2012-10-15 4 views
5

Esiste un valore relativamente uguale a new Linux ABI referred to as x32, in cui il processore x86-64 viene eseguito in modalità a 32 bit, quindi i puntatori sono ancora solo a 32 bit, ma i registri specifici dell'architettura a 64 bit vengono ancora utilizzati. Quindi sei ancora limitato a un massimo di 4 GB di memoria come nel normale 32-bit, ma i tuoi puntatori consumano meno spazio nella cache rispetto a 64-bit, puoi fare aritmetica a 64 bit in modo efficiente e ottieni accesso a più registri (16) di quanto faresti in vaniglia a 32 bit (8).Quali <4 GB carichi di lavoro avrebbero prestazioni peggiori nell'ABI x32 di Linux rispetto a x64?

Supponendo che si abbia un carico di lavoro che si adatta perfettamente a 4 GB, c'è un modo in cui le prestazioni di x32 potrebbero essere peggiori rispetto a x86-64?

Mi sembra che se non si necessita dello spazio di memoria aggiuntivo non si perde nulla, si dovrebbe sempre ottenere lo stesso perfetto (quando si è già inseriti nella cache) o migliore (quando il risparmio di spazio del puntatore consente di adattarsi più nella cache). Ma non mi sorprenderebbe se ci fossero paging/TLB/etc. dettagli che non conosco.

+0

Il male è nei dettagli, quindi non sarò molto sorpreso se in alcune rare occasioni, nelle tue condizioni, a volte x32 potrebbe essere un po 'peggio di x86-64. Ma non credo che sia comune .... (si potrebbe immaginare che i vincoli di allineamento siano meno forti su x32, e questo potrebbe danneggiare raramente le prestazioni della cache). –

+0

Ricorda che la dimensione del puntatore non è l'unica differenza tra i due ABI - x86-64 ha anche più registri, che possono ridurre il numero di istruzioni di caricamento/memorizzazione e molte altre differenze. Di conseguenza, non c'è una risposta semplice a questa domanda, e il benchmarking/testing sarebbe quasi sempre la strada migliore per determinare quale sia "migliore" per qualunque definizione di "migliore" sia importante per quel particolare progetto. – twalberg

+1

@twalberg: Penso che potresti aver letto male la domanda - x32 e x86-64 hanno lo stesso numero di registri. Non sto parlando del normale 32-bit. –

risposta

8

Certamente se si dispone di un programma con multithreading, il fatto che le strutture di dati siano più piccole su x32 potrebbe causare il conflitto di righe della cache tra i thread: oggetti diversi potrebbero essere allocati sulla stessa riga della cache in modalità x32 e diverse linee della cache in modalità x86_64 . Se due thread modificano questi oggetti in modo indipendente, il ping-ping della cache potrebbe rallentare gravemente il codice x32. Ovviamente, questo tipo di effetto cache potrebbe accadere indipendentemente dalle dimensioni del puntatore, ma se il codice è stato ottimizzato assumendo i puntatori a 64 bit, andare a puntatori a 32 bit potrebbe de-sintonizzare le cose.

+1

+1 per essere possibile, ma in pratica dovresti allineare qualsiasi dato che potrebbe essere toccato da due thread su una linea della cache. –

+0

@JosephGarvin: Sì, ma l'allineamento potrebbe essere stato eseguito assumendo una particolare dimensione del puntatore. Se qualcuno riempie gli elementi in modo da riempire una linea di cache con puntatori a 64 bit, la modifica dei puntatori a 32 bit senza aggiornare il padding potrebbe essere un problema.Questo è principalmente un problema se si sta prendendo il codice sorgente esistente, sintonizzato e ricompilato in modalità x32 senza modifiche. –

2

In X32 il processore è attualmente in esecuzione in "modalità lunga", la stessa modalità di x86_64. Cioè, gli indirizzi visti dal processore quando si effettua l'indirizzamento sono ancora a 64 bit, tuttavia l'XI ABI assicura che tutti gli indirizzi siano abbastanza piccoli da adattarsi a 32 bit. Come risultato, in alcuni casi si verifica un leggero sovraccarico quando i puntatori devono essere estesi da 32 a 64 bit.

Inoltre, richiede le librerie x86/x86-64/x32 nella RAM, che suppongo sia ciò che uno finirà con in pratica (a meno che tu non stia parlando di un sistema embedded o altro strettamente controllato piuttosto che un computer di uso generale), potrebbe consumare alcuni dei vantaggi di X32.

+1

I puntatori non sono in realtà sign-extended? E non credo che ci sia alcuna penalità di prestazioni per un carico a 32 bit o istruzioni di memorizzazione in modalità lunga, sia l'estensione di segno che l'estensione zero sono operazioni estremamente economiche gestite nell'hardware durante lo stesso ciclo (nessun ritardo aggiunto). –

+0

Penso che i sistemi embedded e strettamente controllati siano l'obiettivo prefissato, quindi dubito che il problema relativo all'utilizzo della RAM della biblioteca potrebbe emergere. –

+0

@ BenVoigt: Potrebbero davvero essere segno esteso piuttosto che zero, non ricordo quale. E no, non c'è penalità per caricamento/archiviazione a 32 bit in modalità lunga, piuttosto l'opposto in quanto le codifiche di registro rXX occupano più spazio rispetto alle codifiche di reg di 32 bit. E sì, le estensioni sign/zero sono molto economiche, anche se occupano un po 'di decodificatore BW e gonfiano il codice. – janneb

Problemi correlati