Mozilla Firefox Quantum è ufficiale. Ecco cosa cambia

[Trotto@81]

L'estratto è questo <<WebRender is known for being extremely fast. But WebRender isn’t really about making rendering faster. It’s about making it smoother.>> ovvero "WebRender è noto per essere estremante veloce, ma non si occuperà di rendere più veloce il rendering della pagina".
Il filmato esplicativo riguarda la visualizzazione di un contenuto opengl, che è cosa ben diversa da renderizzare una normale pagina web.
Da quello che ho capito WebRender disegnerà la pagina, ma non si occuperà del rendering. Avremo una visualizzazione più snella e fluida, ma il tempo di elaborazione del contenuto non cambierà.
Quando lo avremo sotto mano vedremo quali saranno i reali benefici. Come scritto nell'articolo una GPU nasce per disegnare i pixel e verrà utilizzata per questo, sgravando la CPU da questo compito a lei poco congeniale, rendendola utilizzabile per altri lavori.
Sono anni che controllo su diversi OS se in "about:support" il WebRender è attivo e non vedo l'ora di provarlo.

[Erotavlas_turbo]

Originariamente inviato da Trotto@81

L'estratto è questo <<WebRender is known for being extremely fast. But WebRender isn’t really about making rendering faster. It’s about making it smoother.>> ovvero "WebRender è noto per essere estremante veloce, ma non si occuperà di rendere più veloce il rendering della pagina".
Il filmato esplicativo riguarda la visualizzazione di un contenuto opengl, che è cosa ben diversa da renderizzare una normale pagina web.
Da quello che ho capito WebRender disegnerà la pagina, ma non si occuperà del rendering. Avremo una visualizzazione più snella e fluida, ma il tempo di elaborazione del contenuto non cambierà.

Se avessi riportato almeno tutto il paragrafo della citazione:

WebRender is known for being extremely fast. But WebRender isn’t really about making rendering faster. It’s about making it smoother.

With WebRender, we want apps to run at a silky smooth 60 frames per second (FPS) or better no matter how big the display is or how much of the page is changing from frame to frame. And it works. Pages that chug along at 15 FPS in Chrome or today’s Firefox run at 60 FPS with WebRender.

So how does WebRender do that? It fundamentally changes the way the rendering engine works to make it more like a 3D game engine.

Originariamente inviato da Trotto@81

Quando lo avremo sotto mano vedremo quali saranno i reali benefici. Come scritto nell'articolo una GPU nasce per disegnare i pixel e verrà utilizzata per questo, sgravando la CPU da questo compito a lei poco congeniale, rendendola utilizzabile per altri lavori.
Sono anni che controllo su diversi OS se in "about:support" il WebRender è attivo e non vedo l'ora di provarlo.

Certo, primi mesi del 2018.

[Trotto@81]

Parla di applicazioni e di fps, non ti tempi di caricamento di una pagina. Avrai lo scrolling a 60 fps, ma il tempo che impiegherà il browser a visualizzare la pagina non varierà.

[Erotavlas_turbo]

Originariamente inviato da Trotto@81

Parla di applicazioni e di fps, non ti tempi di caricamento di una pagina. Avrai lo scrolling a 60 fps, ma il tempo che impiegherà il browser a visualizzare la pagina non varierà.

Certo, dove ho scritto caricamento di una pagina o avvio più veloce?!
Ho scritto solo che la velocità di firefox, nel rendering, sarà superiore del 400% a quella di chrome.
Con questa funzionalità, webVR e webAssembly, molti giochi pesanti verranno spostati sul web con la maggioranza dell'elaborazione in cloud.

[cdimauro]

Originariamente inviato da Erotavlas_turbo

Certo che no, arriva dallo spostamento del rendering da CPU a GPU reso possibile soprattutto grazie a Rust fonte.

Rust non è responsabile di ciò. Lo spostamento del rendering da CPU a GPU si può fare anche con altri linguaggi (C e C++ in primis, ovviamente).

Si certo, migliora rispetto a linguaggi semi compilati (JIT) con virtual machine, ma non raggiunge i livelli di linguaggi compilativi "nativi".
Con C# e Java, python, non può avere le stesse prestazioni di un linguaggio più a "basso livello" come C++/C o Rust

Ecco qui il classico benchmark che confronta diversi linguaggi, e nello specifico C# e C++. In particolare:

reverse-complement
C# .NET Core 0.78
C++ g++      0.64

Come vedi almeno in questo codice le prestazioni di C# (nemmeno AoT, ma eseguito su una VM) sono assolutamente comparabili a quelle di C++. Ovviamente non è sempre così, come dimostrano gli altri algoritmi.

dove puoi gestire direttamente la memoria, gestire la vettorizzazione del codice e usare le funzioni intrinsic.

Con C# puoi gestire direttamente la memoria con blocchi di codice "unsafe", e ci sono funzioni di libreria per utilizzare vettori "SIMD".

Non ci sono funzioni intrinsic, però, ma ormai è da un pezzo che non seguo le evoluzioni del linguaggio.

Tutto dipende da cosa tu debba fare con il tuo codice. Se cerchi le prestazioni non vedo altre scelte fuori da C++/C o Rust.

Anche Fortran, Ada, Go, Pascal non sono male.

Per esempio, con l'arrivo di webAssembly aperto e supportato da tutti i browser, molto meglio usare codice C++/C o Rust e compilarlo per webAssembly anziché usare Java o .Net (proprietario) con le relative VM fonte.

Preferisco usare Python da compilare in WebAssembly.

Se secondo te non è cosi, riportami una review con la comparativa delle prestazioni.

Secondo me prima dovresti leggere attentamente quello che ho scritto, perché non ho fatto nessuna affermazione del genere.

In ogni caso ti ho risposto ugualmente.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

Rust non è responsabile di ciò. Lo spostamento del rendering da CPU a GPU si può fare anche con altri linguaggi (C e C++ in primis, ovviamente).

Certo, ma grazie a Rust è stato fatto con la metà delle righe di codice e un quarto dello sforzo.

Originariamente inviato da cdimauro

Ecco qui il classico benchmark che confronta diversi linguaggi, e nello specifico C# e C++. In particolare:

reverse-complement
C# .NET Core 0.78
C++ g++      0.64

Come vedi almeno in questo codice le prestazioni di C# (nemmeno AoT, ma eseguito su una VM) sono assolutamente comparabili a quelle di C++. Ovviamente non è sempre così, come dimostrano gli altri algoritmi.

Hai preso il caso migliore, considera il caso peggiore (solo 1900% più lento):

regex-redux	
C# .NET Core	30.74 	
C++ g++	1.61

e anche nei casi medi non se la cava meglio.

Originariamente inviato da cdimauro

Con C# puoi gestire direttamente la memoria con blocchi di codice "unsafe", e ci sono funzioni di libreria per utilizzare vettori "SIMD".

Non ci sono funzioni intrinsic, però, ma ormai è da un pezzo che non seguo le evoluzioni del linguaggio.

Si, ma il punto è che non ha molto senso. E' come voler far andare in autostrada una jeep o in campagna una Ferrari.

Originariamente inviato da cdimauro

Preferisco usare Python da compilare in WebAssembly.

Certo senza dubbio. Tranne nel caso tu avessi già pronto codice in C/C++ o Rust.

Originariamente inviato da cdimauro

Secondo me prima dovresti leggere attentamente quello che ho scritto, perché non ho fatto nessuna affermazione del genere.

Infatti, ho usato il condizionale se...

[cdimauro]

Originariamente inviato da Erotavlas_turbo

Certo, ma grazie a Rust è stato fatto con la metà delle righe di codice e un quarto dello sforzo.

Questo è un altro discorso, però.

Hai preso il caso migliore, considera il caso peggiore (solo 1900% più lento):

regex-redux	
C# .NET Core	30.74 	
C++ g++	1.61

e anche nei casi medi non se la cava meglio.

Non ho mai preteso di generalizzare quel risultato alla totalità, ma l'avevo già specificato.

Si, ma il punto è che non ha molto senso. E' come voler far andare in autostrada una jeep o in campagna una Ferrari.

Non direi. Coi blocchi unsafe puoi usare i puntatori sostanzialmente come faresti con C/C++, e in ogni caso sei sicuro di avere confinato il codice potenzialmente pericoloso soltanto in quella specifica zona.

La libreria SIMD, invece, consente di parallelizzare l'accesso ai dati in maniera molto semplice e immediata, lasciando poi l'onere delle specifiche ottimizzazioni al backend relativo al particolare microprocessore su cui il codice gira. Infatti in questo caso c'è il vantaggio non indifferente che il backend, essendo stato già informato che si tratta di codice vettorizzabile, può abilitare fin da subito ottimizzazioni che non sarebbero altrimenti utilizzabili da un compilatore (tranne ovviamente se gli si forniscono "hint" con #pragma, intrinsic, o estensioni del linguaggio come CILK+).

Certo senza dubbio. Tranne nel caso tu avessi già pronto codice in C/C++ o Rust.

Non ho molto codice in C. Ormai 13 anni Python è il mio linguaggi principale, e preferisco usarlo il più possibile.

Infatti, ho usato il condizionale se...

[Frate]

ho provato noscript, non funziona benissimo (pagine che rimangono bianche, eccezioni non salvate) e rallenta un po' il browser, ma credo sia normale e posso solo augurare al progettista buon lavoro

il dubbio è se continuare ad usarlo o farne a meno, sono stato qualche giorno senza e non ne ho sentito tantissimo la mancanza, voi che mi consigliate?

[fano]

Originariamente inviato da Erotavlas_turbo

Si certo, migliora rispetto a linguaggi semi compilati (JIT) con virtual machine, ma non raggiunge i livelli di linguaggi compilativi "nativi".
Con C# e Java, python, non può avere le stesse prestazioni di un linguaggio più a "basso livello" come C++/C o Rust dove puoi gestire direttamente la memoria, gestire la vettorizzazione del codice e usare le funzioni intrinsic.

I casi di cui parlavo (Cosmos e CoreRT) sono casi in cui .NET (C#, ma anche VB.NET, F#, IronPython, ecc...) sono compilati in modo AOT e ovviamente raggiungeranno prestazioni paragonabili al C++ / Rust certo senza rinunciare alla sicurezza di essere un linguaggio Managed.
Cosmos - in particolare - è praticamente che gira sul "bare metal" e quindi avrà vantaggi ulteriori rispetto a CoreRT che ha comunque a che fare con un OS pensato per far girare al meglio C/C++.
Riguardo ai Vector ci sono anche in C#: https://msdn.microsoft.com/en-us/lib...vs.111%29.aspx
così come gli hardware intrisics: https://github.com/dotnet/corefx/issues/22940
per "gestire direttamente la memoria" hanno create un nuovo tipo "Span" che permette di allocare molte cose sullo stack: https://github.com/dotnet/corefxlab/.../specs/span.md

Faccio notare che anche Rust è "parzialmente" managed rispetto a C/C++ non è che ti permette mica di trasformare con un semplice cast un int in un array di char, ha protezioni da buffer overrun / overflow ecc...

Originariamente inviato da Erotavlas_turbo

Per esempio, con l'arrivo di webAssembly aperto e supportato da tutti i browser, molto meglio usare codice C++/C o Rust e compilarlo per webAssembly anziché usare Java o .Net (proprietario) con le relative VM fonte.
Se secondo te non è cosi, riportami una review con la comparativa delle prestazioni.

Infatti quello che si farà almeno riguardo .Net (non so che cosa voglia fare Oracle di Java... sembra niente ) sarà di compilarlo AOT per WebAssembly qui puoi vedere un grazioso "Hello World" in C# che gira sul browser senza problemi:
http://morganbr.github.io/corert/HelloWasm.html

io - sinceramente - C/C++ sul browser li vedo proprio male gira di virus su Web ne girano una marea dargli un altro "buco" da cui passare mi pare una pessima idea!
Quei linguaggi di programmazione nel 2017 inoltrato relegati solo a casi estremi tipo appunto l'embedded (schedina con ARM a 20 MHz e 32 KB di RAM), C alla fine è "assembler" scritto leggermente meglio...

(Ma noi stiamo lavorando a X# che potrebbe essere ancora più veloce del C mantenendo una sintassi sensata rispetto ad ASM )

[GTKM]

Originariamente inviato da fano

C alla fine è "assembler" scritto leggermente meglio...

Qua proprio l'hai sparata. Leggermente meglio? Scherzi?

Originariamente inviato da fano

(Ma noi stiamo lavorando a X# che potrebbe essere ancora più veloce del C mantenendo una sintassi sensata rispetto ad ASM )

Oddio, la sintassi di X# non era tutta 'sta magnificienza, l'ultima volta che ho controllato.

[amd-novello]

Originariamente inviato da fano

Infatti quello che si farà almeno riguardo .Net (non so che cosa voglia fare Oracle di Java... sembra niente ) sarà di compilarlo AOT per WebAssembly qui puoi vedere un grazioso "Hello World" in C# che gira sul browser senza problemi:
http://morganbr.github.io/corert/HelloWasm.html

non vedo nulla nè su edge nè firefox

[fano]

Non c'è scritto "Hello from C#!", nel box nero?

Comunque C è / era chiamato "Portable Assembler":
https://stackoverflow.com/questions/...able-assembler

portatile mica poi tanto visto che a seconda dell'archittetura int è 16, 32 o 64 bit... però assembler in un certo senso sì, con il C sono ben poche le "porcate" che ti sono impedite, quindi...

Riguardo a X# non confondente quello dentro C# in Cosmos che è piuttosto verboso, il vero X# è questo che è un po' un ibrido tra C e un normal macro assembler: https://github.com/CosmosOS/Cosmos/wiki/X%23

Stiamo per rendere X# utilizzabile anche al di fuori di Cosmos con possibilità di eseguire ASM direttamente dal F5 di Visaul Studio
https://github.com/CosmosOS/XSharp
(se avete suggerimenti / idee / proposte sentive liberi di aprire un issue, così ne discutiamo!)

[amd-novello]

ah si ho visto quello pensavo che nel riquadro nero sopra dovesse uscire un'animazione

[cdimauro]

Originariamente inviato da fano

Riguardo ai Vector ci sono anche in C#: https://msdn.microsoft.com/en-us/lib...vs.111%29.aspx
così come gli hardware intrisics: https://github.com/dotnet/corefx/issues/22940

Finalmente una sintassi semplice e pulita per gli intrinsic, anche se avrei preferito che utilizzassero l'operator overloading per implementare un po' di operazioni comuni (+ -> Add, - -> Subtract).

io - sinceramente - C/C++ sul browser li vedo proprio male gira di virus su Web ne girano una marea dargli un altro "buco" da cui passare mi pare una pessima idea!

Ma con WebAssembly non si corre questo pericolo: è tutto managed. Potresti scrivere anche in assembly x86 ricompilato in WA, ma non correresti alcun pericolo.

Quei linguaggi di programmazione nel 2017 inoltrato relegati solo a casi estremi tipo appunto l'embedded (schedina con ARM a 20 MHz e 32 KB di RAM),

Magari! Spesso i chip embedded sono molto meno potenti e dotati.

C alla fine è "assembler" scritto leggermente meglio...

Originariamente inviato da fano

Comunque C è / era chiamato "Portable Assembler":
https://stackoverflow.com/questions/...able-assembler

portatile mica poi tanto visto che a seconda dell'archittetura int è 16, 32 o 64 bit... però assembler in un certo senso sì, con il C sono ben poche le "porcate" che ti sono impedite, quindi...

Non esagerare adesso: C è di gran lunga preferibile all'assembly. Non c'è proprio paragone.

Ti farei lavorare con l'assembly dei PIC Microchip, e poi vorrei vedere se non rimpiangeresti amaramente il C.

Riguardo a X# non confondente quello dentro C# in Cosmos che è piuttosto verboso, il vero X# è questo che è un po' un ibrido tra C e un normal macro assembler: https://github.com/CosmosOS/Cosmos/wiki/X%23

Stiamo per rendere X# utilizzabile anche al di fuori di Cosmos con possibilità di eseguire ASM direttamente dal F5 di Visaul Studio
https://github.com/CosmosOS/XSharp
(se avete suggerimenti / idee / proposte sentive liberi di aprire un issue, così ne discutiamo!)

I like it. Continuate così, che la strada presa è quella giusta (finalmente! Non sopportavo proprio l'altro X#).

[Erotavlas_turbo]

Originariamente inviato da cdimauro

Non direi. Coi blocchi unsafe puoi usare i puntatori sostanzialmente come faresti con C/C++, e in ogni caso sei sicuro di avere confinato il codice potenzialmente pericoloso soltanto in quella specifica zona.

La libreria SIMD, invece, consente di parallelizzare l'accesso ai dati in maniera molto semplice e immediata, lasciando poi l'onere delle specifiche ottimizzazioni al backend relativo al particolare microprocessore su cui il codice gira. Infatti in questo caso c'è il vantaggio non indifferente che il backend, essendo stato già informato che si tratta di codice vettorizzabile, può abilitare fin da subito ottimizzazioni che non sarebbero altrimenti utilizzabili da un compilatore (tranne ovviamente se gli si forniscono "hint" con #pragma, intrinsic, o estensioni del linguaggio come CILK+).

Io aspetto di vedere benchmark (non uno specifico) e casi di utilizzo reali in cui le prestazioni di C# siano paragonabili a C/C++ o Rust.

Originariamente inviato da fano

I casi di cui parlavo (Cosmos e CoreRT) sono casi in cui .NET (C#, ma anche VB.NET, F#, IronPython, ecc...) sono compilati in modo AOT e ovviamente raggiungeranno prestazioni paragonabili al C++ / Rust certo senza rinunciare alla sicurezza di essere un linguaggio Managed.

Fammi un fischio quando questo accadrà, non vedo l'ora di vederlo. Personalmente non credo sarà mai possibile in presenza di I/O massiccio e ottimizzazione del codice a livello fisico.

Originariamente inviato da fano

Cosmos - in particolare - è praticamente che gira sul "bare metal" e quindi avrà vantaggi ulteriori rispetto a CoreRT che ha comunque a che fare con un OS pensato per far girare al meglio C/C++.
Riguardo ai Vector ci sono anche in C#: https://msdn.microsoft.com/en-us/lib...vs.111%29.aspx
così come gli hardware intrisics: https://github.com/dotnet/corefx/issues/22940
per "gestire direttamente la memoria" hanno create un nuovo tipo "Span" che permette di allocare molte cose sullo stack: https://github.com/dotnet/corefxlab/.../specs/span.md

Faccio notare che anche Rust è "parzialmente" managed rispetto a C/C++ non è che ti permette mica di trasformare con un semplice cast un int in un array di char, ha protezioni da buffer overrun / overflow ecc...

Certo infatti, non credo verranno mai scritte applicazioni ad alte prestazioni (kernel, calcolo distribuito, etc.) ne in Rust ne sicuramente in C#.
Rust è il miglior candidato che conosco per sostituire il C++ dove occorrono ottime prestazioni e ridotto sforzo di sviluppo.

Originariamente inviato da fano

Infatti quello che si farà almeno riguardo .Net (non so che cosa voglia fare Oracle di Java... sembra niente ) sarà di compilarlo AOT per WebAssembly qui puoi vedere un grazioso "Hello World" in C# che gira sul browser senza problemi:
http://morganbr.github.io/corert/HelloWasm.html

io - sinceramente - C/C++ sul browser li vedo proprio male gira di virus su Web ne girano una marea dargli un altro "buco" da cui passare mi pare una pessima idea!
Quei linguaggi di programmazione nel 2017 inoltrato relegati solo a casi estremi tipo appunto l'embedded (schedina con ARM a 20 MHz e 32 KB di RAM), C alla fine è "assembler" scritto leggermente meglio...

(Ma noi stiamo lavorando a X# che potrebbe essere ancora più veloce del C mantenendo una sintassi sensata rispetto ad ASM )

Mi sembra abbastanza azzardato definire C un assembler scritto meglio, come hanno fatto notare altri utenti.

[cdimauro]

Originariamente inviato da Erotavlas_turbo

Io aspetto di vedere benchmark (non uno specifico) e casi di utilizzo reali in cui le prestazioni di C# siano paragonabili a C/C++ o Rust.

In questo caso servirebbe un'applicazione "non banale" (nonché utile) scritta sia in C# sia in C/C++ o Rust, altrimenti il confronto non avrebbe senso.

Ma non ne conosco.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

In questo caso servirebbe un'applicazione "non banale" (nonché utile) scritta sia in C# sia in C/C++ o Rust, altrimenti il confronto non avrebbe senso.

Ma non ne conosco.

Si, io penso che non ci saranno mai visto gli ambiti diversi per i quali i linguaggi sono stati ideati.

Ritornando nell'argomento della discussione, per coloro che volessero provare a installare i componenti aggiuntivi di chrome e opera dentro firefox è disponibile questo componente aggiuntivo foxified.
Tra i vari vantaggi anche la non necessità di avere un account google.

@TheDarkAngel
Per una lista di gestori delle tab di chrome fonte. Non le ho provate in quanto ho trovato un ottimo sostituto di tab mix plus, in attesa del porting, per firefox foxyTab.

[!fazz]

Originariamente inviato da cdimauro

Finalmente una sintassi semplice e pulita per gli intrinsic, anche se avrei preferito che utilizzassero l'operator overloading per implementare un po' di operazioni comuni (+ -> Add, - -> Subtract).

Ma con WebAssembly non si corre questo pericolo: è tutto managed. Potresti scrivere anche in assembly x86 ricompilato in WA, ma non correresti alcun pericolo.

Magari! Spesso i chip embedded sono molto meno potenti e dotati.


Non esagerare adesso: C è di gran lunga preferibile all'assembly. Non c'è proprio paragone.

Ti farei lavorare con l'assembly dei PIC Microchip, e poi vorrei vedere se non rimpiangeresti amaramente il C.

I like it. Continuate così, che la strada presa è quella giusta (finalmente! Non sopportavo proprio l'altro X#).

mi sento un pò tirato in causa, ma solo un po...

[fano]

Riguardo la domanda un'applicazione scritta in C# può fare meglio di una scritta in C++? Certo in particolare quando si ha a che fare con operazioni con stringhe che in C# sono più ottimizzate (in C++ la prima domanda è: quale tipo di stringa? Ognuno si rifa la sua versione ):
https://blogs.msdn.microsoft.com/ric...ionary-reader/

certo dopo aver ottimizzato "a sangue" fino a riscrivere l'ennesima versione della class string, aver rinunciato al dizionario della libc++ e alla fine scrivendosi le proprio routine di I/O C++ fince su C# ma di poco e vale lo sbattimento?

Kernel scritte in C# o in Rust non sarebbero possibili? E Cosmos e Redox OS cosa sarebbero mai? Redox c'ha pure il Desktop se volete quindi è pure un po' più avanti di Cosmos!

Non so io ad aver inventato la definizione "C is portable assembler" il senso di quello che intendevo è che C è una via di mezzo ha costrutti di alto livello, nasconde i registri, ma poi ti permette di fare cose alla "assembler" tipo prendere un array di char scriverci un indirizzo a "caso", castarlo a puntatore a funzione ed eseguirlo ed eccoti bel bello in kernel mode partendo da un'applicazione utente!

[Trotto@81]

Rust, a detta degli sviluppatori, è stato usato per ovviare alle limitazioni dei classici linguaggi orientati ad oggetti e non per la velocità intrinseca dei binari e tutte le cose di cui avete discusso fin'ora.