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

[cionci]

Originariamente inviato da cdimauro

Perché?

Tanto per fare un esempio nelle simulazioni matematiche e fisiche e nelle applicazioni per microcontrollori. Nelle simulazioni in particolare si ottimizza il più possibile perché più tempo si risparmia e più soldi si risparmia (per il supercomputer intendo). Nei microcontrollori più tempo si risparmia e più autonomia si acquista (vedi reti di sensori).
In questi ambiti applicativi l'ottimizzazione non ha mai fine.

[Unrue]

Originariamente inviato da cdimauro

Perché se è comunque soddisfacente mi va bene così.

Il tempo risparmiato preferisco spenderlo su altri progetti oppure per aggiornarmi...

Allora abbiamo filosofie di programmazione diverse

[cdimauro]

Originariamente inviato da Unrue

Però spesso non è mica facile dire se le prestazioni sono sufficienti. E magari il codice sembra girare veloce, e poi sotto determinate condizioni va lentissimo. Può capitare.

Se capita, ci si rimette mano.

Beh, la mia non è filosofia ma, considerato il poco a tempo disposizione e le tante cose che ho da fare, soltanto pragmatismo.

[cdimauro]

Originariamente inviato da cionci

Tanto per fare un esempio nelle simulazioni matematiche e fisiche e nelle applicazioni per microcontrollori. Nelle simulazioni in particolare si ottimizza il più possibile perché più tempo si risparmia e più soldi si risparmia (per il supercomputer intendo). Nei microcontrollori più tempo si risparmia e più autonomia si acquista (vedi reti di sensori).
In questi ambiti applicativi l'ottimizzazione non ha mai fine.

Certamente, e concordo.

[sottovento]

Originariamente inviato da tomminno

Dimentichi che dietro c'è una VM che esegue insieme al tuo programma, un Garbage collector che agisce dietro le quinte, tutta l'ereditarietà con tutti i suoi costrutti per la sincronizzazione che si ti ritrovi gratis, ma ce li hai anche se non ti servono.

No, non lo dimentico. Ripeto: non e' difficile trovare casi in cui Java e' piu' veloce.
Usi una macchina virtuale estremamente simile a quella reale, ed ha ben poco overhead, che puo' essere benissimo superato da altre comuni inefficienti in un programma reale.

Originariamente inviato da tomminno

Assolutamente no.
Se nel ciclo for ci metti delle new (e delle delete nell'equivalente C++) il codice dell'applicazione java avrà una new che comporta decisamente più operazioni per via della struttura ad oggetti propria di Java e l'assenza totale del codice di deallocazione che non è a carico del programma, ma di una entità terza: il GC.

Assolutamente si:
- se ci metti delle new, dovrai solo registrare quella memoria, operazione semplicissima;
- quando GC andra' a deallocare, lo fara' meglio di te. (economie di scala).
- il ciclo di vita degli oggetti obblighera' C++ a fare una marea di copie inutili, che saranno sicuramente evitate in programmazione Java;

Originariamente inviato da tomminno

Infatti Java è proliferato in tutti altri ambiti, non è mai diventato il linguaggio dei tostapane come pensato originariamente.

E se anche è stato inserito nello standard Blue Ray, bisogna anche ricordarsi che serve l'accompagnamento di ben 256MB di RAM.

L'ho anche visto girare su 1k di RAM

[cionci]

Originariamente inviato da sottovento

No, non lo dimentico. Ripeto: non e' difficile trovare casi in cui Java e' piu' veloce.
Usi una macchina virtuale estremamente simile a quella reale, ed ha ben poco overhead, che puo' essere benissimo superato da altre comuni inefficienti in un programma reale.

Il codice macchina della VM è intrinsecamente più lento del codice macchina del sistema ospite visto che deve essere interpretato. L'unico modo che ha un VM di arrivare alle prestazioni di un programma compilato è usare un compilatore JIT...altrimenti nisba, non c'è proprio storia.

[cdimauro]

Col vantaggio, però, di poter adattare meglio il codice generato a seconda del contesto dell'esecuzione.

Cosa impossibile da realizzare per un programma C/C++, che è compilato staticamente una sola volta e col compilatore che ha fatto a priori delle assunzioni.

Infatti se esce una nuova architettura le applicazioni Java (.NET, ecc.) non devono essere toccate di una virgola: è sufficiente aggiornare la VM per utilizzarla.

La "morte" del codice binario, invece, è la compilazione statica che lega il codice mani e piedi all'architettura target...

[cionci]

Va bene, ma non c'entra niente con le prestazioni.

[cdimauro]

Invece sì e il motivo è semplice: il compilatore JIT può intervenire sul codice "emesso" se si rende conto che è possibile migliorarlo in base ai dati di profilazione raccolti a runtime, generando del nuovo codice che ne tenga conto.

Il codice, in sostanza, viene "adattato" in base alle condizioni rilevate in tempo reale.

Altra cosa, un compilatore "classico" che ha emesso il "miglior codice" (secondo lui) staticamente per una certa architettura (ma possiamo considerare anche n architetture, con code path diversi selezionati a runtime; come ad esempio avviene coi compilatori Intel da un po' di tempo a questa parte, ma soltanto per le sue architetture) ha fatto il suo lavoro e amen: il codice è quello e non si tocca.

Se arriva una nuova architettura che ha bisogno di ottimizzazioni specifiche, si deve ricompilare nuovamente (es: passando da P3 a P4 le ottimizzazioni sono cambiate anche radicalmente, e il vecchio codice pensato per i primi non gira bene su questi ultimi).

Coi linguaggi che fanno uso di VM, invece, entrambi i problemi sono risolti brillantemente aggiornando soltanto la VM (e il primo problema NON è risolvibile da un compilatore "classico").

[Unrue]

Originariamente inviato da cdimauro

Invece sì e il motivo è semplice: il compilatore JIT può intervenire sul codice "emesso" se si rende conto che è possibile migliorarlo in base ai dati di profilazione raccolti a runtime, generando del nuovo codice che ne tenga conto.

Il codice, in sostanza, viene "adattato" in base alle condizioni rilevate in tempo reale.

Scusa ma quali sarebbero queste condizioni che il compilatore JIT rileva ? Inoltre, più un codice lo puoi legare all'architettura più va veloce, in quanto puoi sfruttare tutto al meglio (cache, registri particolari del processore, ecc ecc). Un compilatore JIT non credo che faccia questo a runtime, non credo proprio, come può farlo? Andrebbe contro il concetto stesso di portabilità. Sono queste le cose che danno una bella spinta all'applicazione. Spesso e volentieri la portabilità di Java in programmi che girano su PC non serve a nulla. A parte programmi di grosse dimensioni, non vedo questa grande fatica a dover ricompilare un programma.

[cionci]

In teoria il profiling a runtime potrebbe tranquillamente farlo, gli basterebbe generare codice diverso al successivo ingresso in quella parte di codice. Ma quanto costa fare un profiling a runtime ? La Java VM lo fa ? Io credo proprio di no.

[Unrue]

Appunto Bisogna vedere se il gioco vale la candela. Ad esempio, io potrei impostare un ciclo for in modo che abbia meno cache miss possibili. MA questo proprio perchè so che tipo di cache ho sotto. Con Java è molto più incasinato fare questo, anzi, non lo puoi proprio fare se il programma è pensato per girare su diverse piattaforme. Sicuramente si troverà una cache differente e quindi tutto il lavoro svolto sul ciclo for andrebbe buttato via.

Secondo me, se prendiamo un programma Java , quanto buono che sia, mai e poi mai avrà le stesse prestazioni di un codice scritto in C, C++ che sfrutta appieno l'hardware. Non c'è compilatore JIT che tenga per questo. Il rovescio della medaglia è ovviamente che se cambio architettura devo ricompilare ma, come ho detto prima,.. è davvero questa grande fatica ricompilare ??

[cionci]

Però lo potrebbe fare la prima volta che genera il codice JIT...e già sarebbe un ottimo compromesso...potrebbe generare un codice diverso per ogni CPU...certo un profiling a runtime sarebbe veramente troppo costoso imho.

[Unrue]

Originariamente inviato da cionci

Però lo potrebbe fare la prima volta che genera il codice JIT...e già sarebbe un ottimo compromesso...potrebbe generare un codice diverso per ogni CPU...certo un profiling a runtime sarebbe veramente troppo costoso imho.

Ma lo fa realmente? E' un'opzione attivabile? Oppure nemmeno si sono posti il problema ? Perchè se non è possibile farlo, C++, in fatto di prestazioni vince alla stragrande ( prima di scatenare polemiche ripeto : mi riferisco a programmi adattati all'hardware che c'è sotto, non in generale)

[cdimauro]

Ecco qui http://arstechnica.com/reviews/1q00/.../dynamo-1.html un articolo che tratta la questione JIT, profiling & generazione dinamica di codice.

Per il resto e rispondendo a Unrue, non di tutti i programmi è disponibile il sorgente e quindi è possibile ricompilare.

Va da sé che il progetto Dinamo di HP dimostra che è possibile prendere un eseguibile già compilato e trattarlo alla stregua del bytecode di Java et similia, quindi tirando fuori nuovo codice in base alle condizioni rilevate a runtime.

Non è il concetto di codice eseguibile che si scontra con quello di bytecode, ma qui il problema è più generale e riguarda la presenza di una VM (ormai spesso dotata di compilatore JIT) che si pone da "intermediario" fra il "codice oggetto" e la macchina che dovrà fisicamente eseguirlo.

Questo concetto lo si può tranquillamente allargare prendendo codice oggetto compilato per una certa architettura e ricompilandolo al volo per farlo girare su un'altra anche completamente diversa.

Ultima cosa: non so se la JVM applica quanto ho esposto. Questo ce lo potrebbe dire PGI-Bis, che ha smanettato sui suoi sorgenti.

[Unrue]

Originariamente inviato da cdimauro

Per il resto e rispondendo a Unrue, non di tutti i programmi è disponibile il sorgente e quindi è possibile ricompilare.

Questo è un altro discorso, che si allaccia all'Open Source. Ma si andrebbe fuori tema.

Originariamente inviato da cdimauro

Questo concetto lo si può tranquillamente allargare prendendo codice oggetto compilato per una certa architettura e ricompilandolo al volo per farlo girare su un'altra anche completamente diversa.

Va bene, ma quanto costa farlo? C++ lo fa in fase di compilazione, Java a runtime.

[cdimauro]

Leggiti il link che ho passato prima.

[jappilas]

Originariamente inviato da Unrue

Scusa ma quali sarebbero queste condizioni che il compilatore JIT rileva ?

ad esempio i code path effettivamente attraversati in base alle condizioni di runtime (in presenza di branch condizionati ) - se nel mio codice vi fosse, per dire, una catena di if del tipo

if ( variabile == valore1) 
   <istruzioni>
else if (variabile == valore2)
   <istruzioni>
   <...>

il primo controllo condizionale verrebbe eseguito anche quando variabile è uguale a valore2; e se durante l' esecuzione del programma fosse la seconda condizione verificata con più frequenza, e quindi preso il relativo branch, avrei una inefficienza (che con un compilatore statico non si avrebbe modo di rilevare se non con un profiling del codice compilato)

Inoltre, più un codice lo puoi legare all'architettura più va veloce, in quanto puoi sfruttare tutto al meglio (cache, registri particolari del processore, ecc ecc).

questo dipende dalle capacità del programmatore di ottimizzare il codice (assembly, perchè per sfruttare direttamente eventuali registri particolari a cui ti riferisci l' uso di linguaggi di più alto livello sarebbe praticamente fuori discussione) a mano e a mente

Un compilatore JIT non credo che faccia questo a runtime, non credo proprio, come può farlo? Andrebbe contro il concetto stesso di portabilità.

anche scrivere codice ad alta ottimizzazione non sarebbe esattamente il massimo della portabilità ( tieni conto che per sfruttare al 100% la macchina, come dicevi, dovresti usare istruzioni che alcuni processori supportano e altri no, tenere conto che ogni famiglia di cpu ( anche all' interno della stessa isa x86) ha una differente topologia (line size, associatività...) per la cache l2...

in sostanza credo che non si tratterebbe di una mera ricompilazione, ma di una riscrittura delle parti sensibili del tuo codice ...

Originariamente inviato da cionci

Però lo potrebbe fare la prima volta che genera il codice JIT...e già sarebbe un ottimo compromesso...potrebbe generare un codice diverso per ogni CPU...certo un profiling a runtime sarebbe veramente troppo costoso imho.

ma esiste almeno un compilatore (LLVM) che ha l' analisi e trasformazione del codice, potenzialmente per tutta la durata del suo ciclo di vita, tra i suoi obiettivi primari

Originariamente inviato da cdimauro

Leggiti il link che ho passato prima.

a cui aggiungerei questo http://www.usenix.org/publications/l...f/chernoff.pdf

[cdimauro]

Con la complessità dei processori attuali non è il caso di usare nemmeno l'assembly: molto meglio affidarsi a ottimi compilatori di linguaggi ad alto livello, che possono tenere conto delle innumerevoli variabili in gioco.

P.S. Grazie per il link.

[Unrue]

Originariamente inviato da jappilas

ad esempio i code path effettivamente attraversati in base alle condizioni di runtime (in presenza di branch condizionati ) - se nel mio codice vi fosse, per dire, una catena di if del tipo

if ( variabile == valore1) 
   <istruzioni>
else if (variabile == valore2)
   <istruzioni>
   <...>

il primo controllo condizionale verrebbe eseguito anche quando variabile è uguale a valore2; e se durante l' esecuzione del programma fosse la seconda condizione verificata con più frequenza, e quindi preso il relativo branch, avrei una inefficienza (che con un compilatore statico non si avrebbe modo di rilevare se non con un profiling del codice compilato)

Questo non è vero perchè ci sono circuiti di branch-prediction nel processore, che evitano proprio questo. E non c'entra nulla con il linguaggio che si sta usando.

E visto che vi piace snocciolare link, ve ne snocciolo uno anch'io :

http://en.wikipedia.org/wiki/Branch_prediction

Originariamente inviato da jappilas

questo dipende dalle capacità del programmatore di ottimizzare il codice (assembly, perchè per sfruttare direttamente eventuali registri particolari a cui ti riferisci l' uso di linguaggi di più alto livello sarebbe praticamente fuori discussione) a mano e a mente

Non è necessario scendere fino all'assembly per fare le ottimizzazioni che dicevo sopra. Basta un buon profiler ed un pò di pazienza Inoltre spesso e volentieri, per abilitare particolari registri, è sufficiente impostare un flag specifico in fare di compilazione e ci pensa poi il compilatore a smistare il flusso di programma su quei registri.