Perché il software Java non è compilato in modo nativo?

Question

Realizzo lo benefits di codice bytecode e nativo (portabilità).

Ma dire che si sa sempre che il codice verrà eseguito su un'architettura x86, perché non compilarlo per x86 e ottenere il vantaggio delle prestazioni?

Si noti che sto assumendo che ci sia un guadagno di prestazioni nella compilazione del codice nativo. Alcune persone hanno risposto che ci potrebbe in effetti essere nessun guadagno, che è una novità per me ..

Answer 1

Perché il guadagno di prestazioni (se presente) non vale la pena.

Inoltre, garbage collection è molto importante per le prestazioni. Le probabilità sono che il GC della JVM sia migliore di quello incorporato nell'eseguibile compilato, ad esempio con GCJ.

E la compilazione just in time può anche portare a prestazioni migliori perché la JIT dispone di maggiori informazioni disponibili per ottimizzare la compilazione rispetto al compilatore in fase di compilazione. Vedi la pagina di Wikipedia su JIT.

Answer 2

Il bytecode viene eseguito in una Java Virtual Machine che è compilato per (ad esempio) di Solaris. Sarà ottimizzato come diamine per quel sistema operativo.

In casi reali, si vede spesso vedere prestazioni uguali o migliori dal codice Java in fase di esecuzione, in virtù del fatto di basarsi sul codice della macchina virtuale per cose come la gestione della memoria - il codice si è evoluto e sta maturando da anni.

La JVM offre più vantaggi rispetto alla semplice portabilità: ad esempio, ogni volta che viene rilasciata una nuova JVM, il codice bytecode compilato ottiene ottimizzazioni, miglioramenti algoritmici ecc. Che provengono dai migliori del settore. D'altra parte, una volta compilato il codice C, è tutto.

Answer 3

Perché con la compilazione Just-In-Time, c'è un vantaggio di prestazioni insignificante.

In realtà, molte cose JIT possono effettivamente fare più velocemente.

Answer 4

È già compilato da JIT nel codice nativo di Solaris, dopo l'esecuzione. Non puoi ricevere altri vantaggi se lo compili prima di caricarlo sul sito di destinazione.

Answer 5

"Solaris" è un sistema operativo, non un'architettura CPU. La JVM installata sulla macchina effettiva verrà compilata secondo le istruzioni native della CPU. Solaris potrebbe essere l'architettura SPARC, x86 o x86-64.

Inoltre, il compilatore JIT può rendere ottimizzazioni specifiche del processore a seconda della famiglia di CPU attuale. Ad esempio, sequenze di istruzioni diverse sono più veloci su CPU Intel rispetto alle CPU AMD e un compilatore JIT per la tua esatta piattaforma può trarre vantaggio da queste informazioni per produrre codice altamente ottimizzato.

Answer 6

Si può, o non si può ottenere un beneficio di prestazioni. Ma più probabilmente si otterrebbe una penalizzazione delle prestazioni: l'ottimizzazione JIT non è possibile con la compilazione statica, quindi le prestazioni sarebbero buone solo se il compilatore può renderle "bendate" (senza effettivamente profilare il programma e ottimizzarlo di conseguenza, che è ciò che Compilatori JIT come fa HotSpot).

È sorprendentemente intuitivo quanto sia economica la compilazione (in termini di risorse) e quanto possa essere ottimizzato automaticamente semplicemente osservando il programma in esecuzione. Magia nera, ma buona per noi :-)

Answer 7

Tutto questo parlare di JITs è di circa sette anni non aggiornato. BTW. La tecnologia in questione ora si chiama HotSpot e non è solo una JIT.

Answer 8

Immagino perché la compilazione JIT (just in time) è molto avanzata.

Answer 9

"perché non quindi compilare per x86"

Perché allora non si può sfruttare le caratteristiche specifiche di particolare cpu sarà eseguito su. In particolare, se vogliamo leggere "compile per x86" come "produrre codice nativo che può essere eseguito su un 386 e i suoi discendenti", il codice risultante non può contare su qualcosa di vecchio come le istruzioni mmx.

In questo modo, il risultato finale è che è necessario compilare per ogni architettura esatta su cui verrà eseguito (per quanto riguarda quelli che non esistono ancora) e richiedere all'installatore di selezionare quale file eseguibile mettere in atto. Oppure, sento che il compilatore intel C++ produrrà diverse versioni della stessa funzione, che differiscono solo dalle funzioni della cpu usate, e scelgono quella giusta in fase di esecuzione in base a ciò che la CPU riporta come disponibile.

D'altra parte, è possibile visualizzare il codice byte come sorgente "semi-compilata", simile a un formato intermedio che un compilatore nativo (a meno che non venga richiesto) non scriverà effettivamente sul disco. L'ambiente runtime può quindi eseguire la compilazione finale, sapendo esattamente quale architettura verrà utilizzata. Questo è il motivo per cui un codice C# /. Net potrebbe leggermente sovraperformare il codice C++ su alcune attività cpu-intensive in alcuni benchmark qualche tempo fa.

La "compilazione finale" di bytecode può anche fare ipotesi di ottimizzazione aggiuntive che sono (da una prospettiva di compilazione statica) distintamente non sicure * e ricompilare solo se tali ipotesi sono state trovate errate in seguito.