Gibt es einen guten Grund, 32-Bit-Software anstelle von 64-Bit auf 64-Bit-Computern auszuführen?

56

Gibt es einen guten Grund, eine 32-Bit-Version zusammen mit einer 64-Bit-Version einer Software für moderne Desktop-Computer bereitzustellen, auf denen moderne 64-Bit-Betriebssysteme auf 64-Bit-Hardware ausgeführt werden?

Es scheint, dass 64-Bit-Software effizienter ist, bei Bedarf eine höhere Speichernutzung zulässt usw. Apple verwendet sogar 64-Bit-Prozessoren für seine Telefone, obwohl sie nur über 1-2 GB RAM verfügen, weit unter den 4 GB Limit für 32-Bit-CPUs.

hardware 64-bit 32-bit

— Filip Haglund
quelle

16

Nicht auf jeder modernen Maschine läuft ein 64-Bit-Betriebssystem

— Bálint

4

Haben Sie Beispiele?

— Filip Haglund

8

Fragen Sie Ihre Kunden.

— Murphy

22

Rhetorische Frage: Gibt es einen Grund für die Lieferung einer 64-Bit-Version einer Software, da die meisten modernen 64-Bit-Betriebssysteme die Ausführung von 32-Bit- und 64-Bit-Anwendungen ermöglichen?

— Doc Brown

2

Kein Duplikat von @gnat. Bei dieser Frage geht es um das Anpassen eines Zeitstempels und einer Entwickler-ID im Fehlercode, die beim Beenden eines Programms zurückgegeben wird.

— Filip Haglund

80

Vorteile von 32-Bit-Software in 64-Bit-Umgebungen

Ein geringerer Speicherbedarf, insbesondere bei Anwendungen mit hohem Zeigeraufkommen (64-Bit gegenüber 32-Bit), kann den Speicherbedarf auf einfache Weise verdoppeln.
Objektdateien sind ebenfalls kleiner.
Kompatibilität mit 32-Bit-Umgebungen.
Speicherverluste sind auf 2 GB, 3 GB oder 4 GB beschränkt und überlasten nicht das gesamte System.

Nachteile von 32-Bit-Software in 64-Bit-Umgebungen

Maximal 2 GB, 3 GB oder 4 GB Arbeitsspeicher pro Prozess. (Nur pro Prozess, in der Summe können mehrere 32-Bit-Prozesse den gesamten verfügbaren Systemspeicher nutzen.)
Keine Verwendung zusätzlicher Register und Befehlssatzerweiterungen in Abhängigkeit von x64. Dies ist sehr compiler- und CPU-spezifisch.
Möglicherweise sind 32-Bit-Versionen aller (der meisten Linux-Distributionen) oder seltener (der meisten Windows-Versionen) Bibliotheken und Laufzeitumgebungen erforderlich. Wenn eine 32-Bit-Version einer gemeinsam genutzten Bibliothek exklusiv für Ihre Anwendung geladen wird und dies für Ihren Footprint gilt. Kein Unterschied, wenn Sie statisch verlinken.

Weitere Aspekte

Treiber sind normalerweise kein Problem. Nur Benutzerbereichsbibliotheken sollten sich zwischen 32-Bit und 64-Bit unterscheiden, nicht die API von Kernelmodulen.
Beachten Sie die unterschiedlichen Standardbreiten für ganzzahlige Datentypen, zusätzliche Tests sind erforderlich.
Die 64-Bit-CPU-Architektur unterstützt möglicherweise nicht einmal 32-Bit.
Bestimmte Techniken wie ASLR und andere, die von einem viel größeren Adressraum als dem physischen Speicher abhängen, funktionieren in einem 32-Bit-Ausführungsmodus nicht gut (oder überhaupt nicht).

Wenn ich hier nicht eine ganz bestimmte CPU-Architektur, Betriebssystem- und Bibliotheksinfrastruktur vergleiche, kann ich nicht näher darauf eingehen.

— Ext3h
quelle

8

"Die 64-Bit-CPU-Architektur unterstützt möglicherweise überhaupt nicht 32-Bit." Ist dies eher ein theoretisches Anliegen oder existiert dies in der Welt?

— Mucaho

10

@mucaho Es gab sicherlich nur 64-Bit-CPU-Architekturen, wie die Alpha und die IA64. Beide sind jedoch moribund. Ich bin mir nicht sicher, ob es derzeit 64-Bit-Architekturen gibt - vielleicht AArch64? Weiß jemand, ob 32-Bit-ARM ein obligatorischer Bestandteil davon ist?

— zwol

10

@zwol Nein, 32-Bit ist für ARM nicht obligatorisch und 64-Bit auch nicht. Es gibt nur 64-Bit-ARM-CPUs, während andere sowohl 32-Bit- als auch 64-Bit-Prozesse unterstützen.

— Ext3h

3

Das einfache Auswählen und Festhalten an einer Architektur hat einen weiteren Vorteil: einfachere Entwicklung und einfacheres Testen.

— jl6

7

@Joshua hat es immer gegeben? Wussten die Pharaonen das?

— candied_orange

7

Der Unterschied zwischen 32-Bit-Software und 64-Bit-Software ist die Größe der Zeiger und möglicherweise die Größe der Ganzzahlregister. Das ist es.

Das bedeutet, dass alle Zeiger in Ihrem Programm doppelt so groß sind. Und (zumindest auf einer ILP32 / LP64-Architektur) sind Ihre longs auch doppelt so groß. Dies führt normalerweise zu einer Erhöhung der Objektcodegröße um ca. 30%. Das bedeutet, dass …

Ihr Objektcode benötigt ca. 30% länger, um von der Festplatte in den RAM zu laden
Ihr Objektcode belegt ca. 30% mehr Speicherplatz
Sie haben Ihre Speicherbandbreite (für Objektcode) effektiv um ~ 20% gesenkt
Sie haben die Größe des Anweisungscaches effektiv um ~ 20% verringert.

Dies hat einen nicht zu vernachlässigenden negativen Einfluss auf die Leistung.

Dies zu tun, macht nur Sinn, wenn Sie diese Leistungskosten irgendwie "zurückkaufen" können. Grundsätzlich gibt es zwei Möglichkeiten, dies zu tun: Sie führen eine Menge 64-Bit-Ganzzahlberechnungen durch, oder Sie benötigen mehr als 4 GiByte abgebildeten Speicher. Wenn eines oder beide zutreffen, ist es sinnvoll, 64-Bit-Software zu verwenden, andernfalls ist dies nicht der Fall.

Hinweis: In einigen Architekturen gibt es keine entsprechenden 32- oder 64-Bit-Varianten. In diesem Fall ergibt die Frage offensichtlich keinen Sinn. Die bekanntesten sind IA64 (nur 64-Bit und keine 32-Bit-Variante) und x86 / AMD64 (wenn auch eng verwandt) mit unterschiedlichen Architekturen, wobei x86 nur 32-Bit und AMD64 nur 64-Bit ist.

Tatsächlich ist diese letztere Aussage nicht mehr zu 100% wahr. Linux hat kürzlich das x32-ABI hinzugefügt, mit dem Sie AMD64-Code mit 32-Bit-Zeigern ausführen können. Auch wenn dies keine "richtige" CPU-Architektur ist, können Sie die AMD64-Architektur so verwenden, als ob sie eine native wäre 32-Bit-Variante. Dies geschah genau deshalb, weil der oben erwähnte Leistungsaufwand reale messbare und quantifizierbare Probleme für reale Benutzer verursachte, die realen Code in realen Systemen ausführen.

— Jörg W. Mittag
quelle

8

Was ist mit den zusätzlichen Registern und Befehlen in amd64 im Vergleich zu x86? Wie viel verbessert das die Leistung?

— Filip Haglund

2

Google für "markierte Zeiger", die in Objective-C unter MacOS X und iOS verwendet werden. Sehr große Mengen von Objekten haben überhaupt keinen zugewiesenen Speicher, aber das gesamte Objekt wird auf 64-Bit-Systemen im Zeiger gefälscht. (Ich habe gehört, Java macht etwas Ähnliches). In C ++ enthält std :: string auf 64-Bit häufig bis zu 22 Zeichen im Objekt selbst ohne Speicherzuordnung. Erhebliche Speichereinsparungen und Geschwindigkeitsverbesserungen.

— gnasher729

3

Größe von Zeigern und ganzen Zahlen ist das? Was ist mit dem größeren Adressraum und den zusätzlichen Registern in den meisten 64-Bit-Architekturen?

1

"Sie haben den Befehls-Cache um ~ 20% [reduziert]" ist umstritten, da der Befehlssatz völlig anders ist (und oft effizienter)

— BlueRaja - Danny Pflughoeft

3

"Dies hat einen nicht zu vernachlässigenden negativen Einfluss auf die Leistung." Diese Aussage ist zwar absolut zutreffend, ignoriert jedoch die Tatsache, dass die große Mehrheit der Leistungsengpässe von Anwendungen nicht in der Ladezeit, der Speichernutzung / Bandbreite oder der Anzahl der Anweisungen im Cache liegt.

— Ian Kemp

6

Wenn die Software direkt mit älteren Systemen, Treibern oder Bibliotheken verbunden werden muss, müssen Sie möglicherweise eine 32-Bit-Version bereitstellen, da AFAIK das Mischen von 64-Bit und 32-Bit im Allgemeinen (definitiv Windows und Linux AFAIK) nicht zulässt -Bit-Code innerhalb eines Prozesses.

Wenn Ihre Software beispielsweise auf Spezialhardware zugreifen muss, ist es für Kunden nicht ungewöhnlich, ältere Modelle zu betreiben, für die nur 32-Bit-Treiber verfügbar sind.

Für den Fall, dass Sie nicht mehr weiterkommen möchten

— Michael Borgwardt
quelle

2

Sie können 32-Bit- und 64-Bit- Dateien

— Navin,

1

@ Navin: Aber ist es praktisch? Könnten Sie eine COM-Komponente in einer 64-Bit-Windows-Anwendung verwenden (z. B. eine .NET-Anwendung, die als " Beliebige CPU" markiert ist und unter einer 64-Bit-Version von Windows ausgeführt wird)?

— Peter Mortensen

3

Wenn Ihre Software eine DLL ist, MÜSSEN Sie sowohl 32-Bit- als auch 64-Bit-Versionen bereitstellen. Sie haben keine Ahnung, ob der Kunde 32-Bit- oder 64-Bit-Software verwendet, um mit der DLL zu kommunizieren, und die DLL muss dieselbe Bitlänge wie die Anwendung verwenden. Dies ist nicht verhandelbar.

Wenn es sich bei Ihrer Software um eine eigenständige ausführbare Datei handelt, ist dies weniger klar. Wenn Sie Ihre Software nicht für ältere Betriebssysteme benötigen, müssen Sie möglicherweise keine 32-Bit-Version bereitstellen. Halten Sie sich einfach an die 64-Bit-Version, geben Sie an, dass ein 64-Bit-Betriebssystem erforderlich ist, und erledigen Sie die Aufgabe.

Wenn Sie jedoch Ihre Software für ältere Betriebssysteme benötigen, möchten Sie möglicherweise NICHT aktiv eine 64-Bit-Version bereitstellen. Wenn Sie über zwei Versionen verfügen, haben Sie die doppelte Testdauer, und das ordnungsgemäße Testen von Software für eine Reihe von Betriebssystemversionen und -sprachen ist kein schneller Vorgang. Da 32-Bit-Software auf einer 64-Bit-Plattform problemlos ausgeführt werden kann, ist es immer noch üblich, dass Software nur als 32-Bit-Software veröffentlicht wird, insbesondere von kleineren Entwicklern.

Beachten Sie auch, dass die meisten Handys 32-Bit sind. Vielleicht sind einige High-End-Versionen jetzt 64-Bit, aber es gibt wenig zwingenden Grund, diesen Schritt zu tun. Wenn Sie plattformübergreifend entwickeln und möchten, dass Ihr Code auch auf Android ausgeführt wird, ist die 32-Bit-Version eine sichere Option.

— Graham
quelle

Ich würde mich gegen Ihre Position zu reduzierten Tests aussprechen. Stattdessen würde ich argumentieren, auf mehreren Plattformen zu testen, insbesondere nicht nur mit unterschiedlichen Registergrößen, sondern auch mit unterschiedlichen Byte-Reihenfolgen, um das Testen zu vereinfachen und subtile Fehler aufzufangen. Darüber hinaus würde ich auch Tests auf Computern durchführen, die Ihre empfohlenen Mindesthardwareanforderungen nicht erfüllen, da dies auch zusätzliche Probleme aufwirft, die möglicherweise nur bei sehr großen Datenmengen auftreten.

— Hildred

@hildred Mit unbegrenzten Testressourcen würde ich zustimmen. In der Praxis müssen Sie diese Tests jedoch möglicherweise nicht sofort durchführen, wenn Sie mehr Kontrolle über Ihr Ziel haben. Es ist auch kein "einfacher Weg" - Sie können zwar einige dieser Plattformen in einer VM simulieren, aber wenn Sie physische Hardware einrichten müssen, ist dies mit viel manueller (nicht automatisierbarer) Arbeit verbunden. Es kann Sie davon abhalten, ein Testgeschirr zu schreiben, um dies explizit zu testen, aber es ist keineswegs kostenlos.

— Graham

1

Nicht kostenlos, aber ausgesprochen günstig. Wenn Sie Ihre Off-Platform-Tests auf automatisierte Tests, den gelegentlichen Idiotentest und die verwendete Hardware beschränken, sind Ihre Kosten für erfolgreiche Tests nach der Ersteinrichtung auf die Stromversorgung und etwa 7 Mannminuten pro Testdurchlauf beschränkt. Die Kosten für fehlgeschlagene Tests wären natürlich höher, aber diese wären normalerweise mehr wert (es gibt immer Hardwarefehler). Diese Art der Einrichtung ist besonders für C-Programmierer nützlich, da sie leicht eine bestimmte Klasse von Zeigerproblemen aufdeckt, die ansonsten schwer aufzuspüren sind.

— Hildred