Welche vorteile bietet eine 64bit Architektur, außer das mehr (Arbeits-)speicher verwendet werden kann?
Neben Einzelfällen, in denen 64 Bit Integerrechung wesentliche Vorteile
bringt ist eben die Adressierung der massgebliche Vorteil. Sofern man
innerhalb einer ansonsten gleichen Architektur bleibt.
Bei x64/amd64/x86-64 kommt gegenüber x86 allerdings die erhebliche
Erweiterung der Architektur durch mehr und uniformere Register sowie die
PC-relative Datenadressierung hinzu.
> mehr (Arbeits-)speicher
Der Unterschied liegt im durch die Anwendung adressierbaren Speicher.
Nicht im verbaubaren und vom System nutzbaren realen Speicher.
:
Bearbeitet durch User
Hallo, > Kaj schrieb: > Welche vorteile bietet eine 64bit Architektur, außer das mehr > (Arbeits-)speicher verwendet werden kann? ja nu, die Adressierbarkeit von Speicher ist ja nicht zwingend an die Achitektur gebunden. Man kann mit kleinen Kunstgriffen auch an einem 8Bit-Prozessor viel mehr als 64k adressieren. Aber der wesentliche Unterschied ist eben der 64Bit breite Datenbus und die mind. 64 Bit breiten Register und Verarbeitungsstrukturen in der ALU und sonstigen Teilen. Man kann also mit einem mal 64 Bit aus dem Speicher laden oder zurückschreiben. Ansonsten ist es so, dass die Verarbeitungsbreite mit der Komplexität der Architektur gekoppelt ist. Man braucht dafür also viel mehr Transitorfunktionen, weshalb man so hoch komplexe Schaltungen sinniger weise erst praktisch umsetzen kann, wenn der Integrationsgrad der Herstelltechnologie es gestattet. Neben der Verarbeitungsbreite hat sich zumindest bei PC-Prozessoren eben auch die Anzahl hochkomplexer Verarbeitungsfunktionen, die zusätzlich in Hardware gegossen werden, deutlich erhöht, einfach deshalb, weil man es eben kann. Gruß Öletronika
U. M. schrieb: > Man kann also mit einem mal 64 Bit aus dem Speicher laden oder > zurückschreiben. Das kann man bei PC-Prozessoren seit MMX in 64 Bits und seit SSE in 128 Bits Breite, aus Sicht des Programmierers. Schon bevor die 64-Bit Architektur kam. Intern ist das L1-Cache Interface schon lange für mindestens 64 Bits breite Zugriffe ausgelegt, der effizienten Fliesskommaverarbeitung wegen. Jenseits des L1-Caches besteht auch schon lange keinerlei Zusammenhang zwischen der Architektur und der Breite tatsächlich stattfindender Transfers mehr. Die obige Frage ist also schon berechtigt. Also wofür man die 64 Bits der amd64 Architektur brauchen kann. Blocktransfers konnte man schon vorher mit den oben genannten Befehlssätzen optimieren. Neben davon eher unabhängigen Änderungen im Befehlssatz und den Registern beeinflusst amd64 efektiv nur die Breite der Integer-Register, der Integer-ALUs und der Adressierung. Jenseits davon änderte sich wenig.
:
Bearbeitet durch User
U. M. schrieb: > Man braucht dafür also viel mehr > Transitorfunktionen, weshalb man so hoch komplexe Schaltungen sinniger > weise erst praktisch umsetzen kann, wenn der Integrationsgrad der > Herstelltechnologie es gestattet. Das ist zwar im Prinzip richtig. Aber der Zeitpunkt, zu dem man mit 64 Bit PC-Prozessoren anfing, war schon weit jenseits des Zeitpunkts, zu dem man das hätte implementieren können. Tatsächlich kamen 64-Bit PC-Prozessoren zu dem Zeitpunkt, zu dem sie hinsichtlich der Nutzung des Adressraums auf Servern im PC-Markt ernsthaft interessant wurden. Intel hatte selbst kein Interesse daran, x86 auf 64 Bits aufzubohren. Intel wollte die Leute allmählich zu IA64 migrieren. Darüber hatten sie volle Kontrolle, über den x86 Markt nicht. AMD durchkreuzte diese Strategie, mit damals ziemlichem Erfolg, auch im Serverbereich. Intel musste nachziehen und AMDs Architektur übernehmen. In anderen Bereichen waren 64 Bits viel früher dran. MIPS, Alpha, PowerPC hatten das alle schon in den 90ern. Deren Märkte konnten damit allerdings auch früher etwas anfangen als der PC-Markt, deren typische Anwendungen waren wesentlich speicherhungriger.
:
Bearbeitet durch User
Und welche Nachteile hat sie? -32 Bit Software ist deutlich langsammer... ...
uwe schrieb: > Und welche Nachteile hat sie? > -32 Bit Software ist deutlich langsammer... Aber nur selten wegen der 32 Bits.
Ich würde mir gut überlegen, ob: a) Wirklich mehr als 4 GByte adressieren muss b) Wirklich überwiegend 64 Bit Arithmetik brauche. c) Mir der "Kostenvorteil" egal ist. d) Es egal ist, dass meine 2 KByte Routine jetzt 4 KByte belegt. Einschließlich der dafür nötigen Übertragungszeit. e) Ob der Zugriff auf ein Einzelzeichen 8 Byte "Schaufelarbeit" bewirkt. Bedingt durch das Alignement des Compilers oft aus 4 Byte 8 Byte werden.
Amateur schrieb:shalb? > c) Mir der "Kostenvorteil" egal ist. Welcher? > d) Es egal ist, dass meine 2 KByte Routine jetzt 4 KByte belegt. Weshalb sollte sie das?
Zum Vergleich, cc1 vom avr-gcc 4.7.2: Gesamtgrösse des Files: 32-Bit: 7283476 64-Bit: 7566760 .text, also der Code: 32-Bit: 0x0053dfe4 64-Bit: 0x00528cdc .bss, also uninitialisierte statische Daten 32-Bit: 0x0005fc14 64-Bit: 0x00073ba0 .rodata, also Konstanten aller Art: 32-Bit: 0x000c5ba0 64-Bit: 0x00108420 Der 64-Bit Code ist also geringfügig kürzer als der 32-Bit Code. Die statisch allozierten Daten sind grob ein Viertel grösser, also auch nicht annähernd doppelt so gross.
:
Bearbeitet durch User
Amateur schrieb: > Ich würde mir gut überlegen, ob: ... f) ich Software (32- oder gar 16-Bit) einsetzen will, die unter 64-Bit Probleme macht und/oder Geräte benötige, für die es keine 64-Bit-Treiber gibt. Ja, das kommt in der Praxis noch oft genug vor.
Icke ®. schrieb: > f) ich Software (32- oder gar 16-Bit) einsetzen will, die unter 64-Bit > Probleme macht und/oder Geräte benötige, für die es keine 64-Bit-Treiber > gibt. Ja, das kommt in der Praxis noch oft genug vor. Yep. Kann bei Anwender-PCs eine Rolle spielen. Wobei in meinem Business-Umfeld eher steinalte Software-Versionen Ärger machen als Treiber. Die paar Inselsysteme mit exotischer Hardware dran bleiben ggf. wie sie sind. Beim Server freilich ist der Weg klar. Die aktuelle Server-Version von Microsoft (2012R2) gibts als 32-Bit-Version überhaupt nicht mehr.
:
Bearbeitet durch User
Die addressierung des Arbeitsspeichers hängt aber nicht nur von der Breite des Befehlssatzes ab. Siehe Segmentierung bei X86 oder PAE bei Intel 32 Bit Zu Win 32 vs 64 - ich hab gerade meinen Arbeitsrechner runter auf 32 Bit gebracht, weil einiges an Software nicht laufen will.
Hallo, deine Ausführungen sind schon richtig. Das zeigt aber eigentlich, dass die Prozessorarchitekturen nicht in einem Schritt von 32 auf 64Bit gesprungen sind, sondern eigentlich eher fließend, mit ständig zunehmender Breite in verschiedenen Strukturen der Architektur. Und natürlich stimmt auch der Einwand von A.K., dass man die 64 Bit-Prozessoren schon früher hätte einführen können. Natürlich spielen da noch diverse Randbedingungen eine Rolle. Gruß Ölektronika > A. K. schrieb: > Das kann man bei PC-Prozessoren seit MMX in 64 Bits und seit SSE in 128 > Bits Breite, aus Sicht des Programmierers. Schon bevor die 64-Bit > Architektur kam. > > Intern ist das L1-Cache Interface schon lange für mindestens 64 Bits > breite Zugriffe ausgelegt, der effizienten Fliesskommaverarbeitung > wegen. > > Jenseits des L1-Caches besteht auch schon lange keinerlei Zusammenhang > zwischen der Architektur und der Breite tatsächlich stattfindender > Transfers mehr. > > Die obige Frage ist also schon berechtigt. Also wofür man die 64 Bits > der amd64 Architektur brauchen kann. Blocktransfers konnte man schon > vorher mit den oben genannten Befehlssätzen optimieren.
U. M. schrieb: >> Welche vorteile bietet eine 64bit Architektur, außer das mehr >> (Arbeits-)speicher verwendet werden kann? > ja nu, die Adressierbarkeit von Speicher ist ja nicht zwingend an die > Achitektur gebunden. Man kann mit kleinen Kunstgriffen auch an einem > 8Bit-Prozessor viel mehr als 64k adressieren. Das ist nicht der Punkt. Praktisch jede Rechnerarchitektur die man heutzutage für Workstations oder Server benutzen will, hat virtuellen Speicher. Also ein Adressierungsschema, bei dem streng zwischen logischem und physischem Speicher unterschieden wird (die Abbildung macht die MMU). Und üblicherweise ist der logische Adreßraum größer. Viel größer. Das gibt einem die Flexibilität bei der (logischen) Speicherverwaltung aus dem Vollen zu schöpfen. "Wir brauchen insgesamt 3 Stacks, wissen aber vorher nicht wie groß die werden? Kein Problem; wir legen die Stacks einfach bei 1TB, 2TB und 3TB Anfangsadresse in den virtuellen Adreßraum. Dann kann jeder Stack bis 1TB anwachsen, bevor er mit irgendwas kollidiert. Da wir sowieso nicht soviel physisches RAM haben, kann das aber nie passieren." Das "Problem" der x86 Architektur ist nun, daß sie "nur" 4G virtuellen Adreßraum hat. Von denen bis zu die Hälfte noch durch die Teilung in Anwendungs- und Kernel-Adreßraum verloren geht. Man kann aber mittlerweile problemlos mehr als diese 4GB RAM an physischem RAM haben. Allerdings kann eine x86 Applikation dann blöderweise nicht mehr als 2GB davon nutzen. Das ist das Problem, das die x86_64 Architektur löst. Daß man dann nebenher noch mehr Register, neue Adressierungsarten, bessere SSE-Einheiten usw. dazu kriegt, ist ein Bonus. Das Gewurstel mit Banking, XMS und EMS tut sich heute keiner mehr an. Funktioniert in einer Mutithreaded Umgebung sowieso nicht bzw. ist im Fall von EMS auch bloß wieder durch die virtuelle Speicherverwaltung limitiert. Nur daß das 4GB Limit zu Zeiten von EMS keinen tangiert hat. Man war damals ja schon froh wenn man 16MB RAM hatte. XL
Axel Schwenke schrieb: > 1TB anwachsen, bevor er mit irgendwas kollidiert. Da wir sowieso nicht > soviel physisches RAM haben, kann das aber nie passieren." Häng noch ein paar Nullen ran, sonst geht es dir wie Bill Gates mit seinen 640KB. In einen 08/15 Intel Server von der Stange passen längst mindestens 384GB pro Prozessor-Sockel rein. In einen besseren 8-Sockler insgesamt 12TB. ;-) Und wer sich fragt, wozu man solche 12TB brauchen kann, der kann ja mal unter SAP HANA nachschlagen.
:
Bearbeitet durch User
A. K. (prx) schrieb: uwe schrieb: >> Und welche Nachteile hat sie? >> -32 Bit Software ist deutlich langsammer... > Aber nur selten wegen der 32 Bits. Stimmt doch real sowieso nicht. Läuft KiCad auf einem 64-bit Windows spürbar schneller als unter 32-bit? Läuft FreeCAD unter 64-bit schneller? Welche bekannte Anwendersoftware auf dem PC profitiert denn überhaupt von 64-bit? Gibt es eine? Die Nachteile treffen einen im Gegensatz dazu viel eher in Form von nicht mehr aktualisierten Treibern, deren HW dann nicht mehr läuft -> Tonne. Das permanente Geschrei nach immer mehr Speicher fördert zudem den neumodernen Lapsus entsprechend immer verschwenderischer mit Ressourcen umzugehen. Der Übergang einst von 16-bit zu 32-bit war wenigstens noch ein echter Meilenstein und Mehrgewinn - der zu 64-bit dagegen im Vergleich nur noch ein Bachkiesel. Der Serverbereich einzig und manche Spezialsoftware mag davon profitieren. Gängige Anwendersoftware tut es hingegen kaum bis gar nicht. Wenn da was schneller laufen soll, sollte man besser einfach mal seine alte HW austauschen und seinen lahmen Einkern- oder Zweikernprozessor in Rente schicken. Das bringt dann wenigstens was, gleich ab dem ersten Start der liebgewonnenen Programme bzw. schon beim Hochfahren des OS.
prg schrieb: > Welche bekannte Anwendersoftware auf dem PC profitiert denn > überhaupt von 64-bit? Gibt es eine? Ja, jede Menge. Alle die viel Speicher brauchen. Lade mal ein großes Bild in z.B. Gimp und arbeite damit. Habe gleichzeitig, wie normalerweise üblich noch ein paar andere Programme aktiv. Dann wirst du merken wie sehr einen die 3GB ausbremsen weil die meiste Zeit da für Ein- und Auslagern draufgeht.
Gaestchen (Gast) schrieb: prg schrieb: >> Welche bekannte Anwendersoftware auf dem PC profitiert denn >> überhaupt von 64-bit? Gibt es eine? > Ja, jede Menge. Alle die viel Speicher brauchen. Vielleicht unterscheiden wir uns in der Begriffsbestimmung was "viel" ist. Die allermeisten Dateien auf dem Rechner sind recht überschaubar in ihrer Größe und passen auf handelsübliche Datenträger wie USB-Sticks. > Lade mal ein großes > Bild in z.B. Gimp und arbeite damit. Mache ich ständig mit vielen Bildverarbeitungstools. Keine Probleme. Selbst wenn ich mit doch mal gelegentlich mit 1200 dpi scanne geht das. Ich wüsste nicht welche ultragroßen Pixelhaufen irgend eine praktische Relevanz hätten außer man ist vielleicht Artist. Aber so groß sind deren Dateien die man im Netz findet denn auch wieder nicht. > Habe gleichzeitig, wie > normalerweise üblich noch ein paar andere Programme aktiv. Dann wirst du > merken wie sehr einen die 3GB ausbremsen weil die meiste Zeit da für > Ein- und Auslagern draufgeht. Nö. Selbst wenn ich ein Dutzend Programme gleichzeitig offen halte und der Browser nur so strotzt vor offenen Tabs (einige 100) funktioniert das. Was du beschreibst hatte ich mit 2 GB unter Win7 mal, aber nicht mehr mit 4 GB. Einzig der FF zickt wenn er in die Nähe von 1 GB kommt und schmiert dann schon mal ab. Besonders im Zusammenhang mit im Browser geöffneten PDF die hunderte Seiten haben bekommt man das zu spüren. Die lade ich dann lieber erst herunter. Sehe keinen Grund, keine Vorteile zum Wechsel nach 64-bit.
Wenn du neben anderen Programmen noch ein paar virtuelle Maschinen auf dem PC laufen hast, dann wird Speicher sehr nützlich.
:
Bearbeitet durch User
prg schrieb: > Ich wüsste nicht welche ultragroßen Pixelhaufen irgend eine praktische > Relevanz hätten außer man ist vielleicht Artist. Aber so groß sind deren > Dateien die man im Netz findet denn auch wieder nicht. Ich bin zwar nur ein Hobby-Fotograf, aber meine 16 GB Speicher reize ich ganz gut aus. Dazu reicht es schon ein 20-megapixel Foto in Photoshop mit vielen Ebenen und Smartfiltern in 16 Bit Farbtiefe zu bearbeiten. Und das kommt doch recht häufig vor. Auch der Zusammenschnitt von Videos (ebenfalls nicht professionell) mit Premiere/After Effects frisst beliebig viel RAM. Insbesondere wenn man mit aufwändigen Filtern und Effekten arbeitet. Da könnte man selbst 32 GB RAM noch gut voll bekommen ;-) Hin und wieder mache ich dann auch mal 3D Animationen mit Blender. Deren Bearbeitung schluckt ebenfalls massig Speicher. Und wenn ich dann Abends mal eine Runde SupremeCommander mit Freunden zocke (8 Spieler schicken jeweils bis zu 1000 Einheiten über das Schlachtfeld), bin ich auch froh über jedes GB RAM, das ich habe :-) Du siehst also, auch in Privathaushalten kann man >= 16 GB RAM gut gebrauchen...
Wobei die Adressbreite ja eben nix mit der Bitbreite (32/64Bit) zu tun hat. Integer ist seit 386 32 Bit breit - wieviel Software braucht 64 Bit Integer? Float ist intern 80 Bit breit - bei 64 Bit immer noch (?) Wieso sollte Software schneller werden? Weil mehr auf SSE usw. gesetzt wird, was aber wiederum nichts mit 32/64 Bit zu tun hat
heinz schrieb: > Wobei die Adressbreite ja eben nix mit der Bitbreite (32/64Bit) zu tun > hat. Der Umfang möglichen physikalischen Speichers nicht. Sehr wohl aber die Adressbreite der einzelnen Programme. Und genau darum geht es. Der Adressraum eines 32-Bit Windows Programms ist auf 2GB begrenzt. Aufgrund diverser Löcher darin setzt sich dies in kaum mehr als 1GB von diesem Programm konkret nutzbaren physikalischen Speichers um. Ein 32-Bit Programm kann also i.d.R. nicht mehr als 1GB physikalischen Speichers direkt nutzen, egal wieviel im Rechner steckt. Programme mit grossem Speicherbedarf spüren das. Dazu kommt, dass 32-Bit Windows in der Client-Version effektiv auf 3-3,5GB physikalischen Speichers begrenzt, egal wieviel im Rechner steckt. Das ist eher eine künstliche als eine natürliche Begrenzung (erspart Microsoft Ärger mit doofen Treibern), denn der 32-Bit Windows Kern kann eigentlich mehr, wie die Server zeigen. Es begrenzt Systeme sehr spürbar, auf denen mehrere Programme mit grossem Speicherbedarf laufen, wie etwa virtuelle Maschinen.
:
Bearbeitet durch User
Axel Schwenke schrieb: > Daß man dann nebenher noch mehr Register, neue Adressierungsarten, > bessere SSE-Einheiten usw. dazu kriegt, ist ein Bonus. Wobei es genau dieser Bonus ist, der 64-Bit Versionen bestehender Programme auch dann etwas beschleunigen kann, wenn sie mit 2GB Adressraum locker auskommen.
heinz schrieb: > Float ist intern 80 Bit breit - bei 64 Bit immer noch (?) Nicht mehr, weil Compiler im den 32-Bit Programmiermodellen für normale Fliesskommaverarbeitung klassischen x87 Code verwenden ... > Wieso sollte Software schneller werden? ... in den 64-Bit Programmiermodellen aber den auch skalar effizienteren SSE-Code, der intern mit 32/64 Bits arbeitet. Wenn Compiler überhaupt noch 80-Bit "long double" unterstützen, dann geht es ziemlich bös ums Eck, weil die per x87 verarbeitet werden, float/double Rechnungen aber per SSE.
:
Bearbeitet durch User
>Nicht mehr, weil Compiler im den 32-Bit Programmiermodellen für >normale Fliesskommaverarbeitung klassischen x87 Code verwenden ... selbst wenn Du ein 32 Bit Float in die FPU lädst wurde (wird?) das intern als 80 Bit dargestellt. Ja, wenn der Compiler SSE usw. verwendet - dann wird die Software "schneller" das war aber unter 32 Bit auch so.
heinz schrieb: > selbst wenn Du ein 32 Bit Float in die FPU lädst wurde (wird?) das > intern als 80 Bit dargestellt. Nur bei x87. > das war aber unter 32 Bit auch so. Im 32-Bit ABI werden Return-Werte eines Fliesskommatyps im x87 Register-Stack übergeben. Im 64-Bit ABI werden Parameter und Return-Werte von 32/64-Bit Fliesskommatypen in SSE Registern übergeben. Ein Compiler wird - mindestens per default - für double a, b, c; a = b + c; im 32-Bit Programmiermodell x87-Code erzeugen, im 64-Bit Programmiermodell aber SSE-Code. Normaler portabler Code, der Fliesskommarechnung verwendet, wird also als 64-Bit Programm automatisch in SSE-Code übersetzt. Mit expliziter Programmierung für SSE-Befehle hat das nichts zu tun. Ursprünglich hatte Microsoft sogar fälschlich geschrieben, dass der x87 Kontext beim Task Switch nicht erhalten bliebe.
:
Bearbeitet durch User
Das stimmt alles was Du sagst. Aber das ist ist alles nur Abhängig von der Implementierung und nicht von der Bitbreite des Prozessors. Ich hab vor zig Jahren einen 4-fach PID auf MMX geschrieben. Was war wohl schneller? Ausgerollter FPU Code oder MMX Ich will eigentlich nur sagen, dass eine Verbreiterung der Register nicht automatisch "schneller" heist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.