C'è un buon motivo per eseguire software a 32 bit anziché a 64 bit su macchine a 64 bit?

56

C'è qualche buon motivo per fornire una versione a 32 bit insieme a una versione a 64 bit di qualsiasi software destinato alle moderne macchine desktop, che eseguono moderni sistemi operativi a 64 bit su hardware a 64 bit?

Sembra che il software a 64 bit sarebbe più efficiente, consentirebbe un maggiore utilizzo della memoria se necessario, ecc. Apple utilizza persino processori a 64 bit per i loro telefoni, anche se hanno solo 1-2 GB di RAM, molto al di sotto dei 4 GB limite per CPU a 32 bit.

hardware 64-bit 32-bit

— Filip Haglund
fonte

16

Non tutte le macchine moderne hanno un sistema operativo a 64 bit

— Bálint,

4

Hai qualche esempio?

— Filip Haglund,

8

Chiedi ai tuoi clienti.

— Murphy,

22

Domanda retorica: c'è un motivo per fornire una versione a 64 bit di qualsiasi software poiché la maggior parte dei moderni sistemi operativi a 64 bit consente di eseguire anche applicazioni a 32 e 64 bit?

— Doc Brown,

2

@Gnat non duplicato. Quella domanda riguarda l'adattamento di un timestamp e un ID sviluppatore nel codice di errore restituito alla chiusura di un programma.

— Filip Haglund,

80

Vantaggi del software a 32 bit in ambienti a 64 bit

Ingombro di memoria ridotto, specialmente nelle applicazioni con puntatore elevato, 64 bit contro 32 bit possono facilmente raddoppiare i requisiti di memoria.
Anche i file degli oggetti sono più piccoli.
Compatibilità con ambienti a 32 bit.
Le perdite di memoria hanno un limite massimo di 2 GB, 3 GB o 4 GB e non sommergeranno l'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 sintesi più processi a 32 bit possono utilizzare l'intera memoria di sistema disponibile.)
Non utilizzare registri aggiuntivi ed estensioni del set di istruzioni in base a x64. Questo è altamente compilatore e specifico della CPU.
Potrebbe richiedere versioni a 32 bit di tutte le librerie e ambienti di runtime (la maggior parte delle distribuzioni Linux) o non comuni (la maggior parte delle versioni di Windows). Se una versione a 32 bit di una libreria condivisa viene caricata esclusivamente per l'applicazione, e ciò conta per il tuo footprint. Nessuna differenza se stai collegando staticamente.

Altri aspetti

I driver di solito non rappresentano un problema. Solo le librerie dello spazio utente dovrebbero differire tra 32 e 64 bit, non l'API dei moduli del kernel.
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 32 bit.
Alcune tecniche come ASLR e altre che dipendono da uno spazio di indirizzi molto più ampio rispetto alla memoria fisica non funzioneranno bene (o affatto) in una modalità di esecuzione a 32 bit.

A meno che non si confronti un'architettura CPU, un sistema operativo e un'infrastruttura di libreria molto specifici qui, non sarò in grado di entrare in maggiori dettagli.

— Ext3h
fonte

8

"L'architettura della CPU a 64 bit potrebbe non supportare nemmeno 32 bit." È più una preoccupazione teorica o esiste nel mondo?

— mucaho,

10

@mucaho Certamente ci sono stati 64-bit-solo architetture di CPU, come l'Alfa e l'IA64. Entrambi sono moribondi, però. Non so per caso se ci sono architetture solo a 64 bit attualmente prodotte - AArch64, forse? Qualcuno sa se ARM a 32 bit è un componente obbligatorio di questo?

— zwol,

10

@zwol No, 32 bit non è obbligatorio per ARM, né 64 bit. Esistono solo CPU ARM a 64 bit, mentre altre supportano processi sia a 32 che a 64 bit.

— Ext3h

3

C'è un ulteriore vantaggio nel scegliere semplicemente un'architettura e attenersi ad essa: sviluppo e test più semplici.

— jl6,

7

@Joshua Sei sempre esistito? I faraoni lo sapevano?

— candied_orange,

7

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 nel programma hanno una dimensione doppia. E (almeno su un'architettura ILP32 / LP64) anche le tue longs sono due volte più grandi. Questo di solito comporta un aumento di circa il 30% nella dimensione del codice oggetto. Ciò significa che …

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

Ciò ha un effetto negativo non trascurabile sulle prestazioni.

Farlo ha senso solo se è possibile "riacquistare" quei costi di performance in qualche modo. Fondamentalmente, ci sono due modi per farlo: fai molti calcoli interi a 64 bit o hai bisogno di più di 4 memoria mappata GiByte. Se uno o entrambi sono veri, ha senso usare un software a 64 bit, altrimenti non lo è.

Nota: esistono alcune architetture in cui non esistono varianti corrispondenti a 32 o 64 bit. In tal caso, la domanda ovviamente non ha senso. I più noti sono IA64, che è solo a 64 bit e non ha una variante a 32 bit, e x86 / AMD64 che sono, sebbene strettamente correlati, architetture diverse , x86 essendo solo a 32 bit, AMD64 essendo solo a 64 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 si tratta di un'architettura CPU "corretta", è un modo di utilizzare l'architettura AMD64 in modo da avere un nativo Variante a 32 bit. Ciò è stato fatto proprio perché l'overhead delle prestazioni sopra menzionato stava causando problemi reali misurabili e quantificabili per gli utenti del mondo reale che eseguono codice del mondo reale nei sistemi del mondo reale.

— Jörg W Mittag
fonte

8

Che dire dei registri e delle istruzioni extra in amd64 rispetto a x86? Quanto migliora le prestazioni?

— Filip Haglund,

2

Google per "puntatori con tag" utilizzati in Objective-C su MacOS X e iOS. Quantità di oggetti molto consistenti non hanno alcuna memoria allocata, ma l'intero oggetto viene simulato all'interno del puntatore su sistemi a 64 bit. (Ho sentito che Java fa qualcosa di simile). In C ++, std :: string su 64 bit contiene spesso fino a 22 caratteri nell'oggetto stesso senza alcuna allocazione di memoria. Notevoli risparmi di memoria e miglioramenti della velocità.

— gnasher729,

3

Dimensione di puntatori e numeri interi è? Che dire dello spazio di indirizzi più ampio e dei registri aggiuntivi nella maggior parte delle architetture a 64 bit?

1

"hai [ridotto] la cache delle istruzioni di ~ 20%" è discutibile poiché il set di istruzioni è completamente diverso (e spesso più efficiente)

— BlueRaja - Danny Pflughoeft

3

"Ciò ha un effetto negativo non trascurabile sulle prestazioni." Sebbene questa affermazione sia vera in senso assoluto, ignora il fatto che la stragrande maggioranza delle strozzature delle prestazioni delle applicazioni non è in termini di tempo di caricamento, utilizzo della memoria / larghezza di banda o numero di istruzioni nella cache.

— Ian Kemp,

6

Se il software deve interfacciarsi direttamente con sistemi legacy, driver o librerie, potrebbe essere necessario fornire una versione a 32 bit, poiché AFAIK il sistema operativo in generale (sicuramente Windows e Linux AFAIK) non consente il missaggio di 64 bit e 32 -bit code all'interno di un processo.

Ad esempio, se il tuo software deve accedere a hardware speciale, non è raro che i clienti utilizzino modelli meno recenti per i quali sono disponibili solo driver a 32 bit.

— Michael Borgwardt
fonte

2

È possibile combinare 32 bit e 64 bit nello stesso processo in Windows e Linux: stackoverflow.com/q/12716419/703382

— Navin

1

@Navin: Ma è pratico? È possibile utilizzare un componente COM in un'applicazione Windows a 64 bit (ad esempio un'applicazione .NET contrassegnata come Qualsiasi CPU in esecuzione su una versione a 64 bit di Windows)?

— Peter Mortensen,

3

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

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

Tuttavia, se hai bisogno del tuo software per funzionare su sistemi operativi più vecchi, potresti NON voler attivamente fornire una versione a 64 bit. Se hai due versioni, hai il doppio dei 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 su una piattaforma a 64 bit, è ancora abbastanza comune che il software venga rilasciato solo a 32 bit, soprattutto da sviluppatori più piccoli.

Si noti inoltre che la maggior parte dei cellulari sono a 32 bit. Forse alcuni di fascia alta ora sono a 64 bit, ma ci sono poche ragioni convincenti per fare questo passo. Quindi, se stai sviluppando multipiattaforma e potresti voler eseguire anche il tuo codice su Android, rimanere a 32 bit è un'opzione sicura.

— Graham
fonte

Direi contro la tua posizione sui test ridotti. Direi invece di provare su più piattaforme, in particolare non solo con dimensioni di registro diverse ma con ordini di byte diversi, come un modo semplice per aumentare i test e rilevare errori sottili. Inoltre, farei anche dei test su computer che non soddisfano i requisiti hardware minimi consigliati in quanto esporranno anche problemi aggiuntivi che potrebbero non essere visualizzati diversamente se non con set di dati molto grandi.

— Hildred

@hildred Con risorse di test illimitate, sono d'accordo. In pratica, tuttavia, se si ha un maggiore controllo sul proprio obiettivo, potrebbe non essere necessario eseguire immediatamente questo test. Non è nemmeno un "modo semplice" - sicuramente puoi simulare alcune di queste piattaforme in una VM, ma se hai bisogno di una configurazione hardware fisica, questo comporta un grande lavoro manuale (non automatizzabile). Potrebbe salvarti dalla scrittura di un cablaggio di prova per testarlo esplicitamente, ma non è gratuito in alcun modo.

— Graham,

1

Non gratuito, ma decisamente economico. Se si limitano i test off-platform ai test automatici, il test idiota occasionale, utilizza l'hardware A parte la configurazione, i costi per i test riusciti dopo l'installazione iniziale sarebbero limitati alla potenza e circa 7 minuti uomo per passaggio di test. Il costo per i test falliti sarebbe ovviamente più alto, ma quelli normalmente varrebbero di più (c'è sempre un guasto hardware). Questo tipo di impostazione è particolarmente utile per i programmatori c poiché espone prontamente una certa classe di problemi relativi ai puntatori che sarebbero altrimenti difficili da rintracciare.

— hildred,