.NET runtime vs. Java Hotspot: .NET è una generazione indietro?

Question

Secondo le informazioni che ho potuto raccogliere in ambiente di esecuzione NET e Java, la situazione attuale è segue:

• moderna Java VM sono in grado di eseguire ricompilazione continuo, che combinata con profilatura può produrre grandi prestazioni miglioramenti. Le JVM più anziane hanno utilizzato il JIT. maggiori informazioni in questo articolo: http://www.ibm.com/developerworks/library/j-jtp12214/ ed in particolare: Java theory and practice: Dynamic compilation and performance measurement

• .NET utilizza JIT o NGEN per generare codice nativo, ma una volta che viene generato il codice nativo, senza ulteriori vengono eseguite (runtime) ottimizzazioni.

Benchmark a parte e con nessuna intenzione di intensificare guerre sante, questo significa che Java Hotspot VM è una generazione avanti di .Net. Queste tecnologie utilizzate in Java VM potranno finalmente trovare la sua strada in .NET runtime?

Answer 1

Non ho mai confrontato i due per confrontare, e ho più familiarità con la JVM Sun, posso solo parlare in termini generali di JIT.

Ci sono sempre dei compromessi con le ottimizzazioni e non tutte le ottimizzazioni funzionano sempre. Tuttavia, ecco alcune moderne tecniche di JIT.Penso che questo possa essere l'inizio di una buona conversazione, se ci atteniamo al materiale tecnico:

• analisi fuga
• intrinsics
  • http://bugs.sun.com/view_bug.do?bug_id=6823354
  • http://weblog.ikvm.net/CommentView.aspx?guid=0404dd8a-88a8-4d62-9bcb-98324d57a2a9
• tail-call optimization
• sostituzioni on-stack t
• coarsening blocco
• lock elision
• multi-threaded garbage collection
• basso pausa garbage collection
• polymorphic method call removal
• fast heap allocation

C'è anche funzioni utili per quanto buono implementazioni di una VM andare:

• essere in grado di scegliere tra GC
• implementazioni personalizzazione di ogni GC
• parametri di assegnazione mucchio (quali la crescita)
• pagina bloccaggio

Sulla base di queste caratteristiche e molti altri, possiamo Confronta VM, e non solo "Java" rispetto a ".NET", ma, ad esempio, Sun's JVM contro IBM JVM contro .NET contro Mono.

Ad esempio, JVM di Sun non esegue l'ottimizzazione tail-call, IIRC, ma lo fa l'IBM.

Answer 2

A quanto pare qualcuno stava lavorando su qualcosa di simile per Rotor. Non ho accesso a IEEE, quindi non posso leggere l'abstract.

Dynamic recompilation and profile-guided optimisations for a .NET JIT compiler

preventivo da Sommario ...

Una valutazione del quadro utilizzando una serie di programmi di test mostra che prestazioni possono migliorare al massimo del 42,3% e 9% in media. nostri risultati mostrano anche che le spese generali di raccolta profilo accurato informazioni attraverso strumentazione misura superano i benefici di ottimizzazioni profilo-guida nel nostro attuazione, suggerendo la necessità di tecniche che possono ridurre tali spese generali di attuazione .

Answer 3

Seguono due diverse strategie. Non penso che uno sia migliore dell'altro.

• .NET non interpretare il bytecode, quindi deve JIT tutto come viene viene eseguito e quindi non può ottimizzare pesantemente a causa di vincoli di tempo. Se hai bisogno di grosse ottimizzazioni in qualche parte del codice, puoi sempre farlo manualmente con NGEN, oppure fare un'implementazione veloce ma unsafe. Inoltre, calling native code is easy. L'approccio qui sembra ottenere il tempo di esecuzione abbastanza buono e ottimizzare manualmente i colli di bottiglia.

• Le JVM moderne di solito interpretano la maggior parte del codice e quindi eseguono una compilazione ottimizzata dei colli di bottiglia. Questo di solito ottiene risultati migliori rispetto al JITing diretto, ma se hai bisogno di più, non hai unsafe in Java e calling native code is not nice. Quindi l'approccio qui è quello di eseguire il più possibile l'ottimizzazione automatica, perché le altre opzioni non sono così buone.

In realtà le applicazioni Java tendono a presentare prestazioni leggermente migliori nel tempo e peggio nello spazio rispetto a .NET.

Answer 4

Potresti essere interessato a SPUR che è un compilatore Tracing JIT. Il focus è su javascript ma funziona su CIL e non sul linguaggio stesso. È un progetto di ricerca basato su Bartok e non su .NET VM standard. Il documento presenta alcuni benchmark delle prestazioni che mostrano 'esegue in modo coerente più veloce di SPUR-CLR' che è lo standard 3.5 CLR. Tuttavia non ci sono stati annunci sul suo futuro relativo alla VM attuale. Le tracce possono attraversare i limiti del metodo che non è qualcosa HotSpot fa AFAIK, JIT JIT di tracciamento sono menzionati here.

Sarei titubante nel dire che .NET VM è una generazione indietro soprattutto se si considerano tutti i sottosistemi, in particolare i generici. In che modo lo GC e il DLR vs confronto invocato dinamico non sono sicuro ma ci sono molti dettagli su di loro in posti come channel9.