Esiste una buona ragione per eseguire software a 32 bit anziché 64-bit su macchine a 64 bit?

Vantaggi del software a 32 bit in ambienti a 64 bit

• Un minore ingombro della memoria, specialmente nelle applicazioni con puntatore pesante, 64-bit contro 32-bit può facilmente raddoppiare i requisiti di memoria.
• Anche i file oggetto sono più piccoli.
• Compatibilità con ambienti a 32 bit.
• Le perdite di memoria sono limitate a 2 GB, 3 GB o 4 GB e non imperversano sull'intero sistema.

Svantaggi del software a 32 bit in ambienti a 64 bit

• Limite di memoria di 2 GB, 3 GB o 4 GB per processo. (Solo per processo, in sommario più processi a 32 bit possono utilizzare l'intera memoria di sistema disponibile.)
• Non si utilizzano registri aggiuntivi e estensioni del set di istruzioni a seconda di x64. Questo è altamente compilatore e specifico per la CPU.
• Potrebbe richiedere le versioni a 32 bit di tutte (la maggior parte delle distribuzioni Linux) o non comuni (la maggior parte delle versioni di Windows) librerie e ambienti di esecuzione. Se una versione a 32 bit di una libreria condivisa viene caricata esclusivamente per la tua applicazione, e ciò vale per il tuo footprint. Nessuna differenza se stai collegando staticamente.

Altri aspetti

• I driver non sono di solito un problema. Solo le librerie dello spazio utente dovrebbero differire tra 32-bit e 64-bit, non l'API dei moduli del kernel.
• Fai attenzione alle diverse larghezze predefinite per i tipi di dati interi, sono necessari ulteriori test.
• L'architettura della CPU a 64 bit potrebbe non supportare nemmeno il 32 bit.
• Alcune tecniche come ASLR e altre, a seconda di uno spazio di indirizzi molto più ampio della memoria fisica, non funzionano bene (o affatto) in una modalità di esecuzione a 32 bit.

A meno di confrontare un'architettura CPU, un sistema operativo e un'infrastruttura di librerie molto specifici qui, non potrò entrare in ulteriori dettagli.

La differenza tra software a 32 bit e software a 64 bit è la dimensione dei puntatori e forse la dimensione dei registri interi. Questo è tutto.

Ciò significa che tutti i puntatori del tuo programma hanno il doppio della dimensione. E (almeno su un'architettura ILP32 / LP64) anche il tuo long s ha il doppio della dimensione. Questo in genere comporta un aumento del 30% circa delle dimensioni del codice oggetto. Ciò significa che ...

• il tuo codice oggetto impiegherà circa il 30% in più per essere caricato dal disco nella RAM
• il tuo codice oggetto occuperà il 30% di spazio in più in memoria
• hai effettivamente abbassato la larghezza di banda della tua memoria (per il codice dell'oggetto) del ~ 20%
• hai effettivamente abbassato la dimensione della cache delle istruzioni di ~ 20%

Questo ha un effetto negativo non trascurabile sulle prestazioni.

Fare questo ha senso solo se puoi "riacquistare" quei costi delle prestazioni in qualche modo. Fondamentalmente, ci sono due modi per farlo: si fa un sacco di matematica a 64 bit interi, o si ha bisogno di più di 4 memorie mappate GiByte. Se uno o entrambi sono veri, è logico utilizzare software a 64 bit, altrimenti non lo è.

Nota: ci sono alcune architetture in cui non ci sono varianti corrispondenti a 32 o 64 bit. In tal caso, la domanda ovviamente non ha senso. I più noti sono IA64, che ha solo 64 bit e non ha varianti a 32 bit, e x86 / AMD64 che sono, anche se strettamente collegate, architetture diverse , x86 a 32 bit solo, AMD64 a 64 solo bit.

In realtà, quest'ultima affermazione non è più vera al 100%. Linux ha recentemente aggiunto l'ABI x32, che consente di eseguire il codice AMD64 con puntatori a 32 bit, quindi anche se non è un'architettura CPU "corretta", è un modo di utilizzare l'architettura AMD64 in modo tale che se avesse un Variante a 32 bit. Ciò è stato fatto con precisione perché l'overhead delle prestazioni che ho menzionato sopra stava causando reali problemi misurabili e quantificabili per gli utenti del mondo reale che eseguono il codice del mondo reale nei sistemi reali.

Se il software deve interfacciarsi direttamente con i sistemi, i driver o le librerie precedenti, potrebbe essere necessario fornire una versione a 32 bit, poiché AFAIK generalmente il sistema operativo (sicuramente Windows e Linux AFAIK) non consente il mixaggio di 64- bit e codice a 32 bit all'interno di un processo.

Ad esempio, se il tuo software ha bisogno di accedere all'hardware specialistico, non è raro che i clienti utilizzino modelli precedenti per i quali sono disponibili solo driver a 32 bit.

Se il tuo software è una DLL, DEVE fornire entrambe le versioni a 32 e 64 bit. Non hai idea se il cliente userà software a 32 o 64 bit per parlare con la DLL e la DLL deve utilizzare la stessa lunghezza di bit dell'applicazione. Questo non è negoziabile.

Se il tuo software è un eseguibile standalone, è meno chiaro. Se non è necessario eseguire il software su sistemi operativi precedenti, potrebbe non essere necessario fornire una versione a 32 bit. Basta limitarsi a 64 bit, specificare che richiede un sistema operativo a 64 bit e il lavoro svolto.

Tuttavia, se hai bisogno che il tuo software funzioni su sistemi operativi meno recenti, allora NON potresti attivamente fornire una versione a 64 bit. Se si dispone di due versioni, è necessario raddoppiare il test e testare correttamente il software su una vasta gamma di versioni e lingue del sistema operativo non è un processo rapido. Poiché il software a 32 bit funziona perfettamente felicemente su una piattaforma a 64 bit, è ancora abbastanza comune che il software venga rilasciato solo a 32 bit, soprattutto da parte di sviluppatori più piccoli.

Si noti inoltre che la maggior parte dei cellulari sono a 32 bit. Forse alcuni di fascia alta sono 64-bit ora, ma c'è un motivo poco convincente per fare quel passo. Quindi, se stai sviluppando una piattaforma multipiattaforma e potresti volere che il tuo codice venga eseguito anche su Android, rimanere a 32 bit è un'opzione sicura.