Mozilla Firefox Quantum è ufficiale. Ecco cosa cambia

[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.

[Erotavlas_turbo]

Originariamente inviato da 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/

Nessuno ha chiesto se può fare meglio genericamente, ma a livello di prestazioni.
Lo standard C++ contiene la libreria STL con il tipo string dallo standard C++98, prima ognuno reinventava la ruota (circa 20 anni fa).

Originariamente inviato da fano

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?

Non ho ben capito. Il tipo string dentro STL non è ben ottimizzato!? Questo è vero, ma è solo un aspetto del linguaggio e se hai bisogno di prestazioni utilizzi le stringhe in C fonte 1 fonte 2.

Originariamente inviato da fano

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!

Certo. Teoricamente si può fare in ogni linguaggio di programmazione (python, java, etc.), ma praticamente?! Una buona rassegna delle problematiche da affrontare per scrivere un sistema operativo fonte.
Cosmos e Redox OS al momento sono solo esempi giocattolo teorici.
Vedremo in futuro quando e se ci saranno casi di utilizzo reali (discussione linux vs rust).

[fano]

Originariamente inviato da Erotavlas_turbo

Nessuno ha chiesto se può fare meglio genericamente, ma a livello di prestazioni.
Lo standard C++ contiene la libreria STL con il tipo string dallo standard C++98, prima ognuno reinventava la ruota (circa 20 anni fa).

Scusa ma hai letto tutti e 6 i capitoli? Un'implementazione "naive" in C# era tipo 6 volte più veloce dell'analoga versione C++
Poi ottimizzando fino a che appunto non è diventato C totalmente unsafe e sì C++ vinceva, ma di poco tipo 6%! La domanda qui che si fanno nel blog è per qualche ms in più di "efficienza" vale la pena di sbattersi a scrivere codice in C++?

Originariamente inviato da Erotavlas_turbo

Non ho ben capito. Il tipo string dentro STL non è ben ottimizzato!? Questo è vero, ma è solo un aspetto del linguaggio e se hai bisogno di prestazioni utilizzi le stringhe in C fonte 1 fonte 2.

Vedi? A quel punto se ti riduci ad usare le stringhe C e magari "a fare giochi" di puntatore per trovare stringhe dentro stringhe cosa stai usando C++ a fare? Ti piace dire di compilare con g++, ma poi stai scivendo codice C!

Poi se voglio mica mi impedisce qualcuno di fare le stringhe in C# con i char * sai? Solo che devo usare unsafe e tu non devi mai usare unsafe

Originariamente inviato da Erotavlas_turbo

Certo. Teoricamente si può fare in ogni linguaggio di programmazione (python, java, etc.), ma praticamente?! Una buona rassegna delle problematiche da affrontare per scrivere un sistema operativo fonte.

Beh Python è un linguaggio di scripting di solito interpretato, Java per contro non ha le strutture e unsafe che aiutano molto in C# appunto perché posso fare i giochi di puntatori!

Originariamente inviato da Erotavlas_turbo

Cosmos e Redox OS al momento sono solo esempi giocattolo teorici.
Vedremo in futuro quando e se ci saranno casi di utilizzo reali (discussione linux vs rust).

Teorico Cosmos? Se intendi che esiste solo "sulla carta" di devo smentire gira eccome e pure sull'hardware reale (deve essere un po' vecchiotto però!), abbiamo già le routine di I/O perfettamente funzionante quindi siamo già un po' oltre l'Hello World Kernel.
Ho testato la classe Encoding con sta roba satanica:

            Encoding Encoder = new UTF8Encoding();
            string text;
            byte[] result;
            byte[] expectedResult;

            text = "Cosmos is wonderful!";
            result = Encoder.GetBytes(text);
            expectedResult = UTF8EnglishText;
            Assert.IsTrue(EqualityHelper.ByteArrayAreEquals(result, expectedResult), "UTF8 Encoding of English text failed byte arrays different");

            text = "Cosmos è fantastico!";
            result = Encoder.GetBytes(text);
            expectedResult = UTF8ItalianText;
            Assert.IsTrue(EqualityHelper.ByteArrayAreEquals(result, expectedResult), "UTF8 Encoding of Italian text failed byte arrays different");

            text = "Cosmos es genial!";
            result = Encoder.GetBytes(text);
            expectedResult = UTF8SpanishText;
            Assert.IsTrue(EqualityHelper.ByteArrayAreEquals(result, expectedResult), "UTF8 Encoding of Spanish text failed byte arrays different");

            text = "Cosmos ist großartig!";
            result = Encoder.GetBytes(text);
            expectedResult = UTF8GermanicText;
            Assert.IsTrue(EqualityHelper.ByteArrayAreEquals(result, expectedResult), "UTF8 Encoding of Germanic text failed byte arrays different");

            text = "Cosmos είναι υπέροχος!";
            result = Encoder.GetBytes(text);
            expectedResult = UTF8GreekText;
            Assert.IsTrue(EqualityHelper.ByteArrayAreEquals(result, expectedResult), "UTF8 Encoding of Greek text failed byte arrays different");

            text = "Cosmos 素晴らしいです!";
            result = Encoder.GetBytes(text);
            expectedResult = UTF8JapanaseText;
            Assert.IsTrue(EqualityHelper.ByteArrayAreEquals(result, expectedResult), "UTF8 Encoding of Japanese text failed byte arrays different");

           /* This the only case on which UFT-16 must use a surrugate pairs... it is a Gothic letter go figure! */
            text = "��";
            result = Encoder.GetBytes(text);
            expectedResult = UTF8GothicText;
            Assert.IsTrue(EqualityHelper.ByteArrayAreEquals(result, expectedResult), "UTF8 Encoding of Gothic text failed byte arrays different");
/* E poi l'inverso */

E la velocità era "imbarazzante" il terminale mi scorreva via alla velocità della luce! C & Linux sarebbero stati più veloci? Sì solo perché la libiconv avrebbe dato errore appena incontrato "è" probabilmente: se compilata male come nel 99% delle distro supporta solo ASCII

Linux non è che sia meglio di Cosmos o Redox OS (anzi tutt'altro), ma è stato fortunato a venir "fuori" nel momento giusto...

[cdimauro]

Originariamente inviato da !fazz

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

Già. Pensavo proprio a te, che ci hai a che fare spesso.

Originariamente inviato da fano

Non so io ad aver inventato la definizione "C is portable assembler"

Senz'altro, ma ciò non vuol dire che tale affermazione abbia fondamento.

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!

Sì, si possono fare queste porcate, ma ciò che puoi fare lavorando in assembly è di gran lunga peggio.

Inoltre il C è molto, ma molto più ad alto livello dell'assembly. Anzi, a voler essere pignoli e standard alla mano, ha ben poco di basso livello.

Originariamente inviato da Erotavlas_turbo

se hai bisogno di prestazioni utilizzi le stringhe in C fonte 1 fonte 2.

Le stringhe in C sono anche peggio, visto che conoscere la lunghezza richiede tempo O(n).

E' una delle peggiori strutture dati / implementazioni che siano state scelte per le stringhe.

[Erotavlas_turbo]

Originariamente inviato da fano

Scusa ma hai letto tutti e 6 i capitoli? Un'implementazione "naive" in C# era tipo 6 volte più veloce dell'analoga versione C++
Poi ottimizzando fino a che appunto non è diventato C totalmente unsafe e sì C++ vinceva, ma di poco tipo 6%! La domanda qui che si fanno nel blog è per qualche ms in più di "efficienza" vale la pena di sbattersi a scrivere codice in C++?

Ho letto solo le conclusioni, mi è bastato vedere due benchmark su stackoverflow, che ti ho riportato, dove C vince di molto fonte.
Se chiedi allo sviluppatore di C#, Microsoft, a proposito del suo linguaggio, cosa vuoi ti dica?

Originariamente inviato da fano

Vedi? A quel punto se ti riduci ad usare le stringhe C e magari "a fare giochi" di puntatore per trovare stringhe dentro stringhe cosa stai usando C++ a fare? Ti piace dire di compilare con g++, ma poi stai scivendo codice C!

Il C++ include praticamente tutto il C e quindi non vedo problemi a fare ciò.

Originariamente inviato da fano

Poi se voglio mica mi impedisce qualcuno di fare le stringhe in C# con i char * sai? Solo che devo usare unsafe e tu non devi mai usare unsafe

Certo.

Originariamente inviato da fano

Beh Python è un linguaggio di scripting di solito interpretato, Java per contro non ha le strutture e unsafe che aiutano molto in C# appunto perché posso fare i giochi di puntatori!

Si è vero, ma come è scritto nel link che ti ho riportato non tutti i linguaggi si prestano per scrivere un sistema operativo.

Originariamente inviato da fano

Teorico Cosmos? Se intendi che esiste solo "sulla carta" di devo smentire gira eccome e pure sull'hardware reale (deve essere un po' vecchiotto però!), abbiamo già le routine di I/O perfettamente funzionante quindi siamo già un po' oltre l'Hello World Kernel.
Ho testato la classe Encoding con sta roba satanica:

Teorico giocattolo intendo che non ci siano utilizzi reali. Se mi sbaglio, fammi qualche esempio.
Direttamente da wikipedia:
As of 2016, Cosmos does not aim to become a full operating system, but rather a toolkit to allow other developers to simply and easily build their own operating systems, or as one of the project leaders put it, to act as "operating system Legos".
Se è sbagliato, segnalalo e la correggeranno.

Originariamente inviato da fano

E la velocità era "imbarazzante" il terminale mi scorreva via alla velocità della luce! C & Linux sarebbero stati più veloci? Sì solo perché la libiconv avrebbe dato errore appena incontrato "è" probabilmente: se compilata male come nel 99% delle distro supporta solo ASCII.

Hai un benchmark per affermare ciò? Altrimenti le impressioni lasciano il tempo che trovano...

Originariamente inviato da fano

Linux non è che sia meglio di Cosmos o Redox OS (anzi tutt'altro), ma è stato fortunato a venir "fuori" nel momento giusto...

Linux è un kernel che hai i suoi pregi e difetti come altri kernel cosi come il sistema operativo GNU/linux. Il confronto su reddit mette dei seri punti interrogativi su quali siano i valori aggiunti di Redox OS rispetto a GNU/linux. Non ho trovato niente di simile Cosmos vs GNU/linux, ma non mi aspetto grandi differenze.

Nell'informatica, e non solo, di solito chi arriva prima vince e linux è venuto fuori al momento giusto quando serviva un kernel al progetto GNU. Tuttavia ha 20-25 anni di vantaggio su Cosmos e Redox OS.
Forse fucsia OS di bigG potrebbe essere l'unico rivale di GNU/linux.