[Compiler] Java just-in-time vs C++

[hollywoodundead]

E' vero che il compilatore on the fly di java chiamato just-in-time compiler, riesce a tenere testa (a livello di prestazioni) ad un applicazione scritta in c++ che non ha bisogno di un interprete come la VM?

Riporto la fonte. Libro Core Java Volume I Fundamentals:

In the early days of Java, the language was interpreted. Nowadays, except on “micro” platforms such as cell phones, the Java virtual machine uses a just-in-time compiler. The “hot spots” of your code will run just as fast in Java as they would in C++, and in some cases, they will run faster.

EDIT: Riporto anche la continuazione per completezza:

Java does have some additional overhead over C++. Virtual machine startup time is slow, and Java GUIs are slower than their native counterparts because they are painted in a platform-independent manner.
People have complained for years that Java applications are too slow. However, today’s computers are much faster than they were when these complaints started. A slow Java program will still run quite a bit better than those blazingly fast C++ programs did a few years ago. At this point, these complaints sound like sour grapes, and some detrac- tors have instead started to complain that Java user interfaces are ugly rather than slow.

[pabloski]

Direi che la risposta c'è già in quello che hai citato

"and in some cases, they will run faster."

C'è un dibattito che dura da anni sulle performance dei compilatori just-in-time vs aot.

A meno di seri problemi nello sviluppo di un compilatore jit, è vero che ci sono casi in cui un programma jitted è più veloce di uno compilato aot.

I motivi sono legati principalmente alle possibilità che hanno i compilatori jit di realizzare ottimizzazioni impossibili per un compilatore aot.

[Tommo]

Il problema e' che i test che danno i JIT pari sono per certi versi una presa per il c**o - perche' non testano codice idiomatico del linguaggio.

Nel senso, se prendi codice C e lo traduci paro paro in codice Java e' molto probabile che i tempi viaggino tra 0.9x e 1.5x, che e' un ottimo risultato... ma questo e' un test puramente per il JIT e la VM che non tiene conto ne' delle performance del GC, ne' di quelle della libreria... semplicemente non e' il codice che scriverebbe un programmatore Java tipico.

Ad esempio in Java rimane molto costoso creare piccoli oggetti come Vettori, Colori etc, rispetto a C++... perche' a parte new e delete creare decine di oggetti, indipendentemente dalle dimensioni e' un problema per il garbage collector.
E' anche molto costoso fare chiamate a funzioni, dato che di default sono tutte virtuali (non a caso non c'e' l'overload degli operatori - decisero di non metterlo per "incoraggiare" la gente a sommare le cose a manina ), e se la tua idea e' fare un'esperienza utente fluida c'e' da contare anche il fatto che a random il GC parte e blocca tutti i thread per diversi millisecondi, risultando nei tipici scatti.
In piu' le performance della libreria standard fanno abbastanza schifo e vanno a sbattere contro tutti i limiti di Java stesso (oh the irony), quindi comunque si finisce a usare gli array C-style.

In finale, se usi Java come un linguaggio di alto livello e' lento. Se lo usi a basso livello e' veloce.
Non lo avrebbe mai detto nessuno

[hollywoodundead]

Originariamente inviato da Tommo

Il problema e' che i test che danno i JIT pari sono per certi versi una presa per il c**o - perche' non testano codice idiomatico del linguaggio.

Nel senso, se prendi codice C e lo traduci paro paro in codice Java e' molto probabile che i tempi viaggino tra 0.9x e 1.5x, che e' un ottimo risultato... ma questo e' un test puramente per il JIT e la VM che non tiene conto ne' delle performance del GC, ne' di quelle della libreria... semplicemente non e' il codice che scriverebbe un programmatore Java tipico.

Ad esempio in Java rimane molto costoso creare piccoli oggetti come Vettori, Colori etc, rispetto a C++... perche' a parte new e delete creare decine di oggetti, indipendentemente dalle dimensioni e' un problema per il garbage collector.
E' anche molto costoso fare chiamate a funzioni, dato che di default sono tutte virtuali (non a caso non c'e' l'overload degli operatori - decisero di non metterlo per "incoraggiare" la gente a sommare le cose a manina ), e se la tua idea e' fare un'esperienza utente fluida c'e' da contare anche il fatto che a random il GC parte e blocca tutti i thread per diversi millisecondi, risultando nei tipici scatti.
In piu' le performance della libreria standard fanno abbastanza schifo e vanno a sbattere contro tutti i limiti di Java stesso (oh the irony), quindi comunque si finisce a usare gli array C-style.

In finale, se usi Java come un linguaggio di alto livello e' lento. Se lo usi a basso livello e' veloce.
Non lo avrebbe mai detto nessuno

Questo sarebbe poi il motivo secondo te percui le applicazioni android che sono fatte prevalentemente in java (tranne qualche rara applicazione che debba essere necessariamente performante e allora in quel caso viene scritta in c++) presentano sempre quei rallentamenti tipici ad esempio del samsung galaxy s3 nonostante abbiano una potenza hardware ottima? Mentre invece le app su iphone risultano maggiormente fluide (tranne l'apple store su iphone che è stato ottimizzato male) grazie al fatto che sono scritte in objective-c?

[nico159]

Aggiungo che compilatori più avanzati come GCC e VC++ (MS) hanno qualcosa che si avvicina molto a JIT: profile guided optimizations
http://blogs.msdn.com/b/vcblog/archi...ation-pgo.aspx

Compilatori JIT come la JVM non sfruttano neanche "novità" introdotte dalle cpu 10 anni fa, come il supporto alla vettorizzazione

Inoltre come detto da Tommo la JVM di impone uno stile "generico" di allocamento imposto dalla implementazione del GC scelta all'avvio
In linguaggi con compilatori AOT solitamente manca un GC (alcuni è presente ma disattivabile come in D, altri come Go non puoi gestire la memoria da te)
Un GC non solo impone dell'overhead quando fa il suo lavoro (e con heap sui 4GB, la JVM può farti aspettare anche un paio di minuti ) ma anche quando non entra in funzione ci sono dei costi (write barrier e probabilmente anche altro)
Ma ancora più importante non puoi creare il tuo stile di allocalmento specifico per il problema che ti stai affrontando -- che è dove le performance iniziano a brillare (custom allocator)

Personalmente, non ho mai visto codice "uguale" sulla JVM battere un compilatore con le giuste flags

JIT al momento è un pò come GC: è da 30 anni che si dice, che un giorno saranno più veloci della loro controparte

[nico159]

Originariamente inviato da hollywoodundead

Questo sarebbe poi il motivo secondo te percui le applicazioni android che sono fatte prevalentemente in java (tranne qualche rara applicazione che debba essere necessariamente performante e allora in quel caso viene scritta in c++) presentano sempre quei rallentamenti tipici ad esempio del samsung galaxy s3 nonostante abbiano una potenza hardware ottima? Mentre invece le app su iphone risultano maggiormente fluide (tranne l'apple store su iphone che è stato ottimizzato male) grazie al fatto che sono scritte in objective-c?

Sì, di recente è stato scritto un bell'articolo al riguardo:
http://sealedabstract.com/rants/why-...apps-are-slow/

We feel so strongly about ARC being the right approach to memory management that we have decided to deprecate Garbage Collection in OSX. - Session 101, Platforms Kickoff, 2012, ~01:13:50

At the top of your wishlist of things we could do for you is bringing garbage collection to iOS. And that is exactly what we are not going to do… Unfortunately garbage collection has a suboptimal impact on performance. Garbage can build up in your applications and increase the high water mark of your memory usage. And the collector tends to kick in at undeterministic times which can lead to very high CPU usage and stutters in the user experience. And that’s why GC has not been acceptable to us on our mobile platforms. In comparison, manual memory management with retain/release is harder to learn, and quite frankly it’s a bit of a pain in the ass. But it produces better and more predictable performance, and that’s why we have chosen it as the basis of our memory management strategy. Because out there in the real world, high performance and stutter-free user experiences are what matters to our users. ~Session 300, Developer Tools Kickoff, 2011, 00:47:49

[hollywoodundead]

Possiamo dire quindi che l'unica differenza per quanto riguarda le prestazioni tra java e c++ riguarda fondamentalmente la gestione della memoria, automatica in java tramite il GC e manuale in c++ delegata allo sviluppatore? Forse un tempo java era stato pensato, essendo un linguaggio multipiattaforma per eseguire programmi molto toy, quindi senza particolari richieste di prestazioni, vedi ad esempio Java ME per il mobile. Tuttavia oggi anche le applicazioni piu stupide richiedono prestazioni e gestione della memoria piu che buone per poter funzionare decentemente, il GC di allora non ha subito grosse novita in termini di gestione automatica della memoria. Con il passare del tempo voi penserete che elimineranno il GC quelli di java per implementare una gestione della memoria ibrida come già avviene con l'objective-c e l'ARC,oppure la gestione di memoria da parte del GC andrà a peggiorare con il passare degli anni?

[pabloski]

Originariamente inviato da hollywoodundead

Possiamo dire quindi che l'unica differenza per quanto riguarda le prestazioni tra java e c++ riguarda fondamentalmente la gestione della memoria,

anche ma non solo

come fatto notare da nico159, la jvm hotspot no supporta nemmeno la vettorizzazione...in questo caso si tratta di un modo sicuro per rendere un programma più lento e senza fare nemmeno tanti sforzi

Originariamente inviato da hollywoodundead

Forse un tempo java era stato pensato, essendo un linguaggio multipiattaforma per eseguire programmi molto toy,

no, è solo stato pensato per velocizzare di molto la scrittura dei programmi

loro accettano una penalizzazione in termini di performance, ma ci si guadagna in termini di tempi di sviluppo

ma è una situazione comune a tutti i linguaggi di un certo tipo, a partire da c# fino a python, php, ruby

si paga qualcosa sul fronte performance, per guadagnare qualcosa sul fronte dei tempi di sviluppo

Originariamente inviato da hollywoodundead

Tuttavia oggi anche le applicazioni piu stupide richiedono prestazioni e gestione della memoria piu che buone per poter funzionare decentemente,

la teoria dominante è quella di scaricare sull'hardware questa responsabilità

più core, più gigahertz, più ram

Originariamente inviato da hollywoodundead

Con il passare del tempo voi penserete che elimineranno il GC quelli di java

non lo faranno mai

e comunque le implementazioni della jvm sono tantissime, alcune decisamente migliori di hotspot

ad esempio c'è zing che ha un gc pauseless ( niente lag improvvisi ), oppure excelsior che implementa un compilatore aot per java

la stessa dalvik è profondamente diversa dalla jvm di oracle

Originariamente inviato da hollywoodundead

oppure la gestione di memoria da parte del GC andrà a peggiorare con il passare degli anni?

andrà a migliorare, vista la presenza di sempre più core nei processori moderni

magari le performance per core peggioreranno, ma si rimedierà usando i tanti core a disposizione

[hollywoodundead]

Originariamente inviato da pabloski

anche ma non solo

come fatto notare da nico159, la jvm hotspot no supporta nemmeno la vettorizzazione...in questo caso si tratta di un modo sicuro per rendere un programma più lento e senza fare nemmeno tanti sforzi



no, è solo stato pensato per velocizzare di molto la scrittura dei programmi

loro accettano una penalizzazione in termini di performance, ma ci si guadagna in termini di tempi di sviluppo

ma è una situazione comune a tutti i linguaggi di un certo tipo, a partire da c# fino a python, php, ruby

si paga qualcosa sul fronte performance, per guadagnare qualcosa sul fronte dei tempi di sviluppo



la teoria dominante è quella di scaricare sull'hardware questa responsabilità

più core, più gigahertz, più ram



non lo faranno mai

e comunque le implementazioni della jvm sono tantissime, alcune decisamente migliori di hotspot

ad esempio c'è zing che ha un gc pauseless ( niente lag improvvisi ), oppure excelsior che implementa un compilatore aot per java

la stessa dalvik è profondamente diversa dalla jvm di oracle



andrà a migliorare, vista la presenza di sempre più core nei processori moderni

magari le performance per core peggioreranno, ma si rimedierà usando i tanti core a disposizione

Non li conoscevo quei due gestori di memoria. Quindi se io volessi, e se ne avessi le capacità, potrei creare un GC personalizzato come quello di Zing o Excelsior per rendere il GC di java il piu vicino possibile, in termini di prestazioni alla gestione della memoria di c++ e obj-c?

[pabloski]

Originariamente inviato da hollywoodundead

Non li conoscevo quei due gestori di memoria. Quindi se io volessi, e se ne avessi le capacità, potrei creare un GC personalizzato come quello di Zing o Excelsior per rendere il GC di java il piu vicino possibile, in termini di prestazioni alla gestione della memoria di c++ e obj-c?

Non si tratta di gc ma di implementazioni della java virtual machine.

Sul rendere un gc più performante è possibile, ma per niente banale. Si tratta di campi in cui si fa ancora molta ricerca e ci sono ancora molte discussioni accese.

[hollywoodundead]

Originariamente inviato da pabloski

Non si tratta di gc ma di implementazioni della java virtual machine.

Sul rendere un gc più performante è possibile, ma per niente banale. Si tratta di campi in cui si fa ancora molta ricerca e ci sono ancora molte discussioni accese.

Si ma ad esempio il gc implementato da Zyng aggiunge direttamente delle funzionalità al gc default di java, tramite un algoritmo, offrendo appunto la funzionalità pauseless e quindi modifica direttamente alcune parti di comportamento del tradizionale GC. La JVM in questo caso interpreta solo le modifiche di gestione memoria, ma non viene toccata.

[mone.java]

E per quanto riguarda JRockit qualcuno ne sa qualcosa?

[mone.java]

Rilancio con un'altra domanda... Rivolta a chi di Assembly ne capisce piu di me (il primo che mi viene in mente è cdmauro... ma penso che per quante ne so io il mio gatto ha una maria in più)

Queste ottimizzazioni (es vettorizzazione) non vengono fatte perché nessuno si è messo li a implementarle oppure perché sono troppo dispendiose da fare a runtime, cioè un compilatore standard può "metterci il tempo che vuole e occupare la memoria che vuole" mentre un compilatore JIT deve tener conto che ha il programma in esecuzione...

Detto questo non converrebbe fare una sorta di cache locale con l'assembly generato al primo avvio ad esempio... e poi fare ottimizzazioni su di essa quando il programma non ha richieste particolari di CPU?

[cdimauro]

Sto partendo per la Germania, quindi ho difficoltà a scrivere con lo smartphone, per cui sarò sintetico.
Si, si può fare ciò che chiedi, ma... qualcuno deve rimboccarsi le maniche. Ed è anche corretto che un compilatore JIT possa generare una prima versione "grezza", per poi affinare e generare codice ancora più ottimizzato man mano che raccoglie informazioni a runtime. Ci sono parecchi studi in merito; cerca HP dynamo.
Comunque il vantaggio di usare un intermediate language al posto binario puro è rimane possibile eseguire una compilazione AoT ottimizzata per quella particolare piattaforma, grazie alle maggiori informazioni (e astrazione). Ad esempio compilare per un'architettura inesistente al momento della compilazione in IL.
Qualcosa del genere si potrebbe anche fare partendo dal binario puro, ma sarebbe molto più complicato.

[marco.r]

Originariamente inviato da hollywoodundead

E' vero che il compilatore on the fly di java chiamato just-in-time compiler, riesce a tenere testa (a livello di prestazioni) ad un applicazione scritta in c++ che non ha bisogno di un interprete come la VM?

Riporto la fonte. Libro Core Java Volume I Fundamentals:


EDIT: Riporto anche la continuazione per completezza:

In teoria e' vero, in pratica oltre al compilatore in se' ci sono un altro paio di fattori da tenere in considerazione.

* Per ottenere certi risultati bisogna scrivere codice Java in modo meno idiomatico (tipicamente "alla C"). Questo puo' non essere un problema se si decide di farlo solo nelle parti piu' critiche per le performace
* Prima o poi bisogna usare delle librerie e queste possono avere performance buone o performance cattive. In particolare pero' nota che le librerie standard del C++ sono state scritte con le performance in mente, per cui anche se piu' difficili da utilizzare mediamente permettono di spremere meglio le risorse della macchina. Quelle di Java il piu' delle volte sono state sviluppate con la facilita' e correttezza d'uso come prima regola.
* Fattore "Enterprise". In un linguaggio umano, se devi generare delle immagini server-side userai una libreria con cui crei un oggetto PngImage, manipoli i Pixel, e la salvi su un array di byte per mandarlo al client.
In Java, molto probabilmente dovrai utilizzare un generico MultiMediaObjectGenerator che potrai modificare accedendo ai suoi MultiMediaItemPart , e che poi manderai al client con un qualsiasi AbstractCommunicationChannel. Tutti e tre descritti da specifiche diverse, ognuno implementato da cinque librerie diverse. Cosi' quando vorrai invece che mandare delle immagini via tcp vuoi mandare degli mp3 via smtp, potrai farlo "solo" cambiando le annotations delle tue classi. Basta che non ti lamenti delle performance, o degli stack trace da 100 e piu' metodi, di cui forse 2 sono stati scritti da te.

[marco.r]

Originariamente inviato da mone.java

Rilancio con un'altra domanda... Rivolta a chi di Assembly ne capisce piu di me (il primo che mi viene in mente è cdmauro... ma penso che per quante ne so io il mio gatto ha una maria in più)

Queste ottimizzazioni (es vettorizzazione) non vengono fatte perché nessuno si è messo li a implementarle oppure perché sono troppo dispendiose da fare a runtime, cioè un compilatore standard può "metterci il tempo che vuole e occupare la memoria che vuole" mentre un compilatore JIT deve tener conto che ha il programma in esecuzione...

Detto questo non converrebbe fare una sorta di cache locale con l'assembly generato al primo avvio ad esempio... e poi fare ottimizzazioni su di essa quando il programma non ha richieste particolari di CPU?

Penso sia dovuto soprattutto a mancanza di richieste. Java e' usato soprattutto lato server, non tanto per number crunching quanto per logica di business o servizi web, dove questo tipo di ottimizzazioni hanno una utilita' relativa.
Visto che storicamente le librerie performanti sono sempre state scritte in Fortran, C, C++, risulta molto piu' comodo utilizzare un linguaggio di scripting che si appoggi a queste (Python, ad esempio ma non solo) che non Java.

[shinya]

Originariamente inviato da marco.r

* Fattore "Enterprise". In un linguaggio umano, se devi generare delle immagini server-side userai una libreria con cui crei un oggetto PngImage, manipoli i Pixel, e la salvi su un array di byte per mandarlo al client.
In Java, molto probabilmente dovrai utilizzare un generico MultiMediaObjectGenerator che potrai modificare accedendo ai suoi MultiMediaItemPart , e che poi manderai al client con un qualsiasi AbstractCommunicationChannel. Tutti e tre descritti da specifiche diverse, ognuno implementato da cinque librerie diverse. Cosi' quando vorrai invece che mandare delle immagini via tcp vuoi mandare degli mp3 via smtp, potrai farlo "solo" cambiando le annotations delle tue classi. Basta che non ti lamenti delle performance, o degli stack trace da 100 e piu' metodi, di cui forse 2 sono stati scritti da te.

SI MA VUOI METTERE I VANTAGGIH!!1

[hollywoodundead]

OT: cidimauro è un altro dei tanti in fuga per l'estero, in questo caso the germany?

[cdimauro]

Sì, Ulm per la precisione. Non potevo far morire di fame la mia famiglia.

In Sicilia è molto difficile trovare un lavoro, e tante volte viene schiavizzato. Spostarmi dalla Sicilia verso Roma o in sù avrebbe significato scendere comunque nella mia terra un paio di volte l'anno, prendendo uno stipendio che mi avrebbe permesso di sopravvivere.

Allora tanto vale espatriare, perché c'è tutto da guadagnare. Intanto basta uscire appena fuori dall'Italia e il salario è molto più elevato (ovviamente in paesi come Svizzera, Germania, ecc.; in Europa la situazione non è tutta la florida).

Poi anche perché il valore e il merito vengono apprezzati, premiati, e... molto ricercati. Cercando lavoro all'estero, se sei discretamente bravo, la situazione diventa l'opposto che in Italia: a volte hai l'imbarazzo della scelta, e spesso sono le aziende che cercano te e non il viceversa.

Per non parlare poi dell'ambiente di lavoro, ma in generale anche dell'ambiente (civile) in cui vivi: i servizi funzionano MOLTO bene, c'è parecchia pulizia, ordine, e rispetto degli altri. Ovviamente non è tutto perfetto, ma la differenza con l'Italia è lampante. Qui ti preoccupi se l'autobus è in ritardo di un paio di minuti; e se non sei presente alla fermata all'orario previsto, c'è una discreta possibilità che tu l'abbia perso perché l'autista ha spaccato il secondo; ma lo stesso autista si ferma e ASPETTA alla fermata se per caso è arrivato troppo presto alla tappa prevista (ha un monitor LCD touchscreen in cui è mappato tutto, secondo per secondo).

Chi fosse ancora indeciso sul da farsi, può immaginare, quindi, quale sia il mio consiglio.

Tornando al topic, rispondo al volo a marco.r su un punto (sul resto mi trovo sostanzialmente d'accordo). La libreria standard C++ non è stata pensata per le prestazioni. Ricordo che per lo meno per il test della presenza di un elemento in un set oppure di una chiave in una mappa, il tempo era O(log n) e non O(1), come invece capita in altri linguaggi. Non so se la situazione è cambiata in questi anni, per cui mi fermo qui.

[hollywoodundead]

Originariamente inviato da cdimauro

Sì, Ulm per la precisione. Non potevo far morire di fame la mia famiglia.

In Sicilia è molto difficile trovare un lavoro, e tante volte viene schiavizzato. Spostarmi dalla Sicilia verso Roma o in sù avrebbe significato scendere comunque nella mia terra un paio di volte l'anno, prendendo uno stipendio che mi avrebbe permesso di sopravvivere.

Allora tanto vale espatriare, perché c'è tutto da guadagnare. Intanto basta uscire appena fuori dall'Italia e il salario è molto più elevato (ovviamente in paesi come Svizzera, Germania, ecc.; in Europa la situazione non è tutta la florida).

Poi anche perché il valore e il merito vengono apprezzati, premiati, e... molto ricercati. Cercando lavoro all'estero, se sei discretamente bravo, la situazione diventa l'opposto che in Italia: a volte hai l'imbarazzo della scelta, e spesso sono le aziende che cercano te e non il viceversa.

Per non parlare poi dell'ambiente di lavoro, ma in generale anche dell'ambiente (civile) in cui vivi: i servizi funzionano MOLTO bene, c'è parecchia pulizia, ordine, e rispetto degli altri. Ovviamente non è tutto perfetto, ma la differenza con l'Italia è lampante. Qui ti preoccupi se l'autobus è in ritardo di un paio di minuti; e se non sei presente alla fermata all'orario previsto, c'è una discreta possibilità che tu l'abbia perso perché l'autista ha spaccato il secondo; ma lo stesso autista si ferma e ASPETTA alla fermata se per caso è arrivato troppo presto alla tappa prevista (ha un monitor LCD touchscreen in cui è mappato tutto, secondo per secondo).

Chi fosse ancora indeciso sul da farsi, può immaginare, quindi, quale sia il mio consiglio.

Tornando al topic, rispondo al volo a marco.r su un punto (sul resto mi trovo sostanzialmente d'accordo). La libreria standard C++ non è stata pensata per le prestazioni. Ricordo che per lo meno per il test della presenza di un elemento in un set oppure di una chiave in una mappa, il tempo era O(log n) e non O(1), come invece capita in altri linguaggi. Non so se la situazione è cambiata in questi anni, per cui mi fermo qui.

OT: Ma fai bene, io ho sempre detto che se prendi una laurea in informatica o hai già abbastanza esperienza alle spalle, e rimani in italia, ora come ora sei un cretino . L'estero come junior developer prendi 3000 sterline lorde che sono 2500 sterline circa nette. Trasformale in € e hai 3000€ netti, ripeto netti. La fonte, un conoscente che lavora a londra.