[Java] Prestazioni diverse a 32 o 64 bit??

Lim · 31-03-2011, 13:36

Ho sviluppato un simulatore in Java che deve manipolare un elevato numero di oggetti.
Ho cercato di implementare il multi-thread dove possibile ed ora sto lanciando le simulazioni su diverse macchine macchine virtuali a 32bit ed a 64bit.
Ogni macchina possiede 4 core e 8GB di ram (per le versioni a 64bit) o 3GB di ram (per le versioni a 32bit).
Il sistema operativo è Ubuntu Server 10.10 (ovviamente a 32 e 64 bit)

Bene, lanciando le simulazioni sulle due tipologie di macchine, ottengo prestazioni leggermente differenti. Poiché, al momento non ho bisogno di un grande quantitativo di ram, pensavo che non fosse giustificabile l'utilizzo di una macchina a 64bit, poiché sicuramente introduce un overhead nella gestione degli indirizzi di memoria. Invece, le macchine a 64bit sembrano occupare meno risorse (l'occupazione della CPU è circa il 10% inferiore) e le simulazioni sembrano essere "leggermente" più veloci.

Che sia legato al sistema operativo? (magari la versione a 64bit è più ottimizzata?)

dierre · 31-03-2011, 13:47

Premettendo che non sono un esperto di concorrenza quindi lascio volentieri la parola a qualcuno con più esperienza, ma in generale la situazione è questa: Java è ovviamente un linguaggio che cerca di astrarre il più possibile cioè che c'è sotto e capita delle volte, soprattutto nei casi in cui vengono scomodate operazioni a basso livello (a me è capitato con la copia dei file nelle NIO, stesso hardware, su windows e linux lavorano con chunk diversi), ogni implementazione di Java fa un pò il cavolo che vuole. Tra l'altro la concorrenza sempre per questo motivo, non è che sia implementata da Dio a quanto ho letto, anche perché certi concetti di concorrenza che valgono per Java, magari non valgono per un linguaggio come il C dove magari c'è più libertà d'azione.

Quindi in definitiva sì: posto che hai escluso problemi eventuali derivanti magari da come hai programmato quello che devi fare, è possibile che la diversa implementazione della jvm possa essere il motivo delle tue performance diverse.

Detto ciò aspetta qualcuno che ne sappia più di me.

edit: non so perché ho usato tutti questi magari :P

banryu79 · 31-03-2011, 14:23

Quote:

Originariamente inviato da dierre

... Tra l'altro la concorrenza sempre per questo motivo, non è che sia implementata da Dio a quanto ho letto, anche perché certi concetti di concorrenza che valgono per Java, magari non valgono per un linguaggio come il C dove magari c'è più libertà d'azione.

Potresti approfondire questo concetto? Sono interessato, e non ho capito bene a cosa ti riferisci di preciso (al memory model? alle diverse implementazioni delle jvm? alle API per la concorrenza? alle primitive del linguaggio per il multi-threading?)...

@Lim: personalmente non saprei se le prestazioni migliori che ottieni sui sistemi a 64 bit rispetto che a 32 sono imputabili esclusivamente alle diverse JVM che hai sotto i piedi oppure esclusivamente a dettagli di basso livello (hardware?) dei due sistemi piuttosto che a una commistione di entrambi questi aspetti.

Lim · 31-03-2011, 14:40

Quote:

Originariamente inviato da banryu79

@Lim: personalmente non saprei se le prestazioni migliori che ottieni sui sistemi a 64 bit rispetto che a 32 sono imputabili esclusivamente alle diverse JVM che hai sotto i piedi oppure esclusivamente a dettagli di basso livello (hardware?) dei due sistemi piuttosto che a una commistione di entrambi questi aspetti.

Beh, l'hardware dovrebbe essere "identico".
Ho a disposizione un server con 24 core fisici e 64GB di ram. Ho creato diverse macchine virtuali da 4 core ciascuna, come scritto sopra.
Per ogni macchina ho impostato i core fisici da utilizzare, in modo che non possano essere condivisi.
Non credo che sia un problema di hardware...

dierre · 31-03-2011, 15:43

Quote:

Originariamente inviato da banryu79

Potresti approfondire questo concetto? Sono interessato, e non ho capito bene a cosa ti riferisci di preciso (al memory model? alle diverse implementazioni delle jvm? alle API per la concorrenza? alle primitive del linguaggio per il multi-threading?)...
[...]

Diciamo che si riassume in questa frase:

Quote:

The Java Language Specification does not say how the JVM designer should implement the multithreading primitives specified, because there is so much variation among the various operating systems and hardware on which the JVM is expected to run.

Quindi c'è il classico problema di avere un design univoco a livello java, ma poi come sotto lavori la JVM non è chiaro. Non essendo chiaro non è detto che il codice java per la concorrenza sia portabile, nonostante sia Java

banryu79 · 31-03-2011, 16:15

Quote:

Originariamente inviato da dierre

Diciamo che si riassume in questa frase:
Quindi c'è il classico problema di avere un design univoco a livello java, ma poi come sotto lavori la JVM non è chiaro. Non essendo chiaro non è detto che il codice java per la concorrenza sia portabile, nonostante sia Java

Vediamo di non fare confusione: il codice Java per quanto riguarda la concorrenza è portabile. Le primitive per la concorrenza implementate a livello di linguaggio rispettano un determinato contratto, noto.
Idem per il comportamento del memory model, che è stato sistemato (fino a tot. anni fa in effetti non era allineato).

Non confondiamo gli effetti sulle prestazioni dovute alle implementazioni rispetto alla aderenza ad un contratto/specifica.

In ogni caso consiglio a Lim di provare a chiedere lumi nella sezione Concurency del forum Oracle, qui -> http://forums.oracle.com/forums/foru...ID=924&start=0

cdimauro · 31-03-2011, 19:21

AMD64 come architettura è più veloce del 10-15% mediamente rispetto a x86, grazie soprattutto al raddoppio dei registri general purpose e SIMD.

Inoltre avendo più di 4GB a disposizione è possibile, ad esempio, swappare di meno (o magari niente), oppure eseguire molto più caching dei dati letti dal disco.

dierre · 31-03-2011, 19:36

Quote:

Originariamente inviato da banryu79

Vediamo di non fare confusione: il codice Java per quanto riguarda la concorrenza è portabile. Le primitive per la concorrenza implementate a livello di linguaggio rispettano un determinato contratto, noto.
Idem per il comportamento del memory model, che è stato sistemato (fino a tot. anni fa in effetti non era allineato).

Non confondiamo gli effetti sulle prestazioni dovute alle implementazioni rispetto alla aderenza ad un contratto/specifica.

In ogni caso consiglio a Lim di provare a chiedere lumi nella sezione Concurency del forum Oracle, qui -> http://forums.oracle.com/forums/foru...ID=924&start=0

Sì anche le NIO sono portabili, solo che poi funzionano come il culo e bisogna adeguare il codice per macchina, OS e se c'è luna piena.

PGI-Bis · 01-04-2011, 07:12

E' anche possibile che sia il comportamento del garbage collector ad influenzare le prestazioni. Per via delle dimensioni minori delle partizioni di memoria con uno spazio di indirizzamento a 32 bit può essere chiamato in causa con maggiore frequenza rispetto ai 64 bit. Questo lo puoi verificare con un profiler.

Circa la concorrenza in Java, l'idea che abbia dei problemi di portabilità è piuttosto bizzarra, essendo uno dei pochi linguaggi che possiede un modello di memoria compiutamente definito (e invariato dalla sua nascita). La frase citata da dierre non dice che la concorrenza sia un fatto casuale perchè nel contesto in cui si trova spiega come operi il modello di memoria: l'implementazione del linguaggio è libera di usare le primitive di concorrenza che preferisce, posto che gli effetti di tale uso coincidano esattamente con quanto indicato dal jmm. E la coincidenza con il jmm è uno dei punti specificamente soggetti ad analisi dal tck.

Per chi dovesse averne la curiosità: che cambia tra l'avere e il non avere un modello di memoria nel linguaggio? Che cambia tra la concorrenza in Java (o C#) e, ad esempio, la concorrenza in C o C++?

Cambia che in Java gli eventuali effetti reciproci di flussi di esecuzione multipli sono sempre interamente determinabili dalla "semplice" osservazione del codice sorgente del programma. In C o C++ gli stessi effetti sono interamente determinati dal compilatore che è stato usato per generare l'eseguibile del programma.

Ergo un programma concorrente Java (o C#) ha sempre ed invariabilmente tutti e soli gli effetti determinati da come è scritto nel codice sorgente. Programmi scritti in lingue che non possiedono un modello di memoria hanno effetti variabili.

dierre · 01-04-2011, 08:50

Se riesco cerco di trovare l'articolo a cui mi riferisco. Cmq vorrei precisare che si stava parlando di efficienza e non di "non determinismo".

31-03-2011, 13:36	#1
Lim Senior Member Iscritto dal: Dec 2000 Messaggi: 501	[Java] Prestazioni diverse a 32 o 64 bit?? Ho sviluppato un simulatore in Java che deve manipolare un elevato numero di oggetti. Ho cercato di implementare il multi-thread dove possibile ed ora sto lanciando le simulazioni su diverse macchine macchine virtuali a 32bit ed a 64bit. Ogni macchina possiede 4 core e 8GB di ram (per le versioni a 64bit) o 3GB di ram (per le versioni a 32bit). Il sistema operativo è Ubuntu Server 10.10 (ovviamente a 32 e 64 bit) Bene, lanciando le simulazioni sulle due tipologie di macchine, ottengo prestazioni leggermente differenti. Poiché, al momento non ho bisogno di un grande quantitativo di ram, pensavo che non fosse giustificabile l'utilizzo di una macchina a 64bit, poiché sicuramente introduce un overhead nella gestione degli indirizzi di memoria. Invece, le macchine a 64bit sembrano occupare meno risorse (l'occupazione della CPU è circa il 10% inferiore) e le simulazioni sembrano essere "leggermente" più veloci. Che sia legato al sistema operativo? (magari la versione a 64bit è più ottimizzata?)

31-03-2011, 13:47	#2
dierre Senior Member Iscritto dal: Sep 2004 Città: Interamnia Urbs Messaggi: 2126	Premettendo che non sono un esperto di concorrenza quindi lascio volentieri la parola a qualcuno con più esperienza, ma in generale la situazione è questa: Java è ovviamente un linguaggio che cerca di astrarre il più possibile cioè che c'è sotto e capita delle volte, soprattutto nei casi in cui vengono scomodate operazioni a basso livello (a me è capitato con la copia dei file nelle NIO, stesso hardware, su windows e linux lavorano con chunk diversi), ogni implementazione di Java fa un pò il cavolo che vuole. Tra l'altro la concorrenza sempre per questo motivo, non è che sia implementata da Dio a quanto ho letto, anche perché certi concetti di concorrenza che valgono per Java, magari non valgono per un linguaggio come il C dove magari c'è più libertà d'azione. Quindi in definitiva sì: posto che hai escluso problemi eventuali derivanti magari da come hai programmato quello che devi fare, è possibile che la diversa implementazione della jvm possa essere il motivo delle tue performance diverse. Detto ciò aspetta qualcuno che ne sappia più di me. edit: non so perché ho usato tutti questi magari :P __________________ Un wormhole (buco di tarlo, in italiano), detto anche Ponte di Einstein-Rosen, è una ipotetica caratteristica topologica dello spaziotempo che è essenzialmente una "scorciatoia" da un punto dell'universo a un altro, che permetterebbe di viaggiare tra di essi più velocemente di quanto impiegherebbe la luce a percorrere la distanza attraverso lo spazio normale. Go to a Wormhole

31-03-2011, 19:21	#7
cdimauro Senior Member Iscritto dal: Jan 2002 Città: Germania Messaggi: 26110	AMD64 come architettura è più veloce del 10-15% mediamente rispetto a x86, grazie soprattutto al raddoppio dei registri general purpose e SIMD. Inoltre avendo più di 4GB a disposizione è possibile, ad esempio, swappare di meno (o magari niente), oppure eseguire molto più caching dei dati letti dal disco. __________________ Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys

01-04-2011, 07:12	#9
PGI-Bis Senior Member Iscritto dal: Nov 2004 Città: Tra Verona e Mantova Messaggi: 4553	E' anche possibile che sia il comportamento del garbage collector ad influenzare le prestazioni. Per via delle dimensioni minori delle partizioni di memoria con uno spazio di indirizzamento a 32 bit può essere chiamato in causa con maggiore frequenza rispetto ai 64 bit. Questo lo puoi verificare con un profiler. Circa la concorrenza in Java, l'idea che abbia dei problemi di portabilità è piuttosto bizzarra, essendo uno dei pochi linguaggi che possiede un modello di memoria compiutamente definito (e invariato dalla sua nascita). La frase citata da dierre non dice che la concorrenza sia un fatto casuale perchè nel contesto in cui si trova spiega come operi il modello di memoria: l'implementazione del linguaggio è libera di usare le primitive di concorrenza che preferisce, posto che gli effetti di tale uso coincidano esattamente con quanto indicato dal jmm. E la coincidenza con il jmm è uno dei punti specificamente soggetti ad analisi dal tck. Per chi dovesse averne la curiosità: che cambia tra l'avere e il non avere un modello di memoria nel linguaggio? Che cambia tra la concorrenza in Java (o C#) e, ad esempio, la concorrenza in C o C++? Cambia che in Java gli eventuali effetti reciproci di flussi di esecuzione multipli sono sempre interamente determinabili dalla "semplice" osservazione del codice sorgente del programma. In C o C++ gli stessi effetti sono interamente determinati dal compilatore che è stato usato per generare l'eseguibile del programma. Ergo un programma concorrente Java (o C#) ha sempre ed invariabilmente tutti e soli gli effetti determinati da come è scritto nel codice sorgente. Programmi scritti in lingue che non possiedono un modello di memoria hanno effetti variabili. __________________ Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!

01-04-2011, 08:50	#10
dierre Senior Member Iscritto dal: Sep 2004 Città: Interamnia Urbs Messaggi: 2126	Se riesco cerco di trovare l'articolo a cui mi riferisco. Cmq vorrei precisare che si stava parlando di efficienza e non di "non determinismo". __________________ Un wormhole (buco di tarlo, in italiano), detto anche Ponte di Einstein-Rosen, è una ipotetica caratteristica topologica dello spaziotempo che è essenzialmente una "scorciatoia" da un punto dell'universo a un altro, che permetterebbe di viaggiare tra di essi più velocemente di quanto impiegherebbe la luce a percorrere la distanza attraverso lo spazio normale. Go to a Wormhole Ultima modifica di dierre : 01-04-2011 alle 08:58.

Strumenti
Mostra una versione stampabile Invia questa pagina per email