Gegenüberstellung AMD64 - EMT64

eaglo · 25.03.2005

hi!
ja ... die/das eigentlich/e frage/threadthema steht eh schon in der überschrift

Dresdenboy · 25.03.2005

EM64T ist auf jeden Fall zur ersten dokumentierten AMD64-Version kompatibel. Mittlerweile sind vielleicht schon die letzten Unterschiede auf Befehlsebene beseitigt. Ein großer Unterschied besteht noch: IOMMU-Unterstützung, welche bei EM64T fehlt.

Auf Befehlsebene ist es ähnlich wie in 32bit: höhere Latenzen bei einigen komplexen Befehlen bei EM64T, sonst im Großen und Ganzen ähnliche Ausführungszeiten.

Wie sich das dann in der Realität auswirkt, sieht man z.B. hier:
http://www.techreport.com/reviews/2005q1/64-bits/index.x?pg=1

Interessant ist, daß sich Sandra mit den synthetischen Tests (optimierte Schleifen, die offensichtlich wie z.B. bei ALU und Whetstone-Tests komplett im Cache ablaufen) das Bild von der Realität entfernt.

eaglo · 25.03.2005

gibt es auch sachen die bei emt64 implementiert wurden, die aber bei amd64 nicht vorkamen ??

HenryWince · 25.03.2005

Vorneweg: Für den Normal-Nutzer spielen die Unterschiede keine Rolle. Zu erwartende Unterschiede (CPUID/SSE3/HT/3DNow/MSRs/Microcodeupdate/etc.) lass ich mal weg.

- CMPXCHNG16B wird von AMD bisher nicht unterstützt (evtl. im E-Stepping?)

- SYSCALL & SYSRET funktionieren bei AMD64 auch im 32 Bit Mode

- SYSENTER & SYSEXIT werden von Intel auch im 64 Bit Mode unterstützt

- LAHF & SAHF werden von AMD auch im 64 Bit Mode unterstützt (nutzt z.B. VMware).

- Fast-FXSAVE/FXRSTOR: AMD64 :Support für reduced FP state. Intel speicher immer den vollem FP state.

- BSF/BSR im 64 Bit Mode lieftet bei Operand Size 32 Bit den Index als 32 Bit Wert in das Zielregister (AMD64). Intel promoted den Index auf 64 Bit.

- Physical Memory: Bei AMD64 theoretisch 1TB, bei EM64T weniger (E7525 z.B. auf 32GB limitiert)

Dann gibts noch unterschiedliches Verhalten bei eigentlich undefinierten Kombinationen (z.B. Near Brachens mit Operand Size Overwrite Prefix Byte).

Für die Praxis ist wohl eine Eigenschaft der integrierten Northbridge von AMD64 CPUs relevent:

AMD CPUs besitzen eine IOMMU mit der man per DMA auf Speicher > 4GB zugreifen kann. Bei Intel können Geräte nicht dirket auf diesen Speicherbereich zugriefen. D.h. der entsprechende Treiber muss dann bounce-buffering machen.

Dresdenboy · 25.03.2005

Um HenryWince's Liste zu vervollständigen:
Bei Intel gibt es keine 3DNow!-Befehle (die sollen aber eh nicht im 64bit-Modus genutzt werden) und AMD hat zwar SSE3 übernommen, aber 2 weitere Befehle des Prescotts nicht, die bei Hyperthreading interessant sind.

eaglo · 25.03.2005

3DNow ist klar

und diese 2 weitere Befehle ? wäre das nicht ineressant für Dual Core ... was sind das genau für befehle ?

HenryWince · 25.03.2005

@Dresedenboy

Die Sachen hab ich explizit raus gelassen weil das eigentlich nix mit 64 Bit zu tun hat.

@egalo

MWAIT und MONITOR. Diese Befehle zählt Intel seltsamerweise zu SSE3. Wie Intel darauf kommt ist mir Schleierhaft, denn die Befehle haben weder mit Streaming noch mit SIMD irgendetwas zu tun. Ich tippe mal wieder auf die Marketing-Etage....

Prinzipiell liesen sich die Befehle auch bei in AMD's Dual-Core implementieren, aber irgendwie glaub ich nicht so recht daran. Intel's HT zieht aus diesen Befehlen einen Vorteil in dem es die Execution Resourcen an den zweitn Thread abgeben kann -- bei AMD wäre das ind der Form nicht gegeben.

Bokill · 25.03.2005

Die zwei Sonderbefehle neben den Ergänzungen zur SIMD-Einheit hat was mit SMT und Threadsynchronisation zu tun. Mir ist es genauso schleierhaft wie HenryWince, warum dies als SSE3 Feature verkauft wird ... Na ja Marketing.

SSE Technology in New Intel Prescott Processors

Hyper-Threading support improvement
MONITOR/MWAIT The processor tracks the writes into the selected part of memory and activates the “sleeping” data streams.

http://www.xbitlabs.com/articles/cpu/display/prescott-sse_6.html

Etwas aktueller der Anandartikel: AMD K8 E4 Stepping: SSE3 Performance

With SSE3, Intel added 10 new instructions targeted at SIMD as well as 3 other instructions that don't touch the SSE registers (fisttp, monitor, mwait). Here's a brief list of SSE3 instructions and what they are for:

x87 floating point to integer conversion (fisttp)
Complex arithmetic (addsubps, addsubpd, movsldup, movshdup, movddup)
Video encoding (lddqu)
Graphics (haddps, hsubps, haddpd, hsubpd)
Thread synchronization (monitor, mwait)

MFG Bokill

Starcraftfreak · 25.03.2005

Original geschrieben von HenryWince
- Physical Memory: Bei AMD64 theoretisch 1TB, bei EM64T weniger (E7525 z.B. auf 32GB limitiert)

Ist das nicht auf den Speichercontroller zurückzuführen? D.h., könnte Intel theoretisch mit einem neuen MCH auf 1TB nachziehen? (wäre nach meiner Überlegung logisch)

Der IMC ist eben eine Besonderheit des K8, welcher sich allerdings auch unter 32-bit nicht unerheblich auswirkt. Die Frage ist, welche Art des Speichercontrollers zu bevorzugen ist. Bei Intel könnte man mit einem anderen Mainboard komplett anderen Speicher einsetzen und die CPU gegebenenfalls weiterverwenden. Aufgrund des bevorstehenden Umstiegs auf FB-DIMM im professionellen Bereich ist das nicht ganz unerheblich. Bei AMD wäre ein neues Mainboard (wegen der DIMM Slots) sowie eine neue CPU (wegen dem MC) fällig. Dabei stellt sich dann auf der blauen Seite auch die Frage, ob man nicht bei einem neuen Mainboard gleich auch eine neue, (hoffentlich) schnellere CPU kauft.

mtb][sledgehammer · 26.03.2005

Original geschrieben von Starcraftfreak
Ist das nicht auf den Speichercontroller zurückzuführen? D.h., könnte Intel theoretisch mit einem neuen MCH auf 1TB nachziehen? (wäre nach meiner Überlegung logisch)

Aufgrund des klassishen FSB des P4 würde ich annehmen, dass der maximal adressierbare Speicher auch von der Anzahl der physikalischen Adressleitungen des FSB abhängig ist. Dann kommts eben darauf an, ob diese Anzahl beim Umstieg vom Northwood auf Prescott (mit LGA 775) erweitert wurde.

HenryWince · 26.03.2005

@Starcraftfreak

Ist das nicht auf den Speichercontroller zurückzuführen? D.h., könnte Intel theoretisch mit einem neuen MCH auf 1TB nachziehen? (wäre nach meiner Überlegung logisch)

Das ginge, nur bleibt die Frage wie man an EINEM MCH entsprechend viel Speicher Anschließen sollte... Bei AMD skaliert das physikalische Memory mit der Anzahl der CPUs (=> >8 way gibts mit Horus).

BTW. die EM64T CPUs selbst können jetzt schon mit 1TB (=40 Bit) umgehen. Per CPUID 80000008h kann man die unterstützen Virtual und Physical Adress Sizes auslesen.

Die Frage ist, welche Art des Speichercontrollers zu bevorzugen ist. Bei Intel könnte man mit einem anderen Mainboard komplett anderen Speicher einsetzen und die CPU gegebenenfalls weiterverwenden. Aufgrund des bevorstehenden Umstiegs auf FB-DIMM im professionellen Bereich ist das nicht ganz unerheblich.

Klar bringt eine externer MC Flexibilität, aber wirklich nutzen tut es dem Kunden nicht. Wenn man sich für einen neuen Speicherstandard entschließt ändert sich so viel an der Peripherie, das die CPU zur Nebensache wird. Im Komerziellen Bereich kommt keiner auf die Idee alte CPUs in einem neuen Rechner zu recyclen -- das machen nur Privatleute.

Bei AMD wäre ein neues Mainboard (wegen der DIMM Slots) sowie eine neue CPU (wegen dem MC) fällig. Dabei stellt sich dann auf der blauen Seite auch die Frage, ob man nicht bei einem neuen Mainboard gleich auch eine neue, (hoffentlich) schnellere CPU kauft.

Im Endeffekt kommt man kaum billiger weg. Ob ich nun MB+Speicher neu kaufe und mein altes MB+Speicher verticke oder MB+Speicher+CPU neu kaufe und das alte Zeug komplett verkaufe ist finanzielle gesehen kein großer Unterschied. Vorteile bei der "Komplett-Neukauf-Lösung" sind:
- Garantie auf alle Teile
- Möglichkeit aktuelle CPU mit höherer Leistung zu wächlen
- Ggf. mitnehmen von anderen "Einkaufsvorteilen" (z.B. bei Komplettrechnern ein aktuelles SW Bundle)

@mtb][sledgehammer

Aufgrund des klassishen FSB des P4 würde ich annehmen, dass der maximal adressierbare Speicher auch von der Anzahl der physikalischen Adressleitungen des FSB abhängig ist. Dann kommts eben darauf an, ob diese Anzahl beim Umstieg vom Northwood auf Prescott (mit LGA 775) erweitert wurde.

Es gibt beim P4 Bus längst keine dedizierten Address-Leitungen mehr, das läuft alles Message basiertes Protokoll ab.

eaglo · 26.03.2005

Original geschrieben von HenryWince
Es gibt beim P4 Bus längst keine dedizierten Address-Leitungen mehr, das läuft alles Message basiertes Protokoll ab.

was ?? wäre das nicht extrem verlangsamend ?

Starcraftfreak · 26.03.2005

Original geschrieben von HenryWince
Das ginge, nur bleibt die Frage wie man an EINEM MCH entsprechend viel Speicher Anschließen sollte... Bei AMD skaliert das physikalische Memory mit der Anzahl der CPUs (=> >8 way gibts mit Horus).

Multi-Core MCH 8)

Man könnte analog zu AMD mehrere Memory-Controller verwenden. Die technische Umsetzung ist eine andere Sache, doch wozu gibts die Intel-Ingenieure eigentlich.

Deine Argumentation bezüglich MCH vs IMC ist verständlich.

mtb][sledgehammer · 26.03.2005

Original geschrieben von HenryWince
@mtb][sledgehammer
...
Es gibt beim P4 Bus längst keine dedizierten Address-Leitungen mehr, das läuft alles Message basiertes Protokoll ab.

Hmm, ich habe eben folgendes gelesen:
http://sandpile.org/impl/p4.htm

Code:

Processor Buses  Address Bus Width  36 Bit
                 Data Bus Width     64 Bit
                 Physical Memory    2^36 Bit = 64 GB
                 Virtual Memory     IA-32: 2^32 Bit = 4 GB
                                    EM64T: 2^48 Bit = 256 TB 
                 Logical Memory     IA-32: (8,190 + 8,192) x 4 GB = 65,528 GB (~64 TB)
                                    EM64T: n/a

Und daraus den Schluss gezogen, dass irgendwo noch die physikalischen Adressleitugen als Limitierung existieren müssen *noahnung*

Weißt du wie das dann zu verstehen ist? (Beim K8 werden die Adress und Datenbusleitungen nicht mehr explizit auf sanspile angegeben)

Edit: Zum Thema 8P: Das geht auch ohne Horus

http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=210372

Bokill · 26.03.2005

Wie denn auch ... Der Hypertransportlink hat ja ein gänzlich anderes Übertragungsprotokoll.

Bei dem K7 gab es ja noch separate Daten und Adressleitungen (zwar auch schon Punkt zu Punkt, aber die Adressenübermittlung lehnte sich noch an Busdesigns an).

Der Pentium M kann auch auf normalen P4 Boards lediglich 32Bit Speicher adressieren. Die Limitierungen sind also auch in der CPU selber.

MFG Bokill

Dresdenboy · 26.03.2005

Nochmal kleine Übersicht der Adreßräume für AMD64:
- bis 64 bit virt. Adreßraum implementierbar
- bis 52 bit phys. Adreßraum implementierbar
- 48 bit virt. Adreßraum z.Z. beim Opteron, sowie
- 40 bit phys. Adreßraum

Das findet man z.B. hier:
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/RichBrunnerClusterWorldpresFINAL.pdf

PuckPoltergeist · 26.03.2005

Original geschrieben von mtb][sledgehammer
Edit: Zum Thema 8P: Das geht auch ohne Horus

Jupp, bis 8 CPUs, HenryWince schrieb aber >8.

HenryWince · 26.03.2005

@mtb][sledgehammer

Und daraus den Schluss gezogen, dass irgendwo noch die physikalischen Adressleitugen als Limitierung existieren müssen Weißt du wie das dann zu verstehen ist?

Ich habs nachgeschaut:
Du hast recht, Intels FSB besitzt Addressleitungen und zwar 33 an der Zahl! Mea culpa.

Die 36 Bit Physische Adressbreite ergibt sich 33 Bit-Speicheradressen die jeweils 8 (=2^3) Byte addressieren. D.h. nach aussen werden immer nur 64 Bit Wörter gelesen oder geschrieben. Somit kann ein Intelchipset das mit jetziger FSB-Technologie arbeitet maximal 64GB unterstützen. Tatsächlich kaufen kann man heute ein Chipset das 32GB (PC2100) unterstützt.

Ich war heute früh voll auf dem falschen Dampfer

Liegt daran, dass ich gerade mit jemandem über die P4 Cachekohernz-Implementierung gemailt hatte: Dazu muss man wissen, dass der FSB bis zu zwölf ausstehende Transactions unterstützt. Irgenwie war ich dann Fest davon überzeugt, dass Transactions => Messaging sein muss (hätte nicht gedacht das Intel selbst bei LGA775 immer noch den GTL+ Mist nutzt). *buck*

BTW. Auf diesen "Addressleitungen" werden aber auch andere Informationen übertragen so gesehen sind sie nicht ganz dediziert. Irgendwie erstaunlich das Intel das noch nicht modernisiert hat. Die Zukunft liegt jedenfals eindeutig in einem Message basierten Interface a la HT oder PCIe.

@Starcraftfreak

> Multi-Core MCH

Ist keine Lösung, auch mehrere FSB's wäre keine. Solange der FSB zu wenige Adressleitungen hat gibts nicht mehr als 64GB physisch

@egalo
> [Message basiertes FSB Protokoll] was ?? wäre das nicht extrem verlangsamend ?

Nicht notwendigerweise -- es kommt etwas Logik dazu, dafür kann man entweder Pins einsparen oder die Bandbreite deutlich erhöhen. Bei nem Opteron liegt die Speicherlatenz auf das Remote Memory ziemlich in der Größenordnung in der bei Intel der normale Memoryzugriff liegt. Hier läuft der Speichertransfer auch über ein Message basiertes Protokoll.

eaglo · 26.03.2005

Original geschrieben von HenryWince

> Multi-Core MCH

Ist keine Lösung, auch mehrere FSB's wäre keine. Solange der FSB zu wenige Adressleitungen hat gibts nicht mehr als 64GB physisch

außer du schaltest immer um, dann gehts schon

PuckPoltergeist · 26.03.2005

Original geschrieben von HenryWince
(hätte nicht gedacht das Intel selbst bei LGA775 immer noch den GTL+ Mist nutzt).

Wenn sie es selbst für den Itanium nutzen (der ja einen ganz anderen Einsatzbereich adressiert), wundert mich das nicht wirklich. Der GTL-Bus wurde bis jetzt immer nur leicht aufgebohrt, weil Intel gar keine Notwendigkeit hatte, da grundlegend etwas zu ändern. Würde ja ein komplettes Neudesign erforderlich machen. So konnten sie immer wieder auf die alten Bibliotheken zurück greifen.
Beim Itanium hätten sie natürlich schon was "anständiges" nehmen können. Da sie dort eh mit jeglicher Kompatibilität gebrochen haben, hätten sie dem Teil auch gleich ein anständiges Interface spendieren können. Möglicherweise wäre der dann auch nicht so ein Cache-Monster geworden.

mtb][sledgehammer · 26.03.2005

Original geschrieben von PuckPoltergeist
Jupp, bis 8 CPUs, HenryWince schrieb aber >8.

Da war ich wohl auch nicht ganz bei der Sache

@ HenryWince: Danke für die aktualisierten Infos

Starcraftfreak · 28.03.2005

Original geschrieben von HenryWince
hätte nicht gedacht das Intel selbst bei LGA775 immer noch den GTL+ Mist nutzt).

Wenn es der Sockel 478 P4 nutzte, dann wird sich mit dem gleichen Prescottkern auf LGA775 auch nichts ändern. Wozu man die ganzen zusätzlichen Pins nutzt ist mir im Moment ohnehin ein Rätsel. Bei AMD war der Schritt von 754 auf 939/940 nachvollziehbar (Dual Channel, 940 für Differenzierung Mainstream/Professional).

Bin ja schon gespannt, wie lange es bei Intel noch dauert, bis man auf die Idee kommt, die CPU über eine Point-Point Verbindung anzubinden (am Ende wird es PCIe x32 *lol*

). Im Übrigen finde ich deren FSB Politik auch unter jeder Kritik. Da hat man nun FSB1066, bringt im April Chipsätze raus, die das breit unterstützen und dann verkrüppelt man bandbreitenhungrige Dual-Core Prescotts mit FSB800.

Was DC-MCH angeht, war das eine vorschnelle Idee meinerseits. Mehrere FSBs sind vielleicht keine Lösung, setzt Intel aber neuerdings bei Serverboards ein.

HenryWince · 28.03.2005

@starcraftfreak

> [LGA775] Wozu man die ganzen zusätzlichen Pins nutzt ist mir im Moment ohnehin ein Rätsel.

Es gibt 122 ungenutzte Lands, aber die Mehrzahl dient einer stabileren Spannungsversorgung.

Intel
For clean on-chip power distribution, the Pentium 4 procesesor in the 775-land package has 226 VCC (power), 24 VTT and 273 VSS (ground) lands.

> Da hat man nun FSB1066, bringt im April Chipsätze raus, die das breit unterstützen und dann verkrüppelt man bandbreitenhungrige Dual-Core Prescotts mit FSB800.

Tja, Intels Problem ist, dass ein Dual-Core so realisiert ist, dass es praktisch zwei Busteilnehmer sind. D.h. am FSB gibts insgesamt 3 Bus-Loads. Mit der Anzahl der Bus-Loads sinkt aber die maximal erreichbare Übertragunsrate...

rkinet · 28.03.2005

Original geschrieben von HenryWince
> Da hat man nun FSB1066, bringt im April Chipsätze raus, die das breit unterstützen und dann verkrüppelt man bandbreitenhungrige Dual-Core Prescotts mit FSB800.

Tja, Intels Problem ist, dass ein Dual-Core so realisiert ist, dass es praktisch zwei Busteilnehmer sind. D.h. am FSB gibts insgesamt 3 Bus-Loads. Mit der Anzahl der Bus-Loads sinkt aber die maximal erreichbare Übertragunsrate...

genau, und das Smithfield und später Presler-Design ist ja eh nur das Xeon DP Prinzip nur in einem Gehäuse untergebracht.

Richtig 'dual' wirds bei Intel mit dem 'Merom' und Verwandte(http://www.tecchannel.de/hardware/1159/1.html), der einen gemeinsamen 4MB-L2 und auch neue Sockets /Chipsätze bringen wird.

Intel beschleunigt ja gerade den Umstieg auf 65nm und könnte jetzt vielleicht schon H2'06 als Ziel vorsehen. Smithfield /Presler sind so Lösungen des Überganges, die aber sicherlich auch in Stückzahlen gefertigt werden.

Opteron · 28.03.2005

Original geschrieben von Dresdenboy
Interessant ist, daß sich Sandra mit den synthetischen Tests (optimierte Schleifen, die offensichtlich wie z.B. bei ALU und Whetstone-Tests komplett im Cache ablaufen) das Bild von der Realität entfernt.

Tja, der P4 Cache ist nunmal besser als der K8 Cache, wenn der Code also daran angepasst wird, ist der P4 schneller als der K8. Der Prime95 Entwickler hat das auch festgestellt. Für den L2 Cache kann man den Geschwindigkeitsnachteil immerhin per Prefetchinstructions verbessern (gefunden auf PlanetAMD64):

I just received this email from George Woltman, the programmer of prime95:

Coincidentally, I've spent the last 5 days working on 64-bit optimizations...

I have ported prime95 to the Windows 64-bit OS. It isn't QA'ed or anything
but can pass the torture test.

The trial factoring code was completely rewritten. On an Opteron it is
significantly faster than the 32-bit code - nearly twice as fast.

An Intel guy has played around with using the extra registers and is
reporting an 8% speedup. All attempts I've made to use the extra registers on the Opteron have been ineffective.

The AMD64 (both 32 and 64 bit) code was suffering from 2 bottlenecks.
1) The basic building blocks run faster on a P4 than on the AMD64. For
example the four_complex_fft macro running from the L1 data cache takes 95 clocks on a P4 and takes 129 clocks on the Opteron.
2) The P4 was accessing data from the L2 cache faster than the
Opteron. The same macro running from the L2 cache was taking 100 clocks on a P4 but 180 clocks on the Opteron.

The bad news is nothing I've tried has made the Opteron as fast as the
P4. Using extra registers, reordering code, changing the code to use the ADD/MUL/STORE pipelines differently made any significant difference (exception: moving stores forward as far as possible gets the time down to 117 clocks).

The good news is that the L2 cache penalty can be eliminated by using the
prefetchw instruction (but not prefetch or prefetcht0). The majority of
the time prime95 knows the addresses for the next building block and can use prefetchw accordingly.

I'm near completing a version of prime95 with the prefetchw optimization
for about a 15% gain. I'll also investigate whether this idea can help 32-bit Athlons.

ciao

Alex

Gegenüberstellung AMD64 - EMT64

Admiral Special

Redaktion☆☆☆☆☆☆

Admiral Special

Vice Admiral Special

Redaktion☆☆☆☆☆☆

Admiral Special

Vice Admiral Special

Gesperrt

Vice Admiral Special

Grand Admiral Special

Vice Admiral Special

Admiral Special

Vice Admiral Special

Grand Admiral Special

Gesperrt

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Vice Admiral Special

Admiral Special

Grand Admiral Special

Grand Admiral Special

Vice Admiral Special

Vice Admiral Special

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Ähnliche Themen

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆