Innanzitutto, la maggior parte delle JVM include un compilatore, quindi "interpretato da un codice" è in realtà piuttosto raro (almeno nel codice di riferimento) non è così raro nella vita reale, in cui il codice è in genere più di pochi loop banali che ottengono ripetuto molto spesso).
In secondo luogo, un buon numero di benchmark coinvolti sembra essere abbastanza di parte (sia per intento o incompetenza, non posso davvero dire). Solo per esempio, anni fa ho guardato parte del codice sorgente collegato da uno dei link che hai postato. Aveva un codice come questo:
init0 = (int*)calloc(max_x,sizeof(int));
init1 = (int*)calloc(max_x,sizeof(int));
init2 = (int*)calloc(max_x,sizeof(int));
for (x=0; x<max_x; x++) {
init2[x] = 0;
init1[x] = 0;
init0[x] = 0;
}
Poiché calloc fornisce una memoria già azzerata, utilizzando il ciclo for a zero, di nuovo è ovviamente inutile. Questo è stato seguito (se la memoria serve) riempiendo comunque la memoria con altri dati (e nessuna dipendenza dal suo azzeramento), quindi tutto l'azzeramento era del tutto inutile comunque. Sostituendo il codice precedente con un semplice malloc (come qualsiasi persona sana di mente avrebbe usato per iniziare) ha migliorato la velocità della versione C ++ abbastanza da battere la versione Java (con un margine abbastanza ampio, se la memoria serve).
Considera (per un altro esempio) il benchmark methcall utilizzato nella post di blog nel tuo ultimo link. Nonostante il nome (e il modo in cui le cose potrebbero sembrare), la versione C ++ di questo è non che misura davvero molto circa l'overhead di chiamata del metodo. La parte del codice che risulta critica è nella classe Toggle:
class Toggle {
public:
Toggle(bool start_state) : state(start_state) { }
virtual ~Toggle() { }
bool value() {
return(state);
}
virtual Toggle& activate() {
state = !state;
return(*this);
}
bool state;
};
La parte critica risulta essere state = !state; . Considera cosa succede quando cambiamo il codice per codificare lo stato come int invece di bool :
class Toggle {
enum names{ bfalse = -1, btrue = 1};
const static names values[2];
int state;
public:
Toggle(bool start_state) : state(values[start_state])
{ }
virtual ~Toggle() { }
bool value() { return state==btrue; }
virtual Toggle& activate() {
state = -state;
return(*this);
}
};
Questa piccola modifica migliora la velocità complessiva di circa margine di 5: 1 . Anche se il parametro di riferimento era inteso per misurare il tempo di chiamata del metodo, in realtà la maggior parte di ciò che stava misurando era il tempo di convertire tra int e bool . Sarei certamente d'accordo sul fatto che l'inefficienza mostrata dall'originale sia sfortunata - ma vista la rarità che sembra sorgere nel codice reale e la facilità con cui può essere riparata quando / se si presenta, ho difficoltà a pensare ne significa molto.
Nel caso qualcuno decidesse di rieseguire i benchmark coinvolti, dovrei anche aggiungere che c'è una modifica quasi ugualmente banale alla versione di Java che produce (o almeno una volta prodotta - Non ho ri-eseguito prova con una JVM recente per confermare che fanno ancora) un miglioramento abbastanza sostanziale anche nella versione Java. La versione Java ha un NthToggle :: activate () che assomiglia a questo:
public Toggle activate() {
this.counter += 1;
if (this.counter >= this.count_max) {
this.state = !this.state;
this.counter = 0;
}
return(this);
}
Cambiare questo per chiamare la funzione base invece di manipolare this.state dà direttamente un notevole miglioramento della velocità (sebbene non sia sufficiente per tenere il passo con la versione modificata del C ++).
Quindi, quello che finiamo è una falsa ipotesi sui codici byte interpretati rispetto ad alcuni dei peggiori benchmark (che io abbia mai visto). Né sta dando un risultato significativo.
La mia esperienza personale è che con programmatori altrettanto esperti che prestano uguale attenzione all'ottimizzazione, il C ++ batterà Java molto spesso - ma (almeno tra questi due), il linguaggio raramente farà la stessa differenza dei programmatori e del design . I parametri di riferimento citati ci dicono di più sulla (in) competenza / (dis) onestà dei loro autori di quanto non facciano riguardo alle lingue che intendono indicare.
[Modifica: come implicito in un punto sopra ma mai affermato direttamente come probabilmente dovrei avere, i risultati che sto citando sono quelli che ho ottenuto quando ho testato questo ~ 5 anni fa, usando le implementazioni C ++ e Java che erano attuali a quel tempo. Non ho eseguito nuovamente i test con le implementazioni correnti. Uno sguardo, tuttavia, indica che il codice non è stato corretto, quindi tutto ciò che sarebbe cambiato sarebbe stata la capacità del compilatore di nascondere i problemi nel codice.]
Se ignoriamo gli esempi Java, tuttavia, è effettivamente possibile che il codice interpretato funzioni più velocemente del codice compilato (sebbene sia difficile e alquanto insolito).
Il solito modo in cui ciò accade è che il codice che viene interpretato è molto più compatto del codice macchina, o è in esecuzione su una CPU che ha una cache di dati più grande della cache del codice.
In tal caso, un piccolo interprete (ad esempio, l'interprete interno di un'implementazione Forth) potrebbe essere in grado di adattarsi interamente alla cache del codice e il programma dell'interpretazione si adatta perfettamente alla cache dei dati. La cache è in genere più veloce della memoria principale di un fattore di almeno 10 e spesso molto più (un fattore di 100 non è particolarmente raro).
Quindi, se la cache è più veloce della memoria principale di un fattore N e richiede meno di N istruzioni per codice macchina per implementare ogni codice byte, il codice byte dovrebbe vincere (sto semplificando, ma penso che il generale l'idea dovrebbe essere ancora evidente)
La mano arrotolata C / C ++ fatta da un esperto con un tempo illimitato sarà almeno altrettanto veloce o più veloce di Java. In definitiva, Java in sé è scritto in C / C ++, quindi puoi ovviamente fare tutto ciò che fa Java se sei disposto a impegnarti abbastanza in ingegneria.
In pratica, tuttavia, Java viene eseguito spesso molto velocemente per i seguenti motivi:
Allo stesso tempo C / C ++ ha anche alcuni vantaggi:
In generale:
Il runtime Java isnt interpreta bytecode. Piuttosto, utilizza ciò che è chiamato Compilazione Just In Time . Fondamentalmente, mentre il programma è in esecuzione, prende il bytecode e lo converte in codice nativo ottimizzato per la particolare CPU.
A parità di condizioni, si potrebbe dire: no, Java non dovrebbe mai essere più veloce . È sempre possibile implementare Java in C ++ da zero e ottenere quindi prestazioni altrettanto buone. In pratica, tuttavia:
Per inciso, questo mi ricorda il dibattito su C negli anni '80 / '90. Tutti si chiedevano "può mai essere C veloce come l'assemblea?". Fondamentalmente, la risposta è stata: no sulla carta, ma in realtà il compilatore C ha creato un codice più efficiente del 90% dei programmatori di assiemi (beh, una volta maturato un po ').
But allocation is only half of memory management -- deallocation is the other half. It turns out that for most objects, the direct garbage collection cost is -- zero. This is because a copying collector does not need to visit or copy dead objects, only live ones. So objects that become garbage shortly after allocation contribute no workload to the collection cycle.
...
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know. By letting the JVM choose between stack allocation and heap allocation on a case-by-case basis, we can get the performance benefits of stack allocation without making the programmer agonize over whether to allocate on the stack or on the heap.
Mentre un programma Java completamente ottimizzato raramente batte un programma C ++ completamente ottimizzato, le differenze in cose come la gestione della memoria possono rendere molti algoritmi implementati idiomaticamente in Java più velocemente degli stessi algoritmi implementati in modo criptato in C ++.
Come sottolineato da @Jerry Coffin, ci sono molti casi in cui semplici modifiche possono rendere il codice molto più veloce - ma spesso può richiedere troppe modifiche impure in una lingua o l'altra per il miglioramento delle prestazioni. Questo è probabilmente ciò che vedresti in un benchmark buono che mostra che Java fa meglio del C ++.
Inoltre, anche se di solito non è così significativo, ci sono alcune ottimizzazioni delle prestazioni che un linguaggio JIT come Java può fare che C ++ non può. Il runtime Java può includere miglioramenti dopo il codice è stato compilato, il che significa che il JIT può potenzialmente produrre codice ottimizzato per sfruttare le nuove (o almeno diverse) caratteristiche della CPU. Per questo motivo, un binario Java di 10 anni potrebbe potenzialmente superare un binario C ++ di 10 anni.
Infine, la completa sicurezza del tipo nell'immagine più grande può, in casi molto rari, offrire miglioramenti delle prestazioni estremi. Singularity , un sistema operativo sperimentale scritto quasi interamente in un linguaggio basato su C #, ha una comunicazione interprocesso molto più veloce e multitasking grazie al fatto che non sono necessari limiti di processo hardware o costosi switch di contesto.
Pubblicato da Tim Holloway su JavaRanch:
Here's a primitive example: Back when machines operated in mathematically-determined cycles, a branch instruction typically had 2 different timings. One for when the branch was taken, one for when the branch wasn't taken. Usually, the no-branch case was faster. Obviously, this meant that you could optimize logic based on the knowledge of which case was more common (subject to the constraint that what we "know" isn't always what's actually the case).
JIT recompilation takes this one step further. It monitors the actual real-time usage, and flips the logic based on what actually is the most common case. And flip it back again if the workload shifts. Statically-compiled code can't do this. That's how Java can sometimes out-perform hand-tuned assembly/C/C++ code.
Fonte: link
Questo perché il passaggio finale che genera il codice macchina avviene in modo trasparente all'interno della JVM quando si esegue il programma Java, invece di esplicitare quando si costruisce il tuo preambolo C ++.
Dovresti considerare il fatto che le moderne JVM impiegano un sacco di tempo a compilare il codice byte al volo verso il codice macchina nativo per renderlo il più veloce possibile. Ciò consente alla JVM di eseguire tutti i tipi di trucchi del compilatore che possono essere anche migliori conoscendo i dati di profilo del programma in esecuzione.
Esattamente ciò che inline automaticamente un getter, in modo che un JUMP-RETURN non sia necessario per ottenere un valore, acceleri le cose.
Tuttavia, la cosa che ha davvero permesso programmi veloci è meglio ripulire in seguito. Il meccanismo di garbage collection in Java è più veloce rispetto al manuale malloc-free in C. Molte implementazioni moderne senza malloc utilizzano un garbage collector sotto.
Risposta breve - non lo è. Dimenticalo, l'argomento è antico come il fuoco o la ruota. Java o .NET non è e non sarà più veloce di C / C ++. È abbastanza veloce per la maggior parte delle attività in cui non è necessario pensare all'ottimizzazione. Come i moduli e l'elaborazione SQL, ma è lì che finisce.
Per benchmark, o piccole app scritte da sviluppatori incompetenti sì, il risultato finale sarà che Java / .NET sarà probabilmente vicino e forse anche più veloce.
In realtà, cose semplici come allocare memoria in pila o semplicemente usare memzones uccideranno semplicemente Java / .NET sul posto.
Il mondo dei rifiuti raccolti usa una sorta di memzone con tutta la contabilità. Aggiungi memzone a C e C sarà più veloce proprio lì sul posto. Soprattutto per quei benchmark Java-C "ad alte prestazioni del codice", che vanno così:
for(...)
{
alloc_memory//Allocating heap in a loop is verrry good, in't it?
zero_memory//Extra zeroing, we really need it in our performance code
do_stuff//something like memory[i]++
realloc//This is lovely speedup
strlen//loop through all memory, because storing string length is soo getting old
free//Java will do that outside out timing loop, but oh well, we're comparing apples to oranges here
}//loop 100000 times
Prova ad usare variabili basate sullo stack in C / C ++ (o posizionamento nuovo), traducono in sub esp, 0xff , è una singola istruzione x86, battere quella con Java - non puoi ...
La maggior parte delle volte che vedo quei banchi in cui Java è confrontato con C ++, questo mi fa andare come, wth? Strategie sbagliate di allocazione della memoria, contenitori auto-crescenti senza riserve, multipli di nuovi. Questo non è nemmeno vicino al codice C / C ++ orientato alle prestazioni.
Anche una buona lettura: link
La realtà è che sono entrambi assemblatori di alto livello che fanno esattamente ciò che il programmatore gli dice, esattamente come il programmatore gli dice nell'ordine esatto che il programmatore dice loro. Le differenze di rendimento sono così ridotte da non avere alcun significato a tutti gli scopi pratici.
La lingua non è "lenta", il programmatore ha scritto un programma lento. Molto raramente un programma scritto nel modo migliore in una lingua supera (a qualsiasi scopo pratico) un programma che fa la stessa cosa usando il modo migliore della lingua alternativa, a meno che l'autore dello studio non sia in grado di macinare la sua particolare ascia.
Ovviamente se stai andando in un caso raro come i sistemi embedded hard realtime, la scelta della lingua può fare la differenza, ma quanto spesso è così? e di questi casi, quanto spesso la scelta corretta non è ciecamente ovvia.
See the following links ... But how is this even possible? It boggles my mind that interpreted bytecode could ever be faster than a compiled language.
Keith Lea dice che ci sono "evidenti difetti" ma non fa nulla per questi "difetti evidenti". Nel 2005 quelle vecchie attività sono state scartate e sostituite dalle attività ora mostrate nel gioco di benchmark .
Keith Lea dice che "ha preso il codice di riferimento per C ++ e Java dall'ormai obsoleto Great Computer Language Shootout e ha eseguito i test" ma in realtà he mostra solo le misurazioni per 14 su 25 di questi test obsoleti .
Keith Lea ora ti dice che non stava cercando di dimostrare nulla con il post del blog sette anni prima, ma all'epoca disse "Ero stufo di sentire la gente dire che Java era lento, quando so che è piuttosto veloce ... "che suggerisce allora c'era qualcosa che stava cercando di dimostrare.
Christian Felde ti dice "Non ho creato il codice, ho appena ripreso i test". come se questo lo assolva da ogni responsabilità per la sua decisione di pubblicizzare le misurazioni dei compiti e dei programmi selezionati da Keith Lea.
Le misurazioni di persino 25 minuscoli programmi minuscoli forniscono una prova definitiva?
Quelle misure sono per i programmi eseguiti come "modalità mista" Java non interpretato Java - "Ricorda come funziona HotSpot . " Puoi facilmente scoprire quanto bene Java esegue" interpretato da un codice ", perché puoi forzare Java a solo interpretare bytecode - semplicemente tempo con cui alcuni programmi Java vengono eseguiti con e senza l'opzione -Xint .
Mi diverte quanto sia pervasiva questa strana nozione di "interpretato dal codice". Avete mai sentito parlare della compilation JIT? Il tuo argomento non può essere applicato a Java.
Ma lasciando da parte JVM, ci sono casi in cui un codice threaded diretto o anche un'interpretazione bytecode banale può facilmente sovraperformare un codice nativo strongmente ottimizzato. La spiegazione è abbastanza semplice: bytecode può essere abbastanza compatto e si adatta alla tua minuscola cache quando una versione in codice nativo dello stesso algoritmo finirà per avere diversi errori di cache per una singola iterazione.
JIT, GC e così via a parte, C ++ può essere molto, molto facilmente reso molto più lento di Java. Questo non comparirà nei benchmark, ma la stessa app scritta dallo sviluppatore Java e uno sviluppatore C ++ potrebbe essere molto più veloce in Java.
Per quanto riguarda i modelli di ereditarietà avanzati, questi sono molto simili - il C ++ ne ha alcuni che non fanno Java e viceversa, ma tutti presentano anche un overhead significativo e simile. Quindi nessun vantaggio speciale in C ++ nella programmazione a oggetti.
Un altro avvertimento: GC può essere più veloce o più lento rispetto alla gestione manuale delle allocazioni. Se si assegnano molti piccoli oggetti, nell'ambiente GC di solito viene allocato un blocco di memoria e le parti vengono inviate come necessario per i nuovi oggetti. In gestione - ogni oggetto = l'allocazione separata richiede tempo significativo. OTOH, se tu metti un malloc () molta memoria in una volta sola e poi assegni semplicemente parti di essa ai tuoi oggetti manualmente, o usi poche istanze più grandi di oggetti, potresti venire molto più velocemente.
In qualche modo Stack Exchange non prende i miei altri stackpoint così ... nessuna risposta purtroppo ...
Tuttavia la seconda risposta più votata qui è piena di disinformazione a mio modesto parere.
Un'app arrotolata a mano da un esperto in C / C ++ è SEMPRE molto più veloce di un'applicazione Java, punto. Non c'è 'veloce come Java o Faster'. è solo più veloce, proprio a causa degli elementi che citi di seguito:
Compilazione JIT : ti aspetti che un ottimizzatore automatico abbia l'intelligenza di un programmatore esperto e veda il collegamento tra l'intento e il codice che la CPU eseguirà davvero ??? Inoltre, tutto il JIT che fai è tempo perso rispetto a un programma già compilato.
Garbage Collection è uno strumento che rilascia semplicemente le risorse che un programmatore avrebbe dimenticato di deallocare, in modo più o meno efficiente.
Evidentemente questo può essere solo più lento di quello che un esperto (tu scegliesti il termine) C programmatore farebbe per gestire la sua memoria (e non ci sono perdite nelle app scritte correttamente).
Un'applicazione C ottimizzata per le prestazioni conosce la CPU su cui è in esecuzione, è stata compilata su di essa, altrimenti ciò significa che non hai seguito tutti i passaggi necessari per le prestazioni?
Statistiche di runtime Questo è al di là delle mie conoscenze, ma sospetto che un esperto in C abbia più che sufficienti conoscenze di previsione delle filiali per superare di nuovo l'ottimizzazione automatica -
Librerie molto buone Ci sono molte funzioni non ottimizzate prontamente disponibili attraverso le librerie in Java, e lo stesso vale per qualsiasi lingua, tuttavia le librerie più ottimizzate sono scritte in C, specialmente per calcolo.
La JVM è uno strato di astrazione, che implica entrambe le cose buone, molte delle quali sono sopra, e implica anche che la soluzione generale sia più lenta dalla progettazione.
In generale:
Java non può mai raggiungere la velocità di C / C ++ a causa del modo in cui funziona in una JVM con un sacco di protezione, funzionalità e strumenti.
C ++ ha un chiaro vantaggio nel software ottimizzato, sia per l'informatica che per i giochi, ed è normale vedere che le implementazioni C ++ vincono i concorsi di codifica al punto che le migliori implementazioni Java possono essere viste solo sulla seconda pagina.
In pratica il C ++ non è un giocattolo e non ti lascerà sfuggire molti errori che la maggior parte dei linguaggi moderni può gestire, tuttavia essendo più semplice e meno sicuro, è intrinsecamente più veloce.
E come conclusione, vorrei dire che la maggior parte delle persone non dà due centesimi al riguardo, che alla fine l'ottimizzazione è uno sport riservato solo a pochissimi utenti fortunati e che, tranne nei casi in cui le prestazioni sono davvero è una preoccupazione (iE in cui la moltiplicazione dell'hardware per 10 non ti aiuterà - o rappresenterà almeno qualche milione), la maggior parte dei manager preferirà un'app non ottimizzata e una tonnellata di hardware.
Ho visto almeno due impressionanti mmo in Java, per dire che non è abbastanza veloce per i giochi è un termine improprio. Solo perché i progettisti di giochi preferiscono il C ++ in più rispetto ad altri linguaggi, si dice che semplicemente non è solo relativo a Java, significa semplicemente che i programmatori non hanno mai realmente usato altri paradigmi / linguaggi di programmazione. Qualunque cosa in una lingua così avanzata come C / C ++ o anche Java può produrre codice che potrebbe tecnicamente incontrare o sconfiggere l'argomento della velocità. Tutto ciò che va bene e detto si riduce a ciò che i programmatori sanno, quali team lavorano con il più e più importante perché usano tali strumenti. Dal momento che stiamo affrontando l'aspetto dello sviluppo del gioco della programmazione, allora ci deve essere di più nell'argomento. In poche parole, si tratta di soldi e tempo per un business dead impostato sull'utilizzo di strumenti che soddisfano il QA e nel mondo reale non ha alcun peso sulle ragioni xx per scegliere C ++ su Java o qualsiasi altra lingua. È solo una decisione di produzione di massa. Al livello più elementare degli algoritmi di calcolo con cui stiamo giocando solo uno e zero, l'argomento della velocità è uno degli argomenti più stupidi mai applicati al gioco. Se si desidera che i guadagni di velocità peggiorino, allora abbandonare completamente i linguaggi di programmazione e lavorare con l'assembly che è probabilmente il miglior vantaggio di gran lunga.
Leggi altre domande sui tag java c++ performance