[cdimauro]

Originariamente inviato da Yrbaf

Non diciamo stupidate solo per muovere le dita.

Il futuro è a 64 bit ma 32 bit sono ancora sufficienti per una buona fetta delle applicazioni del presente e spesso le versioni a 64 bit se non sfruttano i 64 bit (o nel caso x86 i registri in più, cosa magari non vera in tutte le altre architetture a 64b) sono pure più lente della controparte 32b.

Sfruttare i registri in più di x64 è molto più semplice, nonché comune ed effettivamente usato, che sfruttare i 64 bit. Basta disassemblare un po' di applicazioni per rendersene conto.

Eseguibili IA-32/x86, con soli 8 registri a disposizione (in realtà 7, perché uno riservato allo stack), sono pieni di istruzioni PUSH e POP per salvare e ripristinare registri, a cui si aggiungono vagonate di istruzioni che referenziano locazioni nello stack.

Eseguibili per x86-64/x64, invece, presentano di gran lunga meno casi del genere, e un notevole sfruttamento degli 8 registri in più.

Applicazioni a 64 bit che girano più lentamente delle equivalenti a 32 bit ce ne possono essere, senz'altro, ma sono una minoranza. In genere un'applicazione a 64 bit gira il 10-15% più velocemente della stessa, ma a 32 bit.

La ram ormai sarà poco costosa (in config oltre 4GB) ma le cache di primo livello dei processori non sono cresciute così tanto (come gli altri livelli) rispetto a quando si era solo a 32b.

No, ma quelle L2 e, soprattutto, L3 sono cresciute molto, e quindi mitigano molto l'accresciuta dimensione del codice (in genere il codice x64 è del 20-25% più grande di quello x86) e il raddoppio della dimensione dei puntatori (che è il problema primario quando si passare a un'ISA a 64 bit).

Forse anche a livello di MMU c'è un carico maggiore nell'usare i 64b sempre anche quando non servono.

Sì, ed ed è sempre tutto legato alla maggior dimensione del codice e dei dati.

Senza contare che ci sono vecchie macchine che hanno il supporto a 64b ma la ram fisica limitata comunque a 3-4GB e obbligarle a passare alla versione a 64b dell'OS (che potrebbe girare) sarebbe forse solo una perdita di prestazioni e basta senza veri altri benefici.

Con 4GB in genere si va abbastanza bene con s.o. & applicazioni a 64 bit.

Ovviamente dipende anche da quante se ne fanno girare, e di che tipo.

Originariamente inviato da WarDuck

Avere uno spazio di indirizzamento più ampio non vuol dire solo poter usare più RAM, ma anche sfruttare più bit per l'algoritmo di randomizzazione degli indirizzi logici (ALSR).

Le applicazioni 64 bit sono tendenzialmente più sicure delle stesse compilate a 32 bit.

Inoltre in x86_64 hai a disposizione il doppio dei registri, con tutti i benefici di ciò.

Il fatto che le applicazioni 64 usino il doppio della RAM non è un assoluto: sono i puntatori ad occupare il doppio.

Motivo per cui hanno sviluppato l'ABI x32, per il supporto ai registri a 64 bit con indirizzi a 32 bit.

*

Anche se purtroppo è un'ABI che viene usata troppo poco.

Originariamente inviato da fano

Diciamo pure che x86 è nato male cresciuto peggio e che x64 cerca di metterci delle pezze, ma è un po' un casino di architettura.

x64 è una pezza in tutti i sensi, perché il lavoro che hanno fatto lascia il tempo che trova.

Comunque il problema più grosso di x86/x64 è rappresentato dai decoder. Ma una volta che le istruzioni sono state tradotte in micro-op, il backend è poco influenzato dal "legacy".

L'ABI 32x che io trovo una soluzione interessante per uso "desktop" sembra come al solito essere stata abbandonata su Linux almeno io non la vedo molto pubblicizzata... non me la sentirei sinceramente di usarla in produzione: già i driver sono pochi figuriamoci per la versione "esotica" 32x.

Purtroppo è proprio questo il problema: la scarsa adozione. Aggiungiamoci pure che Microsoft ha completamente ignorato quest'ABI.

E' un vero peccato, perché oggi si potrebbero tranquillamente utilizzare applicazioni x32 e x64, a seconda dei casi, sfruttando il meglio delle due ABI.

La stiamo valutando per Cosmos credo che a tendere sarà quella la "nostra" versione a 32 bit, supportare 8087, farli i "long" a mano scrivendo dentro 2 registri, menarsela a salvare tutto nello stack non ha molto senso quando processori 32 bit "puri" sono una nicchia della nicchia, magari avrà senso per particolari soluzioni embedded in cui sono usate m*rdate tipo "Galileo" o "Geode".

Infatti i 32 bit "puri" (x86) hanno senso sostanzialmente solo in ambito embedded ormai.

Originariamente inviato da Yrbaf

Per la precisione Arm (32bit) e M68K di registri generici ne hanno solo 16 (sempre meglio degli 8 di x86) e non 32 o più.

In realtà i 68K hanno 8 registri dati e 8 registri indirizzi. I registri, quindi, non sono "ortogonali" (utilizzabili indifferentemente).

Mentre in x64 (e x32) sono ortogonali.

PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.

Davvero molto interessante, grazie.