JAVA più lento del C++. Ma quanto?

[jappilas]

Originariamente inviato da sottovento

Dimenticavo. Spesso e' utile controllar wikipedia.
Beh, la versione italiana non mi piace, visto che da notizie contrastanti da quella inglese (non completamente, ma le informazioni sono diverse).

[OT]no no, in certi casi le voci sono completamente diverse, e quel che è peggio, a volte riportano evidenti castronerie solo per non voler (o non saper) postare una traduzione diretta della voce inglese originale (solitamente scritta cum grano salis, almeno per quanto concerne l' informatica) - quella sull' Hyperthreading è un esempio lampante [/OT]

Leggendo infatti al link http://en.wikipedia.org/wiki/Compiler il paragrafo "Compiled versus interpreted languages" si legge una cosa, secondo me, importante:<...>
In un certo senso, tutti i linguaggi sono intepretati poiche' girano tutti su una macchina virtuale.

importante, e tanto più vera, soprattutto se si tiene conto che:
da una parte, esistono chip che eseguono nativamente bytecode Java (in cui quindi il BC java diventa parte dell' instruction set - ad esempio ARM con estensione Jazelle )
dall'altra, nei moderni processori, anche l' assembly della ISA pubblica è disaccoppiato dal set delle istruzioni effettivamente eseguite dalle unità interne della cpu, da un livello di traduzione - in questo senso l' instruction decoder agirebbe come virtual machine di basso livello...

Cosa ne pensate? E' questo, secondo voi, il motivo per cui i linguaggi "managed" vinceranno la sfida rispetto ai linguaggi tradizionali?

che i linguaggi managed vincano o meno, dipenderà dal livello di rapidità e di immunità agli errori dei programmatori, che consentiranno di raggiungere nello sviluppo di una soluzione, e da quanto questi due aspetti controbilanceranno il runtime overhead, in ambiti ora esclusivamente coperti dallo sviluppo in linguaggio compilato
se però si considera che dei runtime per managed code sono già entrati a livello kernel nei sistemi operativi attuali (come parti di infrastrutture tese a uniformare la driver base e facilitare lo sviluppo di nuovi driver) e che per l' aggiornamento del C++ in programma per il 2009, si prevede l' introduzione nello standard di una garbage collection, l' impressione è che il managed code sia quello che vuole il mercato...

[sottovento]

Originariamente inviato da jappilas

Tutto

Non volevo ricopiare tutto il tuo post, per cui lo quoto tutto cosi'

[jappilas]

Originariamente inviato da sottovento

Non volevo ricopiare tutto il tuo post, per cui lo quoto tutto cosi'

Originariamente inviato da -Slash

diamond crush mai provato

provalo, secondo me non ti deluderà

<...>: eclipse, che da solo si prende 300 mb di ram e all'uni sui computer un pochino datati è piu che inutilizzabile, maple che sul mio computer con 1 gb di ram e core duo fatica a caricare le finestre azureus che lo trovo semplicemente inutilizzabile, e potrei dirne altri...

non ho usato maple (solo matlab, e non mi pare fosse Java ), uso Eclipse su un p4 con 512 MB di ram - oggettivamente è pesante, più pesante di , per dire, Code:Blocks
ma rispetto a quest' ultimo ha un' architettura diversa (è strutturato in una moltitudine di plugin che vengono caricati all' avvio dell' sdk) e a runtime sembra fare molte più operazioni "dietro le quinte": l' input dell' utente sembra essere monitorato costantemente da un thread in background per tenere aggiornato il database degli import, gli Outlines e per la creazione delle liste contestuali, di hints mirati alla correzione degli errori sintattici in sospeso, di refactoring possibili sul metodo selezionato in un dato momento, e dei membri di classe accessibili con l' operatore di scopes...
credo che ciò contribuisca al suo essere memory e cpu - intensive...

[tomminno]

Originariamente inviato da sottovento

Si, mi ero accorto di non aver deallocato (ho fatto diverse prove prima di postare, poi ho copiato&incollato l'ultima).

Prestazioni di tutto rispetto, direi. 10 milioni di allocazioni in 3 secondi, praticamente 300 nanosecondi ad allocazione.
Sei proprio sicuro? Mi sembra una prestazione davvero esagerata!

Ne approfitto per augurarti Buon Anno, e per estendere l'augurio a tutti i frequentatori del forum.

Compilato in debug, mi risulta che l'esecuzione vari tra 3.4 e 3.6 secondi.
Con un milione di cicli il tempo di esecuzione è di 0.37 secondi.
Tra l'altro vedo che in release con l'opzione O2 non cambia praticamente niente.
Non escludo pesanti ottimizzazioni del loop unrolling del gcc.

Ho provato anche ad usare un pò di C++ invece del C, usando una variabile string e assegnando la stringa vuota. Risultato 1,5 secondi per 10 milioni di cicli.

Con Java 1.6.0.3 usando la classe String ottengo 1,8 secondi, mentre eseguendo la new di un array di char pari a 1024 il tempo di esecuzione è 143,797 secondi.

Se le differenze sono pressochè nulle usando le rispettive classi String, con una sequenza enorme di allocazioni la differenza è parecchio marcata.
Non vedo possibili ottimizzazioni della JVM messe in pratica.

Domani riprovo con XP.

Sarebbe interessante riportare i benchmark ottenuti con questo piccolo test.
I test li ho eseguiti su un notebook Core 2 Duo T5300 1,7GHz, 2GB RAM, Fedora 8.

nel mio caso stravince il c++.

[-Slash]

Originariamente inviato da jappilas

provalo, secondo me non ti deluderà
non ho usato maple (solo matlab, e non mi pare fosse Java ), uso Eclipse su un p4 con 512 MB di ram - oggettivamente è pesante, più pesante di , per dire, Code:Blocks
ma rispetto a quest' ultimo ha un' architettura diversa (è strutturato in una moltitudine di plugin che vengono caricati all' avvio dell' sdk) e a runtime sembra fare molte più operazioni "dietro le quinte": l' input dell' utente sembra essere monitorato costantemente da un thread in background per tenere aggiornato il database degli import, gli Outlines e per la creazione delle liste contestuali, di hints mirati alla correzione degli errori sintattici in sospeso, di refactoring possibili sul metodo selezionato in un dato momento, e dei membri di classe accessibili con l' operatore di scopes...
credo che ciò contribuisca al suo essere memory e cpu - intensive...

anche code::blocks ha una architettura a plugin, e di default ha piu plugin caricati di eclipse(ad esempio wxsmith)

[tomminno]

Originariamente inviato da -Slash

anche code::blocks ha una architettura a plugin, e di default ha piu plugin caricati di eclipse(ad esempio wxsmith)

Eclipse però è un progetto ben più grande e maturo di Code::Blocks, il quale non è che abbia poi molti plugin.
Eclipse lo puoi confrontare con Visual Studio, Code::Blocks no, sebbene sotto tanti aspetto CB funzioni molto meglio di VS per il C++.

[-Slash]

Originariamente inviato da tomminno

Eclipse però è un progetto ben più grande e maturo di Code::Blocks, il quale non è che abbia poi molti plugin.
Eclipse lo puoi confrontare con Visual Studio, Code::Blocks no, sebbene sotto tanti aspetto CB funzioni molto meglio di VS per il C++.

Ma io parlo di velocità del programma... Eclipse di default non ha nessun plugin, a parte quello per team syncronising se non erro

Code::Blocks di default ne ha qualcuno in piu, compreso wxsmith che è bello pesante come plugin, però come velocità non c'è proprio paragone

comunque io sinceramente mi trovo molto meglio con CB che con eclipse cdt, difatti all'uni consigliano eclipse ed io me ne frego altamente ed utilizzo CB

[sottovento]

Originariamente inviato da tomminno

Compilato in debug, mi risulta che l'esecuzione vari tra 3.4 e 3.6 secondi.
Con un milione di cicli il tempo di esecuzione è di 0.37 secondi.
Tra l'altro vedo che in release con l'opzione O2 non cambia praticamente niente.
Non escludo pesanti ottimizzazioni del loop unrolling del gcc.

Ho provato anche ad usare un pò di C++ invece del C, usando una variabile string e assegnando la stringa vuota. Risultato 1,5 secondi per 10 milioni di cicli.

Con Java 1.6.0.3 usando la classe String ottengo 1,8 secondi, mentre eseguendo la new di un array di char pari a 1024 il tempo di esecuzione è 143,797 secondi.

Se le differenze sono pressochè nulle usando le rispettive classi String, con una sequenza enorme di allocazioni la differenza è parecchio marcata.
Non vedo possibili ottimizzazioni della JVM messe in pratica.

Domani riprovo con XP.

Sarebbe interessante riportare i benchmark ottenuti con questo piccolo test.
I test li ho eseguiti su un notebook Core 2 Duo T5300 1,7GHz, 2GB RAM, Fedora 8.

nel mio caso stravince il c++.

E' piu' che interessante, anche perche' mi hai fatto venire il dubbio ed ho rifatto le operazioni, ottenendo ancora la vittoria di Java.

Ho usato un notebook 1,7GHz, 1GB RAM Win XP SP2.
Ho fatto 100 milioni di cicli, avendo tempi in proporzione piu' che doppi dei tuoi (per java, c++ e' molto piu' lento). Fra l'altro, usando Java 1.5 e Visual Studio .NET, che sembra essere uno dei migliori.

Sulle stringhe hai ottenuto 1,5 contro 1,8... beh, devo dire che sono sorpreso in ogni caso dalla velocita', in entrambi i casi. Eppure hai un computer che non e' poi cosi' piu' performante del mio...

A proposito, che tempi hai su 100 milioni di cicli? E, avendo tempo, su 1 miliardo? Le differenze dovrebbero accentuarsi, giusto?
Oppure potrebbe succedere qualcos'altro, visto che la tua memoria e' doppia della mia

[tomminno]

Originariamente inviato da sottovento

E' piu' che interessante, anche perche' mi hai fatto venire il dubbio ed ho rifatto le operazioni, ottenendo ancora la vittoria di Java.

Ho usato un notebook 1,7GHz, 1GB RAM Win XP SP2.
Ho fatto 100 milioni di cicli, avendo tempi in proporzione piu' che doppi dei tuoi (per java, c++ e' molto piu' lento). Fra l'altro, usando Java 1.5 e Visual Studio .NET, che sembra essere uno dei migliori.

Ma con Java che tempi ottieni?
Perchè a me per fare 10 milioni di cicli ci ha messo più di 147 secondi contro i 3.5 del C++.
Non so se possa essere un problema della JVM Sun su linux.

Per quanto riguarda il C++ non ho dubbi che il vantaggio sia il compilatore

A proposito, che tempi hai su 100 milioni di cicli? E, avendo tempo, su 1 miliardo? Le differenze dovrebbero accentuarsi, giusto?
Oppure potrebbe succedere qualcos'altro, visto che la tua memoria e' doppia della mia

Domani provo a ripetere i test e ad eseguirli anche su XP con VS2005.

[sottovento]

Originariamente inviato da tomminno

Ma con Java che tempi ottieni?
Perchè a me per fare 10 milioni di cicli ci ha messo più di 147 secondi contro i 3.5 del C++.

Esattamente il contrario del mio test!
Per 100 milioni di cicli, ci metto 52 secondi, mentre C++ (compilato in modalita' release) piu' del doppio.

Originariamente inviato da tomminno

Fra l'altro, aumentando il numero di cicli, si vede che la velocita' su C++ diminuisce progressivamente.

Non so se possa essere un problema della JVM Sun su linux.

Per quanto riguarda il C++ non ho dubbi che il vantaggio sia il compilatore



Domani provo a ripetere i test e ad eseguirli anche su XP con VS2005.

Sono davvero confuso. Oltretutto ho usato 1.5 che non e' nemmeno l'ultima versione di jdk.

In ogni caso, prendendo le prestazioni che hai segnalato prima sulle stringhe, (in cui Java e' piu' lento), risulta piu' lento di circa il 7%...

[cionci]

Originariamente inviato da cdimauro

Per le altre cose, l'avevo scritto: http://www.hwupgrade.it/forum/showpo...9&postcount=65
Confrontare applicazioni diverse, come Azureus e uTorrent, non ha senso.

Però sarebbe interessante confrontare Azureus in bytecode e Azureus compilato con GCJ...

[cdimauro]

Sicuramente.

[cionci]

sottovento...posta il sorgente anche di Java, almeno evitiamo dubbi dovuti all'implementazione. L'avevi messo il distruttore con la delete[] nella versione C++, vero ?

[cionci]

O il mio compilatore è molto intelligente o la mia macchina è molto veloce

Alloco un po'...
Tempo di allocazione: 0

Versione C++

Edit:

$ time ./MyTest
Alloco un po'...
Tempo di allocazione: 0

real 0m0.154s
user 0m0.148s
sys 0m0.000s

[cionci]

sottovento, mi sa che non hai scelto proprio l'esempio migliore

$ time java -classpath . mytest/Main
Alloco un po'...
Time: 63.06

real 1m3.177s
user 1m2.908s
sys 0m0.500s

$ time ./MyTest
Alloco un po'...
Tempo di allocazione: 11

real 0m11.373s
user 0m11.369s
sys 0m0.000s

[^TiGeRShArK^]

Originariamente inviato da Unrue

Indipendentemente dal fatto che Java sia meglio di C++ od il contrario ( a me piacciono entrambi ) Java, ha l'innegabile overhead di dover fare due compilazioni: una in bytecode e l'altra in assembler. C++ no, la fa direttamente in assembler. E per quanto piccolo sia questo passaggio, non sarà mai eliminabile, in quanto insito nella natura dei linguaggi interpretati. Tutto sta nell'analizzare quanto, nella nostra applicazione, questo passaggio comporta o meno dei rallentamenti. Quindi in ogni applicazione, fatta bene o male, Java parte con un leggero svantaggio.

A volte questo può essere un vantaggio dato che il JIT compila con ottimizzazioni diverse il codice a seconda dei vari path che vengono seguiti al run-time mentre in C++ il codice è sempre compilato staticamente.

Detto questo, spesso il codice Java è più elegante e pulito( ovviamente dipende molto anche dal programmatore) quindi spesso si può accettare un maggior tempo di esecuzione a fronte di una maggiore chiarezza del codice.

Io che lavoro spesso con applicazioni parallele che operano su decine di processori, posso dirvi che Java è visto come la peste in questi campi. C++ un pò meno, non a caso ci sono molte librerie parallele scritte in C++( ad esempio Charm++) . In questo campo, dove si cerca la massima velocità di esecuzione possibile, prevalgono C e Fortran perchè sono ritenuti più veloci di tutti.

Il tempo sprecato per ottimizzare la velocità di esecuzione in C può essere imho usato MOLTO + proficuamente ottimizzando l'algoritmo, che dovrebbe essere praticamente l'unica ottimizzazione da fare dato che tutte le altre portano invariabilmente a una complicazione del codice e va fatta solo ed esclusivamente se vi sono requisiti strettissimi a riguardo.
Inoltre già dalla version 5 di Java c'è tutto il package java.util.concurrent che semplifica notevolmente la gestione di applicaizioni parallele.
Il supporto base al parallelismo invece credo ci sia fin da java 1.0

[^TiGeRShArK^]

Originariamente inviato da tomminno

Come se i memory leak in java non fossero possibili.
A volte anche trovare dei riferimenti circolari che impediscono la deallocazione degli oggetti non è così immediato.
Io non sono risucito a trovarne in un programma C# che per inviare delle stringhe via seriale (usando 2 classi) arriva ad occupare 70MB di RAM per circa 2MB di dati inviati. Avesse avuto dei memory leak in C++ si sarebbe fermato ad occupare 2MB più del necessario, al massimo 4 visto che le classi coinvolte erano 2.

E' MOLTO + difficile avere dei memory leaks in java.
A me sinceramente è capitato solo una volta e il problema si presentava solo in modalità concorrente per un bug del caiser che non riceveva mai tutti i messaggi di un'agente e quindi la coda dei messaggi cresceva indefinitamente.
E sinceramente mi sfugge perchè in C++ il memory leak ti avrebbe preso solo 2 MB in +..
Io credo invece che in quella situazione il problema sarebbe stato se possibile ancora + grave.

[^TiGeRShArK^]

Originariamente inviato da tomminno

Se nei fatti quella memoria non viene mai rilasciata è esattamente equivalente ad un memory leak.
Se dopo un ora che sto sviluppando un progetto C# l'IDE mi occupa 150MB e passo ad un progetto C++ quei 150MB non cambiano di una virgola.
Se invece parto direttamente con il progetto C++ l'occupazione di memoria generalmente non va oltre gli 80MB.
Cosa porta il GC a non deallocare tutta quella ram?
Si tratta di progetti profondamente differenti per cui tutto l'eventuale caching dei dati non è riusabile e quindi dovrebbe essere deallocato.
Siccome questo non accade è perfettamente analogo ad un memory leak, visto che non recupererai mai quella memoria fino alla chiusura dell'IDE.

In C# non ho idea, ma in JAVA il garbage collector di solito viene eseguito solo quando si raggiunge la dimensione predefinita massima assegnata per l'heap space tramite l'opzione -Xmx da riga di comando.
In quel modo l'applicazione non verrà rallentata in alcun modo dal garbage collector fino a che non sia effettivamente necessario.

[Unrue]

Originariamente inviato da sottovento

Si, e' proprio bella.
Immagino che tu abbia preso un programma da 10000 righe di codice ed abbia fatto la verifica. Prego postare

Quindi secondo te gli assembly generati sono uguali?? Ma via su, se vuoi te lo posto un assembly di un programma da 10.000 righe di codice.. Cambia il linguaggio, cambiano i compilatori, cambiano le librerie.. Dimmi come fa l'assembly generato ad essere lo stesso

[Unrue]

Originariamente inviato da ^TiGeRShArK^

Il supporto base al parallelismo invece credo ci sia fin da java 1.0

Io per parallelismo intendevo applicazioni che girano su più processori, non intendevo con i thread. Nel senso che te hai un'applicazione seriale e modifichi l'algoritmo in modo che ogni processore esegue una porzione e poi comunicano tra loro i risultati intermedi. Ad esempio, con le librerie MPI. Dove è il supporto di Java ad applicazioni di questo tipo? Che sono quelle che girano nei supercomputers per simulazioni scientifiche per intendersi. C'è una libreria che sfrutta i threads, ma guarda caso è scritta in C++, e si chiama Charm++

In campi come la simulazione su supercomputers, dove la velocità è fondamentale, Java non è presente. Ma guarda un pò ..