wieso 64BIT und nicht gleich 128?

[greenvirus]

der sprung zu mehr bit, wie jetzt von 32 auf 64, aber schon früher von 16 auf 32, ist ein langes und kospieliges unterfangen. soviel ich mitbekommen habe, bringt es aber nur wegne einer 64bit obtimierung beriets durchschnittlich 10-15% mehr leistung (bitte korrigiert mich). wieso geht man nicht direkt auf 128? oder sogar auf 256? 512?



gruss und sorry für diese blöde frage:D




greenvirus

[Aqualon]

Weil du pro Bit eine Datenleitung brauchst und solange 64Bit völlig ausreichen, muss man sich nicht Gedanken machen, wie man 128 oder 256 Datenleitungen unterbringen soll.

Aqua

[Tesseract]

Original geschrieben von greenvirus
wieso geht man nicht direkt auf 128? oder sogar auf 256? 512?

weil der adressraum von 64bit vermutlich noch die nächsten paar jahrzehne reichen wird - selbst wenn die entwicklung so weitergeht wie bis jetzt ;)

und die 64bit selbst braucht man im alltagsgebrauch einfach kaum weil solche gewaltigen zahlen nicht wirklich vorkommen

genau genommen sind 64bit momentan eigendlich noch total überflüssig - AMD is seiner zeit praktisch um ein paar jahre vorraus

[greenvirus]

ok, vielen dank, aber etwas wundert mich noch

woher kommen dan die 10-15% mehr lesitung von 64bit optimierten anwendungen? wären es nicht noch mehr, wenn man auf 128bit optimieren würde?


gruss

[HellHorse]

Weil von 32 zu 64 bit der Addressraum nicht verdoppelt, sondern quadriert wird (und wirklich verdammt gross ist, falls wirklich 64 bit genutzt werden).

[greenvirus]

Original geschrieben von HellHorse
Weil von 32 zu 64 bit der Addressraum nicht verdoppelt, sondern quadriert wird (und wirklich verdammt gross ist, falls wirklich 64 bit genutzt werden).

und das ist der grund, für die 10%?

[Endorphine]

Original geschrieben von HellHorse
Weil von 32 zu 64 bit der Addressraum nicht verdoppelt, sondern quadriert wird (und wirklich verdammt gross ist, falls wirklich 64 bit genutzt werden). Der Adressraum verdoppelt sich mit jedem Adressbit. 33 Bit Adressraum sind 8 GiB, 34 Bit dann 16 etc.

Der physische Adressraum der AMD64-Architektur ist aber "nur" 40-Bit gross -> 1024 GiB (virtuell dann 48-Bit). Das sollte für die nächste Dekade ausreichen.

[CrazyIvan]

@ greenvirus

Das mit den 10 - 15% ist eigentlich nur ein Marketinggag. Das liegt daran, dass der Athlon64 im LongMode (64Bit) noch ein paar SSE Einheiten zuschaltet. Dadurch gehen halt manche Multimediaanwendungen und Packer etc. schneller.
Im Grunde könnten diese auch bei 32bit schon laufen, aber so kann man sagen:

"64 bit bringt 10 - 15%" - obwohl es nicht an den 64 Bit sondern nur an den zusätzlichen SSE Einheinten liegt.

Derzeit bringt 64 bit wohl keinem Mainstream Programm auch nur einen einzigen Prozent - auch nicht optimiert.

Die 64bit werden, glaube ich, zur Rechengenauigkeit genutzt. Da eine solche Genauigkeit aber (derzeit) nur für Wettervorhersagen, Atomtests etc. gebraucht wird, bringts dem Normalo ziemlich wenig.

Aber ist auch egal. Bin auch schon dem Marketing Virus erlegen und werde innerhalb der nächsten 6 Monate definitiv auf 64 bit umsteigen ;D

[Zool]

Zahlen wie 64, 128, 256Bit sind oft nur ein Marketing-Gag.

Bei der Adressierung bringen mehr als 64Bit nix. Selbst der Ahtlon 64 kann im Augenblick nur 2^40Byte ansprechen, und bis jetzt unterstützt kein aktuelles Board mehr als 4GB RAM.

@CrazyIvan
64Bit Genauigkeit können schon seit Urzeiten auch mit 8Bit-Rechnern genutzt werden. Echte 64Bit CPU-Register können daß nur schneller verarbeiten.

Seit dem 486 hat die FPU-Einheit 80Bit breite Register für schnelle 80Bit Float-Genauigkeit.
Aber auch 128Bit,256Bit... Integer/Float-Genauigkeit können mit entsprechenden Aufwand auf jeder akutellen CPU realisiert werden

Seit SSE stecken in jedem Pentium 3,4, Athlon XP... 128Bit SSE-Register drin.

[Endorphine]

Original geschrieben von Zool
[...] und bis jetzt unterstützt kein aktuelles Board mehr als 4GB RAM.[...] Der Opteron (bzw. Athlon 64-FX) kann dank registered/buffered DDR-SDRAM pro CPU eine ganz ordentliche Speichermenge ansprechen, nämlich derzeit bis zu 8 GiB pro CPU. Bei einem Quad-Opteron System dann derzeit bis zu 32 GiB. Damit sollten dann auch wirklich die grössten Enterprise-Server Anforderungen an Hauptspeichergrösse gestillt werden.

Mit IA32-CPUs geht's derzeit nur über Krücken wie PSE36 (lahm, viele Limitierungen). Und mit PSE36 ist bei 64 GiB dann auch endgültig Schluss. Der Intel PSE36-Treiber für Windows stellt mehr eine RAMDisk dar als echten klassisch nutzbaren Systemhauptspeicher. Und nur ein Task kann PSE36-Speicher zu einem Zeitpunkt nutzen. Einfach nur ein Notbehelf für grosse XeonMP-Server.

Echte 64-Bit Architekturen sind längst notwendig und auch bereits im Einsatz. Nur im Desktopbereich noch nicht. Aber auch im artverwandten Workstationbereich sind 3,5 GiB nutzbarer Hauptspeicher schon zu wenig. AMD64 ist kein Marketinggag, allenfalls beim Sockel-754 und Sockel-939 Athlon 64-FX kann man davon sprechen.

Irgendwann muss neue Technik aber über den Massenmarkt eingeführt werden. T&L hat bei der Einführung in der GF1 auch noch keinen Nutzen gehabt. Die meisten User haben die Hardware gekauft ohne mit den Fähigkeiten etwas sinnvolles anfangen zu können. Später war dann die T&L-Marktdurchdringung gross genug, so dass die neuen Fähigkeiten ausgenutzt werden konnten.

Gleiches mit 64-Bit Architekturen. IMHO kann man AMD nichts vorwerfen. Eher Intel, die mit IA64 wieder mal viel zu ehrgeizige Ziele verfolgen und nun eine Architektur haben, die derzeit nicht Massenmarkt-tauglich ist, da zu aufwändig und unwirtschaftlich im Desktopmarkt.

[BlackBirdSR]

Irgendwer sagte mal:
Warum 128Bit Adressierung?
Wieso sollte ich denn jedes Atom im Universum adressieren wollen? ;)

In der Hinsicht machen 128Bit also keinen großen Sinn. (jetzt und in naher Zukunft).
Was 128Bit breite Register und Datenformate angeht:
128Bit breite Register gibt es z.B mit SSE. Datenformate dazu findet man aber ungleich schwerer. Zumal man dies durch 2x64Bit Register ebenfalls erreichen kann. Natürlich langsamer. Aber wie gesagt: Wer braucht ein 128Bit Datenformat?

Selbst IA64 gibt sich mit max. 82Bit bei Fließkommaberechnungen zufrieden.

Es gibt einfach keine Zahlen oder Wertebereiche in heutiger Software, die so groß wären, dass man sie ständig nutzen müsste. Somit gibt es auch keinen Grund sich teure 128Bit Register zuzulegen.

Vielleicht bringen uns die VLIW Rechner mal in der Hinsicht etwas weiter..

[Gast]

64-bit bringt zurst einmal gar nichts,ausser vielleicht bei einigen wenigen anwendung wo der 4GB-adressraum nichtmehr ausreicht.
Im gegenteil, der "verschnitt" wird sogar grösser, was die performance erstmal drückt. (will ich nur einen wert übertragen der 8-bit umfasst,werden trotzdem 64 bit übertragen --> 56bit "verschnitt")
Der eigentliche Geschwindigkeitsvorteil beim A64 wird sich beim Umstieg auf ein 64-Bit Windows dadurch ergeben,daß der Prozessor unter 64bit doppelt soviele Register zur verfügung stellt.

[HellHorse]

Original geschrieben von Endorphine
Der Adressraum verdoppelt sich mit jedem Adressbit. 33 Bit Adressraum sind 8 GiB, 34 Bit dann 16 etc.

Der physische Adressraum der AMD64-Architektur ist aber "nur" 40-Bit gross -> 1024 GiB (virtuell dann 48-Bit). Das sollte für die nächste Dekade ausreichen.
Habe ich was anderes geschrieben?
2^64 sind doch (2^32)^2?

[BlackBirdSR]

Original geschrieben von Gast
64-bit bringt zurst einmal gar nichts,ausser vielleicht bei einigen wenigen anwendung wo der 4GB-adressraum nichtmehr ausreicht.
Im gegenteil, der "verschnitt" wird sogar grösser, was die performance erstmal drückt. (will ich nur einen wert übertragen der 8-bit umfasst,werden trotzdem 64 bit übertragen --> 56bit "verschnitt")
Der eigentliche Geschwindigkeitsvorteil beim A64 wird sich beim Umstieg auf ein 64-Bit Windows dadurch ergeben,daß der Prozessor unter 64bit doppelt soviele Register zur verfügung stellt.

Da ich die Anzahl an Bits der Register nicht als Gesamtraum betrachte, spielt Verschnitt hier in Sachen Leistung keine Rolle.

Klar habe ich 56Bit Verschnitt, wenn ich nur einen 8Bit Datentyp in ein Register lade.
Aber es ist ja nicht so, dass ich diese 56Bit irgendwo sonst nutzen könnte (SIMD nicht mit einbezogen).

Ob ich jetzt 24Bit (32Bit Register) oder 56Bit (64Bit Register) Verschnitt habe, Das Register ist jedesmal belegt und nicht weiter Nutzbar. (bzw wird mit 0 aufgefüllt)

Leistungseinbußen gibt es aber z.B bei der Multiplikation, die bei 32Bit Datentypen 2(?) Takte weniger benötigt als mit 64Bit. Dafür kann man die Anzahl an benötigten Multiplikationen stark senken wenn man 64Bit Datentypen braucht. Liegt wohl wieder in der Hand des Compilers ;)

[GloomY]

Original geschrieben von Aqualon
Weil du pro Bit eine Datenleitung brauchst und solange 64Bit völlig ausreichen, muss man sich nicht Gedanken machen, wie man 128 oder 256 Datenleitungen unterbringen soll.

Aqua Nicht nur das. Man braucht auch ALUs/FPUs/AGUs, die 128 Bit möglichst in einem Takt verarbeiten können (um nicht an Geschwindigkeit zu verlieren). D.h. die Schaltungen werden komplexer und die Laufzeiten der Schaltungen dauern länger, was die Taktbarkeit der Chips verschlechtert. Kein Wunder, dass der Hammer für eine normale Integer Multiplikation im 64 Bit Modus 4 statt 3 Takte (32 Bit) benötigt.
Original geschrieben von greenvirus
ok, vielen dank, aber etwas wundert mich noch

woher kommen dan die 10-15% mehr lesitung von 64bit optimierten anwendungen? wären es nicht noch mehr, wenn man auf 128bit optimieren würde?


gruss 8 neue General Purpose Register, 8 neue SSE Register und die FPU ist nicht mehr stackbbasiert. Das bringt ein gutes Stückchen mehr Leistung. Mit 64 Bit hat das eigentlich gar nichts zu tun. Nur hat man bei der Umstellung der ISA auf 64 Bit gleich die Chance erkannt und ein paar alte Beschränkungen über Bord geworfen.

Digital hat als es vor Jahren um die Umstellung der Vax (32 Bit) auf die Alpha (64 Bit) ging, bezüglich der Geschwindigkeit von 64 und 32 Bit herausgefunden, dass 64 Bit im Schnitt 5% langsamer ist, weil die Codedichte auf Grund der größeren Adressen geringer ist.
Bei AMD gilt dies in etwa analog, bloss hat man hier im Gegenzug noch die erwähnten Optimierungen gemacht, so dass im Schnitt eine Geschwindigkeitsverbesserung heraus kommt. Es gibt aber durchaus auch einzelne Applikationen, die langsamer laufen (irgendwas aus dem SPEC Bench), aber wenn man das weiss, kann man ja diese Applikation im 32 Bit Modus kompilieren und man hat wieder die alte Geschwindigkeit. Man kann also jede Applikation für die schnellere ISA kompilieren und damit das Maximum an Geschwindigkeit herausholen. Andere Features (wie z.B. Intel SMT) kann man nur global an- oder ausstellen. Aber ich weiss, ich schweife ab... ;)
Original geschrieben von BlackBirdSR
Was 128Bit breite Register und Datenformate angeht:
128Bit breite Register gibt es z.B mit SSE.Wobei man hier nicht die 128 bit einzeln benutzen kann sondern es eigentlich 4 32 Bit (SSE) bzw. 2 64 Bit Register (SSE2) sind.
Original geschrieben von HellHorse
Habe ich was anderes geschrieben?
2^64 sind doch (2^32)^2? Ja, (2^32)^2 = (2^32)*(2^32), also 2^32 mal so viel Adressen wie bisher und nicht nur 2 oder 4 mal so viel:
Original geschrieben von HellHorse
Weil von 32 zu 64 bit der Addressraum nicht verdoppelt, sondern quadriert wird (und wirklich verdammt gross ist, falls wirklich 64 bit genutzt werden).

[Endorphine]

Original geschrieben von HellHorse
Habe ich was anderes geschrieben?
2^64 sind doch (2^32)^2? Stimmt natürlich. Hab zu schnell gelesen und in meinem Kopf wurde aus "quadriert" ein "vervierfacht" :|

Zu meiner Ehrenrettung: AMD64 hat aber dennoch keinen 64-Bit großen Adressraum, das Posting passt also weiterhin :)

[x-dragon]

Könnte man nicht mit diesem Programm http://home.t-online.de/home/zsack/mandelbrot.html 128 Bit sinnvoll nutzen? :)

[Tigerchen]

Original geschrieben von Gast
64-bit bringt zurst einmal gar nichts,ausser vielleicht bei einigen wenigen anwendung wo der 4GB-adressraum nichtmehr ausreicht.
Im gegenteil, der "verschnitt" wird sogar grösser, was die performance erstmal drückt. (will ich nur einen wert übertragen der 8-bit umfasst,werden trotzdem 64 bit übertragen --> 56bit "verschnitt")
Der eigentliche Geschwindigkeitsvorteil beim A64 wird sich beim Umstieg auf ein 64-Bit Windows dadurch ergeben,daß der Prozessor unter 64bit doppelt soviele Register zur verfügung stellt.

Das Aufblähen von 64-Bit Programmen ist bei AMD`s Lösung noch recht moderat.Ich hab die Zahlen nicht im Kopf.Aber Intel's Konzept siehr dagegen richtig schlecht aus.

Und das mit dem 4GB Adressraum ist so eine Sache.Unter Windows sind davon ohne wirkliche Klimmzüge nur 2GB nutzbar.Viele User entdecken aber jetzt schon die Lust an 1GB RAM.Da ist also gar nicht mehr sehr viel Spielraum im Adressraum.

[GloomY]

Original geschrieben von X-Dragon
Könnte man nicht mit diesem Programm http://home.t-online.de/home/zsack/mandelbrot.html 128 Bit sinnvoll nutzen? :) Ja, das hat Zeckensack auch schon mal irgendwo ausgeführt. Trotz Suchfunktion finde ich den Thread aber nicht mehr :(

[zeckensack]

Original geschrieben von GloomY
Ja, das hat Zeckensack auch schon mal irgendwo ausgeführt. Trotz Suchfunktion finde ich den Thread aber nicht mehr :( Nimm den hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=49075) :)

[GloomY]

Original geschrieben von zeckensack
Nimm den hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=49075) :) Ja, aber dort drin habe ich das was ich suche, leider nicht gefunden :( Eigentlich gucke ich nach deiner Ausführungen, wie viele Multiplikationen und Additionen eine einzelne Extreme-Float Multiplikation benötigt. In dem Zusammenhang hattest du auch den Speed-Up für 64 Bit Systeme erwähnt (IIRC Faktor 4).

[zeckensack]

Original geschrieben von GloomY
Ja, aber dort drin habe ich das was ich suche, leider nicht gefunden :( Eigentlich gucke ich nach deiner Ausführungen, wie viele Multiplikationen und Additionen eine einzelne Extreme-Float Multiplikation benötigt. In dem Zusammenhang hattest du auch den Speed-Up für 64 Bit Systeme erwähnt (IIRC Faktor 4). Das kann ich dir auch nochmal vorrechnen :)
Multiplikation einer 192-Bit-Mantisse
32 bit ALU (6*32) | 64 bit ALU (3*64)
36 MULs, 45 ADDs | 9 MULs, 18 ADDs
Dazu kommt dann noch fixup (aka 'Renormalisierung') und die Addition des Exponenten, aber das ist einfach linear. 64 bit sind hierbei exakt doppelt so schnell wie 32 bit.

Ganz genau genommen müsste man jetzt noch die MUL-Latenzen des Opteron einrechnen, das ist mir jetzt aber ein bisserl zu kompliziert (Scheduling spielt hier eine große Rolle).

Wen's interessiert:;multiply two extremefloats. assumes both operands are nonzero
;prototype:
;void x86_xfloat_mul(ExtremeFloat* target,ExtremeFloat* src)
_x86_xfloat_mul:
PUSHA
MOV ESI,[ESP+36]
MOV EDI,[ESP+40]

MOV EAX,[EDI+24] ;add exponents
ADD [ESI+24],EAX

MOV EAX,[EDI+28] ;adjust sign
XOR [ESI+28],EAX

SUB ESP,44 ;allocate 352 bit temporary product

MOV EAX,[EDI] ;multiply 0*0, we only need the high DWORD
MOV EBX,EAX
MUL dword [ESI]
MOV [ESP],EDX
MOV ECX,-5
.mul_0_loop: ;multiply remaining bits with lowest significance rhs' DWORD
MOV EAX,EBX
MUL dword [ESI+4*ECX+24]
ADD [ESP+4*ECX+20],EAX
ADC EDX,0
MOV [ESP+4*ECX+24],EDX
INC ECX
JNZ .mul_0_loop

MOV ECX,-5
.mul_loop: ;perform remaining 5*6 multiplies and accumulate product on stack
MOV EAX,[ESI+4*ECX+24]
MUL dword [EDI+4]
ADD [ESP+4*ECX+24],EAX
ADC [ESP+4*ECX+28],EDX
SETC BL
MOVZX EBX,BL

MOV EAX,[ESI+4*ECX+24]
MUL dword [EDI+8]
ADD [ESP+4*ECX+28],EAX
ADC EDX,EBX
ADD [ESP+4*ECX+32],EDX
SETC BL
MOVZX EBX,BL

MOV EAX,[ESI+4*ECX+24]
MUL dword [EDI+12]
ADD [ESP+4*ECX+32],EAX
ADC EDX,EBX
ADD [ESP+4*ECX+36],EDX
SETC BL
MOVZX EBX,BL

MOV EAX,[ESI+4*ECX+24]
MUL dword [EDI+16]
ADD [ESP+4*ECX+36],EAX
ADC EDX,EBX
ADD [ESP+4*ECX+40],EDX
SETC BL
MOVZX EBX,BL

MOV EAX,[ESI+4*ECX+24]
MUL dword [EDI+20]
ADD [ESP+4*ECX+40],EAX
ADC EDX,EBX
MOV [ESP+4*ECX+44],EDX
INC ECX
JNZ .mul_loop

;we now have 352 bits of the product on the stack
;the high 192 bits are the new result mantissa
MOVQ mm0,[ESP+20]
MOVQ mm1,[ESP+28]
MOVQ mm2,[ESP+36]
MOVQ [ESI],mm0
MOVQ [ESI+8],mm1
MOVQ [ESI+16],mm2
EMMS

;a few more bits might be needed for rounding
;and if the msb is clear we shift everything left and need another bit
MOV EDI,[ESP+16]
ADD ESP,44 ;deallocate temp result
TEST EDX,EDX
JNS .shift

INC dword [ESI+24] ;adjust exponent
JMP .round_to_nearest
.shift:
SHLD dword [ESI],EDI,1
RCL dword [ESI+4],1
RCL dword [ESI+8],1
RCL dword [ESI+12],1
RCL dword [ESI+16],1
RCL dword [ESI+20],1
SHL EDI,1 ;we already used one bit

.round_to_nearest:
XOR EAX,EAX
ADD EDI,EDI ;get rounding adjustment into carry flag
ADC [ESI],EAX
ADC [ESI+4],EAX
ADC [ESI+8],EAX
ADC [ESI+12],EAX
ADC [ESI+16],EAX
ADC [ESI+20],EAX
JS .finished
;rounding has moved the msb yet again
RCR dword [ESI+20],1
RCR dword [ESI+16],1
RCR dword [ESI+12],1
RCR dword [ESI+8],1
RCR dword [ESI+4],1
RCR dword [ESI],1
INC dword [ESI+24] ;adjust exponent
.finished:
POPA
RETN

[Darkstar]

Welche Bereiche des Arbeitsspeichers (genauer: des Adreßraums) werden eigentlich von PCI-Karten bei Rechnern mit mehr als 4 GiB RAM belegt? Wird der Speicher dann zerstückelt, so wie es früher im DOS der Fall war?