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

[Unrue]

Originariamente inviato da jappilas

so cos'è la brach prediction
ma quelle che avevo in mente prima (chiedo scusa, nella fretta ho formulato il post precedente in modo poco chiaro ) erano non tanto penalità da branch misprediction, ma cache miss
se il blocco di codice coperto dalla prima condizione (non verificata) è lungo, quello seguente, non essendo "locale" al primo, resterà escluso dal prefetch in cache della prima istruzione di test e di quelle attigue - al che entrarvi comporterà un cache miss ( questo anche se il processore eseguisse il branch corretto nella totalità dei casi, cioè se il branch predictor avesse un ' accuratezza del 100%, cosa che anche con i predittori attuali a tabelle multiple, non avviene - la precisione si attesta sul 97% - motivo per cui su certi processori l' instruction scheduling interno avviene in modo ottimistico, ignorando il responso della BP per, eventualmente e successivamente, ripetere il flusso di esecuzione corretto, dal branch in avanti ... certo, si potrebbe obiettare che su quegli stessi processori la L1I allinea le micro-ops sulle cache lines, sequenziando direttamente un flusso di esecuzione che copre i salti condizionati, quindi un' ottimizzazione di questo tipo potrebbe avere valenza relativa, però... )
se la seconda condizione è quella più frequentemente verificata ( cosa che un compilatore C/C++ statico che non inferisce sulla condizioni di runtime, non ha modo di sapere a priori ), e se l' intera sequenza è racchiusa in un loop, quel loop sarà tipicamente inefficiente
ed è qui che può assumere rilevanza il profiling od anche un compilatore JIT che ottimizzi l' ordine dei blocchi di codice, che è quello che intendevo prima ( e per cui LLVM è nato, anche se LLVM è interessante per tutta una serie di altri aspetti - oltre a poter essere usato come compilatore statico a mo' di alternativa all' ottimizzatore di GCC ...)
ma in effetti si comincia a divagare... LLVM di suo avrebbe le potenzialità per portare notevoli benefici su più fronti, un sistema JIT su altri ( non necessariamente e non solo in relazione con la portabilità o con il profiling delle applicazioni), mentre il thread verteva su java

ps: tanti auguri

Auguri anche a te !Mi fa piacere che conosci bene la branch-prediction La tua analisi è molto interessante, è chiaro che C/C++ staticamente non possono ottimizzare i cache-miss, ma se lo fai a mano puoi è come. Ovviamente è più lungo , dispendioso e richiede una buona esperienza. Se Java fa questo a runtime ben venga, anche se non credo, altrimenti ci sarebbero differenze prestazionali davvero notevoli. Nel' articolo Dinamo postato prima si parla di un 20% in più, non è che sia chissà cosa. Trall'altro, come si spiegano allora quei grafici postati all'inizio in cui si vede Java che è sempre sotto a C++ anche se di poco?Fa il profiling a runtime e ciò nonostante va peggio di C++? C'è qualcosa che non torna..

Inoltre cari javisti spiegatemi una cosa Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.

[franksisca]

Originariamente inviato da Unrue

Inoltre cari javisti spiegatemi una cosa Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a mandare tutto quanto?Come mai in C++ questo non succede? Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.

e questo dove l'hai sentita???

io faccio fare tutto in un (ovviametne seguendo patter specifici)...è acnhe vero che io non faccio applicazioni grosse.....semplici programmini(per ora).

comunque credo che da dati pratici la discussione si stia spostando su "ideologie".

io credo che il tutto si possa riassumere così:

C++ è più performate se lo sai scrivere a dovere, ma se conosci java e non devi per "forza di cose" usare c++, allora java è ottimo anche a livello prestazionale.


ho sbagliato con la sintesi??

[Unrue]

L'ho sentita e sperimentata più volte di persona Non è un mistero questa cosa dei refresh. Spiegatemela su, perchè sinceramente non l'ho mai capita

[franksisca]

Originariamente inviato da Unrue

L'ho sentita e sperimentata più volte di persona Non è un mistero questa cosa dei refresh. Spiegatemela su, perchè sinceramente non l'ho mai capita

allora, una cosa è che si sceglie di farlo in questo modo, un'altra è che si è costretti.

s si sceglie, chiedilo a chi lo fà, non a me.

io ti posso dire che secondo me può essere una scelta furba per alleggerire il sistema(usando i thread lo stesso spazio di memoria).


poi, ripeto, ognuno la pensa come vuole.

[^TiGeRShArK^]

Originariamente inviato da 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.

Originariamente inviato da wikipedia

Adaptive optimization

Adaptive optimization is a technique in computer science that performs dynamic recompilation of portions of a program based on the current execution profile. With a simple implementation, an adaptive optimizer may simply make a trade-off between Just-in-time compilation and interpreting instructions. At another level, adaptive optimization may take advantage of local data conditions to optimize away branches and to use inline expansion to decrease context switching.


Register allocation improvements

Prior to Java 6, allocation of registers was very primitive in the "client" virtual machine (they did not live across blocks), which was a problem in architectures which did not have a lot of registers available, such as x86 for example. If there are no more registers available for an operation, the compiler must copy from register to memory (or memory to register), which takes time (registers are typically much faster to access). However the "server" virtual machine used a color-graph allocator and did not suffer from this problem.

An optimization of register allocation was introduced in this version: [7]; it was then possible to use the same registers across blocks (when applicable), reducing accesses to the memory. This led to a reported performance gain of approximately 60% in some benchmarks. [8]

In this example, the same register could be used for result, and the doSomethingElse method.

public int doSomething() {
int result = 1;
for (int i = 0; i < 10000; i++) {
result = result + doSomethingElse(i * 20);
}
return result;
}
private int doSomethingElse(int value) {
return value * 10;
}

non è un un full-profiling al runtime, cmq il codice viene dinamicamente adattato in base alle condizioni attuali.

[Unrue]

Originariamente inviato da franksisca

allora, una cosa è che si sceglie di farlo in questo modo, un'altra è che si è costretti.

s si sceglie, chiedilo a chi lo fà, non a me.

io ti posso dire che secondo me può essere una scelta furba per alleggerire il sistema(usando i thread lo stesso spazio di memoria).


poi, ripeto, ognuno la pensa come vuole.

Anche secondo me è una scelta furba, solo che spesso e volentieri sono costretto a farlo perchè sennò l'applicazione non fa il refresh, se non alla fine!! Ora,non sono un mostro nella programmazione di grafica in Java, ma questa cosa l'ho sentita spesso in giro. In C++ non mi è mai capitato. Oh, qualcosa vorrà dire.

[^TiGeRShArK^]

Originariamente inviato da 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 ??

questo mi spieghi come fai a farlo sinceramente
Lo puoi fare sicuramente in architetture come il Cell in cui decidi tu quali dati caricare nella memoria locale delle SPE, ma in un'architettura di tipo x86 non hai alcun controllo sulla cache (e vorrei ben dire!) e quindi qualsiasi supposizione vai a fare, a meno che il tuo programma non sia un piccolo kernel dedicato che faccia solo quell'operazione, non è valida dato che varia al variare delle condizioni in cui si trova il processore.

[Unrue]

Originariamente inviato da ^TiGeRShArK^

questo mi spieghi come fai a farlo sinceramente
Lo puoi fare sicuramente in architetture come il Cell in cui decidi tu quali dati caricare nella memoria locale delle SPE, ma in un'architettura di tipo x86 non hai alcun controllo sulla cache (e vorrei ben dire!) e quindi qualsiasi supposizione vai a fare, a meno che il tuo programma non sia un piccolo kernel dedicato che faccia solo quell'operazione, non è valida dato che varia al variare delle condizioni in cui si trova il processore.

Controlli la cache nel senso che adatti il ciclo alla cache stessa, in modo da avere meno cache miss possibili ,non nel senso che te gli dici cosa caricare (cosa credo impossibile)

Io personalmente non ho mai fatto ottimizzazioni a livello di cache, però conosco persone che lo fanno, quindi è possibilissimo

[sottovento]

Originariamente inviato da cionci

sottovento, mi sa che non hai scelto proprio l'esempio migliore

$ time java -classpath . mytest/Main
Alloco un po'...
Time: 63.06

real 1m3.177s
user 1m2.908s
sys 0m0.500s

$ time ./MyTest
Alloco un po'...
Tempo di allocazione: 11

real 0m11.373s
user 0m11.369s
sys 0m0.000s

Well, a questo punto siete in due contro uno
Devo quindi pensare che il problema stia dalla mia parte, anche se ho fatto esperimenti parecchie volte prima di postare, onde evitare brutte figure.

Avevo anche messo la delete[]. Cmq penso sia inutile postare anche il codice Java, visto che e' proprio uguale. Devo capire come mai ho queste prestazioni.

Non per fare il cocciuto, ma resto ancora convinto di quanto scritto prima: Java (come altre piattaforme managed) hanno la possibilita' di fare ottimizzazioni a livello globale, certamente ad un livello piu' alto di quanto possa fare C++.
Ovviamente con C++ si puo' fare tutto quello che fa Java, naturalmente scrivendolo da zero...

[^TiGeRShArK^]

Originariamente inviato da Unrue

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

Sono due discorsi diversi.
La branch prediction del processore usa delle euristiche che vanno bene nel circa il 95% dei casi nelle architetture moderne, ma il caso proposto da jappilas mi pare proprio uno di quei casi in cui tale tecnica non funziona correttamente, portando ad uno stallo della pipeline in caso di errore di predizione.

[tomminno]

Originariamente inviato da ^TiGeRShArK^

E sinceramente mi sfugge perchè in C++ il memory leak ti avrebbe preso solo 2 MB in +..
Io credo invece che in quella situazione il problema sarebbe stato se possibile ancora + grave.

Perchè le 2 classi in totale inviano su seriale tanti pacchetti da 100 byte per un totale di circa 2MB di dati, più una serie di eventi per monitorare lo stato di invio, ma questi si scambiano degli interi.
Se in C++ facessi tante "new char [100]" dimenticandomi la delete avrei un memory leak di 2MB, invece il programma C# che già di per se parte con 25MB arriva alla fine del'operazione ad occupare 70MB che non vengono mai rilasciati.
Insomma non saranno memory leak ma 70MB per inviare 4 cavolate in seriale mi sembrano una esagerazione.

[jappilas]

Originariamente inviato da Unrue

Auguri anche a te !Mi fa piacere che conosci bene la branch-prediction La tua analisi è molto interessante, è chiaro che C/C++ staticamente non possono ottimizzare i cache-miss, ma se lo fai a mano puoi è come.

certo
qualsiasi cosa è fattibile avendo a disposizione risorse sufficienti, nel senso di tempo e capacità del programmatore impiegato, e tenendo conto che molto probabilmente l' ottimizzazione spinta renderà il codice meno leggibile e più difficilmente manutenibile (il che si rifletterà in un aumento dei costi della soluzione a lungo termine) - il punto è: considerando ciò, ne vale la pena?
in certi casi può effettivamente valere la pena, ma negli altri risulterà più conveniente scrivere codice più pulito e leggibile che altamente ottimizzato, e affidarsi a strumenti di ottimizzazione dinamica ...

Nel' articolo Dinamo postato prima si parla di un 20% in più, non è che sia chissà cosa.

sì ma cosiderando che Dinamo traduceva (o meglio, "trasformava" ottimizzando, a run time) codice macchina PA8000 (generato da un compilatore che, si può ragionevolmente pensare, vi avesse applicato le ottimizzazioni di cui era capace) in altro codice macchina PA8000, un incremento di prestazioni del 20% è imho tutt' altro che trascurabile (proprio perchè frutto di ottimizzazioni sull' AST del programma intero, che il compilatore originale non aveva modo di applicare)

Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.

veramente, AFAIK, la presenza di almeno due thread sarebbe una caratteristica inerente alla realizzazione di applicazioni GUI- based, quindi interattive
con un solo thread, un' applicazione interattiva consisterebbe in un loop in cui si effettuerebbe un polling degli eventi in ingresso e un aggiornamento della struttura dati interna e della presentazione visuale in base a questi eventi - in occasione dell' invocazione di una system call sincrona o dell' ingresso in una lunga routine di calcolo, l' intera applicazione smetterebbe di rispondere all' input dell' utente fino alla terminazione di queste
per questo motivo è prassi comune per applicazioni di un certa complessità creare thread separati per ridurre la "modalità" dell' interfaccia, ma questo "ad alto livello" è indipendente dal linguaggio ... il meccanismo con cui ciò viene implementato, e il modo di impiegarlo invece possono variare ampiamente rispetto al linguaggio, ad estensioni del linguaggio (ad esempio openMP), o al toolkit grafico (già considerando il C++ esistono *se non ricordo male* toolkit in cui un thread nascosto è creato internamente all' inizializzazione della libreria, e altri in cui la gestione dei messaggi e degli eventi gui è thread-safe, quindi viene supportato un event/message loop per_thread, quindi è possibile adottare un design più scalabile per la propria applicazione )

[Unrue]

Originariamente inviato da ^TiGeRShArK^

Sono due discorsi diversi.
La branch prediction del processore usa delle euristiche che vanno bene nel circa il 95% dei casi nelle architetture moderne, ma il caso proposto da jappilas mi pare proprio uno di quei casi in cui tale tecnica non funziona correttamente, portando ad uno stallo della pipeline in caso di errore di predizione.

Quindi? Io stavo puntualizzando il fatto che la branch-prediction non c'entra nulla con il linguaggio di programmazione usato.

[^TiGeRShArK^]

Originariamente inviato da Unrue

Ma scusami tanto.. quando ho parlato di codice C++ ottimizzato per l'hardware, mi hai linkato quell'articolo Dinamo( molto interessante trall'altro). E poi si scopre che molto probabilmente Java non adotta quelle tecniche? Ma allora .. Continua a valere il mio discorso. Che, almeno per adesso, un programma C++ ottimizzato con l'hardware è più veloce di un analogo Java

teoricamente si.
Nelle applicazioni REALI tali differenze sono, a parte casi particolari, negligibili dato che in un sistema reale non è solo il tuo programma a girare ma gira una quantità enorme di servizi e il tuo programma, compilato staticamente, non potrà sapere a priori quale tipo di ottimizzazione darà i risultati migliori.

Un'altra tecnica implementata nella JVM a partire da Java 6 è la seguente:

In programming language compiler optimization theory, escape analysis is a method for determining the dynamic scope of pointers. It is related to pointer analysis and shape analysis.

When a variable (or an object) is allocated in a subroutine, a pointer to the variable can escape to other threads of execution, or to calling subroutines. If a subroutine allocates an object and returns a pointer to it, the object can be accessed from undetermined places in the program — the pointer has "escaped". Pointers can also escape if they are stored in global variables or other data structures that, in turn, escape the current procedure.

Escape analysis determines all the places where a pointer can be stored and whether the lifetime of the pointer can be proven to be restricted only to the current procedure and/or thread.

Optimizations

A compiler can use the results of escape analysis as basis for optimizations:

* Converting heap allocations to stack allocations. If an object is allocated in a subroutine, and a pointer to the object never escapes, the object may be a candidate for stack allocation instead of heap allocation.

* Synchronization elision. If an object is found to be accessible from one thread only, operations on the object can be performed without synchronization.

* Breaking up objects or scalar replacement. An object may be found to be accessed in ways that do not require the object to exist as a sequential memory structure. This may allow parts (or all) of the object to be stored in CPU registers instead of in memory.

In pratica, nonostante non sia un full profiling, questa tecnica, porta notevoli vantaggi nei casi succitati.
La cosa interessante da notare è che *corregge* anche degli eventuali errori di un programmatore.
Se un oggetto o un blocco di codice è dichiarato synchronized, ma viene utilizzato solo all'interno di un unico thread in fase di esecuzione, allora le operazioni lì definite vengono eseguite senza sincronizzazione.

[sottovento]

Conci/Tommino
Sto cercando di capire se e dove sbaglio. Vorrei provare (se possibile) ad avere una base comune.
E' possbile x voi rifare l'esperimento con le due sole variabili a,b? (i.e. eliminare tutto cio' che riguarda buf).

Sul mio computer, questo determina un bel vantaggio di Java. Sarebbe bello vedere gli stessi risultati da un'altra parte, visto che comincio a sentirmi solo

Ripeto mia configurazione: Win XP SP2 1.7 GHz 1Mb RAM

[Unrue]

Originariamente inviato da ^TiGeRShArK^

Se un oggetto o un blocco di codice è dichiarato synchronized, ma viene utilizzato solo all'interno di un unico thread in fase di esecuzione, allora le operazioni lì definite vengono eseguite senza sincronizzazione.

Nessuno nega che Java faccia tante ottimizzazioni carine a runtime, ma come si spiega allora che, nonostante C++ non le faccia, le prestazioni nel grafico che tu hai postato all'inizio sono pressappoco uguali ?

[cionci]

Originariamente inviato da Unrue

Inoltre cari javisti spiegatemi una cosa Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.

Succede anche in C++, con le MFC ad esempio...e quei framework che non te lo fanno vedere hanno comunque un thread dedicato a gestire la GUI

[^TiGeRShArK^]

Originariamente inviato da tomminno

Appunto il problema è che inavvertitamente potresti lasciare referenziato un oggetto che non dovrebbe più esserlo.

Qualche post fa è stato riportato un link a Mokabyte dove viene riportato un esempio di memory leak in Java: nell'esempio il pop su uno stack non impostava a null l'oggetto estratto, così che il GC si trova sempre referenziato l'oggetto e non lo elimina mai.
La dimenticanza equivalente in C++ sarebbe stata la mancata delete, ma che differenza c'è tra dimenticarsi elements[size] = null piuttosto che delete elements[size] ?
In entrambi i casi hai memory leak.

sono due cose ESTREMAMENTE diverse.
Un oggetto, quando non viene + utilizzato, allora viene automaticamente deallocato.
Gli unici problemi in Java ci possono essere quando tra i campi di una classe ci sono strutture aventi la funzione di repository di dati o di cache.
In quel caso, mio pare anche *ovvio* che debbano essere implementati dei meccanismi per gestire correttamente la cache o per rimuovere i dati non + necessari.
Quindi non c'entra niente fare elements[size] = null (che tra l'altro non è neanche semanticamente corretto perchè al + dovrebbe essere elements[i] = null ), dato che si suppone che in un'array di dimensione fissa si abbia abbastanza memoria da garantire la memorizzazione di ogni oggetto dell'array, ma il vero problema è fare il remove dalle varie collections.
Tra l'altro, se non erro, mi pare che sia anche sconsigliato porre a null un oggetto dato che si complica inutilmente il codice e si incasina di + il lavoro del GC.

[cionci]

Originariamente inviato da sottovento

Sul mio computer, questo determina un bel vantaggio di Java. Sarebbe bello vedere gli stessi risultati da un'altra parte, visto che comincio a sentirmi solo

Ripeto mia configurazione: Win XP SP2 1.7 GHz 1Mb RAM

Posta i sorgenti C++ e quelli Java...
Almeno partiamo davvero da una base comune
In ogni caso gcc 4.1.3 su Linux e Java 1.6. Il sistema è un Core 2 Duo a 3.2 Ghz.

[shinya]

Originariamente inviato da Unrue

Controlli la cache nel senso che adatti il ciclo alla cache stessa, in modo da avere meno cache miss possibili ,non nel senso che te gli dici cosa caricare (cosa credo impossibile)

Io personalmente non ho mai fatto ottimizzazioni a livello di cache, però conosco persone che lo fanno, quindi è possibilissimo

Colgo la palla al balzo per insinuarmi nella discussione, e a proposito di gestione della cache faccio notare che esiste un paper a riguardo.

paper: http://citeseer.ist.psu.edu/prokop99cacheobliviou.html
wikipedia: http://en.wikipedia.org/wiki/Cache-oblivious_algorithm

Avvertimento: il paper è di quelli da mal di testa!

edit: c'è anche un paper più umano (sembra)... http://www.dunkel.dk/thesis/