Java vs C++... Sono stanco...

[71104]

Originariamente inviato da mjordan

Se non c'è nulla che la vieti, allora perchè parli di livello teorico?

dove sarebbe il controsenso?

[tomminno]

Originariamente inviato da cdimauro

Sì, sono decisamente da buttare. Infatti non è un caso che MS punti molto su C#, che è un linguaggio notoriamente managed, e che i programmatori cominciano a sviluppare giochi con C# e l'ultimo XDK, che è basato su questo linguaggio.
Inoltre linguaggi come Python e LUA oggi rappresentano la scelta d'elezione per implementare la parte di scripting dei videogiochi.

Peccato che il C# cambi le linee guida di programmazione ad ogni major revision, dai dataset ai datasource a non so cosa nella versione 3.0.
Si parla di riusabilità del codice, ma col C# è inesistente.
Se penso ad un programma con una vita stimata di una decina d'anni, realizzarlo in C# non mi sembra un'ottima idea. Ogni 2 anni sarai obbligato a fare il porting alla nuovissima versione ricca di feature.

Non solo: il prossimo s.o. MS, che arriverà fra 3 anni, a quanto pare sarà basato interamente sulla piattaforma .NET, il cui runtime è anch'esso notoriamente managed (e alla base di linguaggi come C#, VB.NET, Delphi.NET, IronPython, ecc.. ecc.)

Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno...

Poi siamo realistici in 3 anni non scrivi un sistema operativo, sarà più facile che realizzino un wrapper sopra le API di Vista così da renderlo ancora più leggero

Saranno tutti pazzi...

No tirano acqua al loro mulino, tanto che il C++ è decisamente trascurato dai loro editor e alcune feature attese con VS2005 pare saranno rimandate a 2 versioni dopo Orcas...

[71104]

Originariamente inviato da tomminno

Peccato che il C# cambi le linee guida di programmazione ad ogni major revision, dai dataset ai datasource a non so cosa nella versione 3.0.
Si parla di riusabilità del codice, ma col C# è inesistente.
Se penso ad un programma con una vita stimata di una decina d'anni, realizzarlo in C# non mi sembra un'ottima idea. Ogni 2 anni sarai obbligato a fare il porting alla nuovissima versione ricca di feature.

il framework è ancora giuovine, dagli tempo: è solo alla versione 3, Java per esempio è già alla 6. chissà quali difetti aveva Java quando era alla versione 3 a partire dalla numerazione delle versioni

io mi chiedo sinceramente cosa diamine avessero in mente di fare alla Sun prima di ottenere la major version numero 2.

Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno...

perché?

Poi siamo realistici in 3 anni non scrivi un sistema operativo, sarà più facile che realizzino un wrapper sopra le API di Vista così da renderlo ancora più leggero

in 3 anni lo scrivi un sistema operativo, dipende da quali sono gli obiettivi e quanta manodopera c'è a disposizione. più che altro io dubito che riusciranno veramente a realizzare un intero sistema operativo (kernel compreso) in .NET, Microsoft vorrà anche investire su questa nuova tecnologia ma non così tanto... considera che comunque il tutto dovrebbe continuare a supportare in backward compatibility gli attuali drivers e l'attuale subsystem Win32, altrimenti è un semplice suicidio. raramente però nelle piattaforme managed è facile gestire ciò di cui gli attuali device drivers per Windows hanno bisogno: tutte le struct che essi utilizzano, tra documentate, opache e non documentate, hanno un layout ben preciso che penso in C# sarebbe decisamente meno gestibile che in C. forse è per questo che il C# ha la keyword unsafe

No tirano acqua al loro mulino,

convertire il mondo alle piattaforme managed secondo te è un comodo loro? certo, lo sarà di sicuro quando il mondo sarà stato convertito ad una piattaforma managed loro, ma vorrei sapere cosa importa a te: la tua vita non può che cambiare in meglio senza i puntatori, e allora stacci senza tante storie, no? ti fanno un grande favore, si vede che meritano un ringraziamento.

tanto che il C++ è decisamente trascurato dai loro editor e alcune feature attese con VS2005 pare saranno rimandate a 2 versioni dopo Orcas...

tipo? uno formato universale per i puntatori a metodi?
comunque non vedo cosa c'entri: hai fatto un'affermazione ("tirano acqua al loro mulino") già di per se' discutibile e pretendi di anche rifilarcela molto alla lontana.

[71104]

Originariamente inviato da tomminno

Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno...

ah, dimenticavo: http://en.wikipedia.org/wiki/Physical_Address_Extension

[cionci]

Originariamente inviato da 71104

ah, dimenticavo: http://en.wikipedia.org/wiki/Physical_Address_Extension

71104: peccato che il PAE abbia un impatto sulle prestazioni notevole.

[cdimauro]

Originariamente inviato da tomminno

Peccato che il C# cambi le linee guida di programmazione ad ogni major revision, dai dataset ai datasource a non so cosa nella versione 3.0.
Si parla di riusabilità del codice, ma col C# è inesistente.
Se penso ad un programma con una vita stimata di una decina d'anni, realizzarlo in C# non mi sembra un'ottima idea. Ogni 2 anni sarai obbligato a fare il porting alla nuovissima versione ricca di feature.

Questo potrebbe succedere se ogni major version rompesse pesantemente la compatibilità col passato, ma non mi risulta.

Finalmente avremo un OS che sarà obbligatoriamente a 64 bit visto che 4GB di ram non basteranno...

Non vedo il nesso. Managed <> enorme quantità di memoria richiesta.

Poi siamo realistici in 3 anni non scrivi un sistema operativo, sarà più facile che realizzino un wrapper sopra le API di Vista così da renderlo ancora più leggero

Con Vista Windows è stato oggetto di una profonda riscrittura (e .NET è stato utilizzato estensivamente), che però non è ancora stata completata: lo sarà, appunto, con la prossima versione.

No tirano acqua al loro mulino, tanto che il C++ è decisamente trascurato dai loro editor e alcune feature attese con VS2005 pare saranno rimandate a 2 versioni dopo Orcas...

Mi sembra normale: il futuro è managed, e ha poco senso continuare a investire su prodotti che diventeranno presto obsoleti (C# ha già rosicchiato una buona fetta del mercato, e considerato che è un linguaggio molto giovane ha tutte le carte in regole per imporsi).

Per il resto, chi non tira acqua al proprio mulino?

[cdimauro]

Originariamente inviato da cionci

71104: peccato che il PAE abbia un impatto sulle prestazioni notevole.

Dipende da come viene usato.

[cionci]

Originariamente inviato da cdimauro

Dipende da come viene usato.

Cioè ?
Che io sappia per la sola traduzione degli indirizzi c'è un hit intorno al 5%.

[k0nt3]

Originariamente inviato da 71104

la verità è che per la scrittura dei kernels non ci sono molte vie di mezzo: l'unica che conosco è il C++, per la quale però secondo me Microsoft non passerà.

il C++ se usato come si deve è una buona alternativa, ma per fare il primo esempio che mi viene in mente c'è anche il D

Originariamente inviato da 71104

reinterpreto la frase come: "sono dell'idea che gli ambienti managed non convengano alla programmazione di sistemi operativi". è vero che quelli attualmente esistenti non sono fatti per la programmazione di sistema e il controllo della macchina a basso livello, ma nulla permette di affermare che per definizione un ambiente managed non possa essere progettato a tali scopi. e che una volta progettati "non convengano" è tutto da dimostrare (ma secondo me sprecheresti solo tempo a cercare di dimostrarlo).

io dico che non convengono per motivi prestazionali, se non poi un giorno ci potremo permettere un processore che serve solo alla VM, oppure chessò un'implementazione hardware.. allora le cose potrebbero cambiare.

Originariamente inviato da 71104

credo che sia opinione abbastanza diffusa che gli errori più brutti che la storia della programmazione abbia mai visto sono quelli relativi alla corruzione di memoria e all'uso errato della memoria allocata dinamicamente. non sono certo gli operatori new e delete a risolvere tale problema: per quanto mi riguarda sono quasi identici a malloc e free (faccio solo meno fatica a scriverli perché richiedono meno caratteri e non serve il cast). il passo decisivo verso una nuova era di gestione della memoria dinamica (lol ) sono i garbage collectors e gli array managed. gcnew e niente delete. eccezione se sforo un buffer.

non vedo come le cose siano correlate
il garbage collector non è una peculiarità degli ambienti managed (anche se sono loro ad averne spinto l'uso) ci sono dei GC anche per il C
la peculiarità degli ambienti managed è quella di girare dentro una VM e attualmente non vedo perchè dovrebbe farlo il SO, in fondo il vantaggio più evidente di queste soluzioni è la portabilità e non mi sembra un'esigenza nella programmazione di un SO.
prendi un linguaggio come il D ad esempio.. offre tutto quello che offrono i linguaggi degli ambienti managed come java e C# (se non di più) e inoltre permette anche di inserire direttamente codice assembly nel sorgente (cosa che nella programmazione di un SO fa sempre comodo)

[cionci]

Un Gabage Collector fatto con gli smart pointer si scrive in 10 minuti con la STL

[cdimauro]

Originariamente inviato da cionci

Cioè ?
Che io sappia per la sola traduzione degli indirizzi c'è un hit intorno al 5%.

Non mi risulta questa penalizzazione (che è a carico della cache tag), ma anche se fosse il 5% non sarebbe certo di "notevole impatto" sulle prestazioni.

La fregatura col PAE è quando la memoria in più viene usata come la vecchissima EMS dei tempi dell'8086, cioé copiando in segmenti sotto il limite dei 4GB le zone di memoria alta a cui bisogna accedere.

[^TiGeRShArK^]

Originariamente inviato da 71104

io mi chiedo sinceramente cosa diamine avessero in mente di fare alla Sun prima di ottenere la major version numero 2.

perché?

[cionci]

Originariamente inviato da cdimauro

La fregatura col PAE è quando la memoria in più viene usata come la vecchissima EMS dei tempi dell'8086, cioé copiando in segmenti sotto il limite dei 4GB le zone di memoria alta a cui bisogna accedere.

E Windows Server come fa ? Se non sbaglio NT e 2000 facevano come hai detto te.

[k0nt3]

Originariamente inviato da cdimauro

Non mi risulta questa penalizzazione (che è a carico della cache tag), ma anche se fosse il 5% non sarebbe certo di "notevole impatto" sulle prestazioni.

a me sembra tantissimo per un SO

[^TiGeRShArK^]

Originariamente inviato da cionci

71104: peccato che il PAE abbia un impatto sulle prestazioni notevole.

confermo

[cionci]

Originariamente inviato da cdimauro

Non mi risulta questa penalizzazione (che è a carico della cache tag), ma anche se fosse il 5% non sarebbe certo di "notevole impatto" sulle prestazioni.

Non solo della tag cache. Mi sembra di aver letto che c'è un'ulteriore livello nella tabella delle pagine e questo mette in crisi il TLB.

[^TiGeRShArK^]

Originariamente inviato da cionci

Cioè ?
Che io sappia per la sola traduzione degli indirizzi c'è un hit intorno al 5%.

da quello che ricordo io quello era il problema minore..
quando dovevi accedere continuamente a pagine situate in blocchi diversi avevi prestazioni decisamente catastrofiche.
Quello era uno dei principali vantaggi dell'uso di x86-64 con programmi che usavano enormi quantità di memoria.

[^TiGeRShArK^]

Originariamente inviato da k0nt3

io dico che non convengono per motivi prestazionali, se non poi un giorno ci potremo permettere un processore che serve solo alla VM, oppure chessò un'implementazione hardware.. allora le cose potrebbero cambiare.

da quel che so almeno in ambiente mobile ci si sta già muovendo in questa direzione mediante dei chip atti proprio ad accelerare la VM java in hardware...
Ora però mi sfugge il nome del chipppettino in questione

[k0nt3]

Originariamente inviato da ^TiGeRShArK^

da quel che so almeno in ambiente mobile ci si sta già muovendo in questa direzione mediante dei chip atti proprio ad accelerare la VM java in hardware...
Ora però mi sfugge il nome del chipppettino in questione

vero! ma in questo caso la portabilità è un'esigenza piuttosto importante

[cdimauro]

Originariamente inviato da k0nt3

il C++ se usato come si deve è una buona alternativa, ma per fare il primo esempio che mi viene in mente c'è anche il D

Concordo: il D lo trovo nettamente migliore del C++.

Per il resto, non credo che i tempi siano maturi per un s.o. totalmente managed.

Personalmente propendo per un piccolo kernel scritto con un linguaggio non-managed e che si occupa di far girare la VM (col JIT compiler) su cui poi poggia tutto il resto.

io dico che non convengono per motivi prestazionali, se non poi un giorno ci potremo permettere un processore che serve solo alla VM, oppure chessò un'implementazione hardware.. allora le cose potrebbero cambiare.

Ricordo di aver letto tempo fa che mediamente le prestazioni di un'applicazione managed .NET 2.0 sono del 90% circa rispetto alla stessa, ma compilata in x86 per win32.

Mi sembra un ottimo risultato, con margini di miglioramento per il futuro.

non vedo come le cose siano correlate
il garbage collector non è una peculiarità degli ambienti managed (anche se sono loro ad averne spinto l'uso) ci sono dei GC anche per il C
la peculiarità degli ambienti managed è quella di girare dentro una VM e attualmente non vedo perchè dovrebbe farlo il SO, in fondo il vantaggio più evidente di queste soluzioni è la portabilità e non mi sembra un'esigenza nella programmazione di un SO.

Certamente (e ancora per un po').

Comunque la VM di cui parli con .NET si traduce sempre in JIT compiler per l'architettura su cui sta girando l'applicazione.

prendi un linguaggio come il D ad esempio.. offre tutto quello che offrono i linguaggi degli ambienti managed come java e C# (se non di più)

In Java e C# viene usato il GC per TUTTO, e infatti non c'è più spazio per i segmentation fault. Non mi risulta che il D faccia lo stesso.

e inoltre permette anche di inserire direttamente codice assembly nel sorgente (cosa che nella programmazione di un SO fa sempre comodo)

Considerato il ristrettissimo uso che se ne fa dell'assembly (dentro un s.o. in particolare) ormai, non sarebbe una gran perdita.