Mozilla Firefox Quantum è ufficiale. Ecco cosa cambia

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

[cdimauro]

Abbastanza probabile.

[fano]

Originariamente inviato da Erotavlas_turbo

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.

No, non è sbagliato, ma è un modo un po' "romantico" per dire che Cosmos è solo un kernel non un S.O completo, come Linux nei fatti... è solo un kernel i S.O. hanno nomi esotici tipo "Fedora", "Ubuntu", Mandriva, ecc...

Cosmos non sarà mai il "Windows di domani", non ci interessa il Desktop: quella è una battaglia persa in partenza: lo "Windows di domani" è... Windows.
Ci interessa invece avere un S.O. basato su Cosmos nei router, nei settop-box, perché no pure nei telefoni!