Perché alcune applicazioni vengono eseguite più velocemente su una VM guest a 32 bit rispetto al computer host a 64 bit?


4

Ho un laptop Windows 7 x64 con una macchina virtuale guest Windows XP x32 installata usando VirtualBox. Una volta ho eseguito un'app sull'ospite e ho scoperto che funzionava notevolmente più velocemente rispetto all'host. Perché dovrebbe essere?

Risposte:


4

Dato che menzioni Java, qual è la versione della tua JVM ed è in esecuzione in modalità a 32 o 64 bit sull'host?

Compresso Oops

Un "oop", o un normale puntatore ad oggetto nel linguaggio Java Hotspot, è un puntatore gestito a un oggetto. Un oop ha normalmente le stesse dimensioni di un puntatore macchina nativo, il che significa 64 bit su un sistema LP64. Su un sistema ILP32, la dimensione massima dell'heap è leggermente inferiore a 4 gigabyte, il che è insufficiente per molte applicazioni. Su un sistema LP64, l'heap utilizzato da un determinato programma potrebbe dover essere circa 1,5 volte più grande di quando viene eseguito su un sistema ILP32. Questo requisito è dovuto alla dimensione estesa dei puntatori gestiti. La memoria è poco costosa, ma oggigiorno la larghezza di banda e la cache sono scarse, pertanto non è desiderabile aumentare in modo significativo la dimensione dell'heap e superare solo il limite di 4 gigabyte.

I puntatori gestiti nell'heap Java puntano ad oggetti allineati su limiti di indirizzi a 8 byte. Gli oops compressi rappresentano puntatori gestiti (in molti ma non tutti i punti nel software JVM) come offset di oggetti a 32 bit dall'indirizzo di base dell'heap Java a 64 bit. Poiché sono offset di oggetti anziché offset di byte, possono essere utilizzati per indirizzare fino a quattro miliardi di oggetti (non byte) o una dimensione heap fino a circa 32 gigabyte. Per usarli, devono essere ridimensionati di un fattore 8 e aggiunti all'indirizzo di base dell'heap Java per trovare l'oggetto a cui si riferiscono. Le dimensioni degli oggetti che utilizzano oops compressi sono paragonabili a quelle in modalità ILP32.

Il termine decodifica viene utilizzato per esprimere l'operazione mediante la quale un oop compresso a 32 bit viene convertito in un indirizzo nativo a 64 bit nell'heap gestito. L'operazione inversa viene definita codifica .

L'oops compresso è supportato e abilitato per impostazione predefinita in Java SE 6u23 e versioni successive. In Java SE 7, l'uso di oops compressi è l'impostazione predefinita per i processi JVM a 64 bit quando -Xmxnon è specificato e per valori -Xmxinferiori a 32 gigabyte. Per JDK 6 prima della versione 6u23, utilizzare il -XX:+UseCompressedOopsflag con il comando java per abilitare la funzione.

L'impronta di memoria maggiore delle JVM a 64 bit ha implicazioni di prestazioni molto significative.


Questa è una buona domanda. È passato quasi un anno da quando l'ho notato, quindi non ricordo quale versione stavo usando allora, tuttavia probabilmente era aggiornato, perché ero diligente a riguardo. Inoltre, molto probabilmente stavo usando un browser a 32 bit, nel qual caso suppongo che Java funzionasse a 32 bit. Immagino sia anche rilevante aggiungere che sul mio laptop sono installati 4 GB di RAM.
user125900

3

Le applicazioni potrebbero essere più veloci nella VM a causa della memorizzazione nella cache. Poiché la VM memorizza i propri dischi in file, il sistema operativo dell'host potrebbe memorizzare nella cache questi file nella RAM e funzioneranno più velocemente. La differenza nel mondo reale tra le applicazioni a 32 e 64 bit è di alcune percentuali.


Interessante. Immagino che accelererebbe un po 'le cose. Che dire delle applicazioni Flash o Java? Immagino sia rilevante aggiungere che l'applicazione era in esecuzione da una pagina Web, quindi era Java o Flash (non ricordo quale).
user125900
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.