[Sammelthread] AMD Bulldozer "Zambezi" 32nm "New CPU Architecture" Sockel AM3+ [Part 3]

[classic437]

hört sich sehr gut an, was ihr da schreibt.

 

[mr.dude]

Was bringen mir die vielen Kerne/Threads, die die CPU verarbeiten kann, wenn sie im Endeffekt garnicht genutzt werden...

Wenn sie dir nichts bringen, darfst du auch gerne zu einem 2- oder 3-Modul Modell greifen.

Die meisten Programme, die man so nutzt, nutzten ja nur 2 cores, wenn überhaupt, und Spiele fangen gerade erst an von quadcore zu profitieren und selbst da hält es sich in Grenzen.

Schon mal was von Multitasking gehört? Man hat nicht immer nur eine Anwendungen laufen. Ich merke es bei mir besonders in einem Fall, wo mehr als ein Prozess am werkeln ist. Mein X2 läuft da schon am Limit und schreit nach mehr Kernen.

 

[classic437]

Stimmt, mein E6300 fragt mich auch jeden Tag, wann er denn endlich in Rente gehen darf

mfg

 

[mr.dude]

Übrigens, der Software Optimization Guide für Bulldozer ist jetzt verfügbar.

Ich habe es nur mal kurz überflogen. Dennoch ein paar interessante Details am Rande. Manches ist schon bekannt, anderes noch nicht. Modul wird hier übrigens als Compute Unit bezeichnet.

Bulldozer ist ein 4-fach superskalares Design, kann also bis zu 4 x86-64 Instruktionen pro Takt verarbeiten. K10 konnte bisher nur 3 x86-64 Instruktionen pro Takt verarbeiten.

Während K10 ein 32-byte fetch window hatte, besitzt Bulldozer deren zwei. Weiterhin wird hier von einem "fast or slow mode" gesprochen. Was das genau ist, fragt man sich ja schon länger. Es scheint wohl eine Technik auf Logikebene sein und nicht einfach nur Takt.

Die Beziehung von L1 und L2 ist inklusive. Dh, Inhalte des L1 werden automatisch im L2 gespeichert. Wohl auch deshalb hat man einen relativ grossen L2 gewählt. Man spricht hier auch von einem sogenannten Write-Through Cache. Also immer wenn eine Schreibaktion durchgeführt wird, geschieht dies in L1D und L2. L1 und L2 in K10 waren exklusive.

L1I: 64-Kbyte 2-way set-associative
L1D (2x): 16-Kbyte 4-way predicted, 4 Takte Latenz
L2: full speed, Grösse und Assoziativität variabel, 18-20 Takte Latenz
L3 (shared on chip): bis zu 8 MiB mit 2 MiB sub-caches, non-inclusive victim cache

Es gibt zwei Load/Store Einheiten pro Compute Unit, zwei 128-bit Loads und ein 128-bit Store pro Load/Store Einheit.

Unaligned SSE MOVs arbeiten nun so effizient wie die aligned Versionen. Generell arbeitet load-execute SIMD und x87 Code nun effizienter als zuvor. Separates Laden in Register, um diese dann mit Rechenbefehlen weiterzuverarbeiten, wird nicht mehr empfohlen.

20 Takte Penalty für falsche Vorhersagen für bedingte und indirekte Sprünge, 15 Takte Penalty für unbedingte Sprünge.

Es gibt 4 Ausführungseinheiten pro Integer Cluster. Zwei für arithmetische, logische und Shift Operationen (EX) und zwei für Adressgenerierung und einfache ALU Operationen (AGLU). Wie also schon mal spekuliert, die AGLUs sind nicht nur einfache Adressgeneratoren wie in K10, sondern können auch einfache arithmetische und logische Operationen durchführen. Wir haben also einen maximalen theoretischen Durchsatz von 4 Integer Operationen pro Takt im Vergleich zu 3 bei K10.

 

[giga lightstorm]

Dazu hab ich eine Verständnisfrage: Wie kann etwas simultan in L1 und L2 Cache geschrieben werden, wenn der L1 Cache nur 4, der L2 Cache aber 18 Takte Latenz hat? Muss dann nicht der L1 auf den L2 warten?


Und wie wird eigentlich verhindert, dass der Rechner abstürzt, wenn das Powergating einen Kern abschaltet? Normalerweise muss man Windows doch vor Systemstart sagen, auf wie vielen Prozessoren es laufen soll.

 

[HardlineAMD]

Dazu hab ich eine Verständnisfrage: Wie kann etwas simultan in L1 und L2 Cache geschrieben werden, wenn der L1 Cache nur 4, der L2 Cache aber 18 Takte Latenz hat? Muss dann nicht der L1 auf den L2 warten?


Und wie wird eigentlich verhindert, dass der Rechner abstürzt, wenn das Powergating einen Kern abschaltet? Normalerweise muss man Windows doch vor Systemstart sagen, auf wie vielen Prozessoren es laufen soll.

Wenn du die Funktionsweise verstehen würdest, dann hättest du nicht solch immens unsinnigen Fragen gestellt.
Du liegst meines Wissens nach mit allem falsch.

 

[Nimrais]

Dann erklährs uns Hardline

Er hat nämlich nicht mal eine Aussage gemacht sondern eine (zwei) Fragen gestellt die mich auch interessieren würden...

 

[mr.dude]

Dazu hab ich eine Verständnisfrage: Wie kann etwas simultan in L1 und L2 Cache geschrieben werden, wenn der L1 Cache nur 4, der L2 Cache aber 18 Takte Latenz hat? Muss dann nicht der L1 auf den L2 warten?

Latenzen beziehen sich üblicherweise auf Lesezugriffe, nicht auf Schreibzugriffe. Genau genommen heisst es im Dokument "load-to-use latency". Natürlich brauchen Schreibzugriffe auch eine gewisse Zeit. Ist hier aber nebensächlich. Die Vermeidung von Inkonsistenzen ist wieder ein anderes Thema, -> Kohärenz.

Und wie wird eigentlich verhindert, dass der Rechner abstürzt, wenn das Powergating einen Kern abschaltet? Normalerweise muss man Windows doch vor Systemstart sagen, auf wie vielen Prozessoren es laufen soll.

Power-Gating ist keine Technik, wo einfach ein Schalter umgelegt wird und das war es dann. Da passiert auf Hardwareebene einiges. Im Gegensatz zu Clock-Gating, wo man praktisch taktweise steuern kann, kann das Aktivieren von Power-Gating schon mal mehrere hundert Takte dauern. Dem Betriebssystem wiederum ist es völlig egal, was die Hardware macht. Das Betriebssystem sagt doch nur "Prozessor A führe Instruktion X aus" oder "Prozessor B führe Instruktion Y" aus. Sollte ein Prozessor mal keine Instruktionen zur Ausführung erhalten, was vom Betriebssystem mit einer WAIT Instruktion oder ähnlichem signalisiert wird, ist das die Möglichkeit für den Prozessor, in einem Sparmodus zu wechseln. Entweder wird dann Takt und Spannung gesenkt (Clock-Gating) oder der Prozessor wird komplett stromlos geschaltet (Power-Gating).

 

[giga lightstorm]

Ok Danke.

Ich rechne nun mit einer großen Steigerung der IPC ( > 25%) gegenüber K10.5.

 

[Duplex]

Ok Danke.

Ich rechne nun mit einer großen Steigerung der IPC ( > 25%) gegenüber K10.5.

BD Modul vs. K10 Dual Core oder BD Inter-Core vs. K10 Core?

Server Specrate 50% Speedup vs. MC bei 33% mehr Kerne,
macht also pro Core 12,5% mehr IPC als K10, hat BD mehr Basistat, dazu mehr Nortbridge Takt, dann ist die IPC weitaus geringer.

 

[giga lightstorm]

Gibt es echt schon aussagekräftige Benches? Wen ja, würde ich um einen Link bitten (auch wenn es evtl schon mal gepostet war).

Die 25% habe ich für einen Singlethread aber int + FPU abgeschätzt. Also ohne die Leistung der CMT.

 

[HardlineAMD]

Dein letzter Absatz ist vor allem wichtig.
"Gamer" nennen das cheaten.

 

[che new]

Gab zwar eine Einigung mit der FTC:

Leibowitz ging auch auf die Vorwürfe wegen der Intel-Compiler ein und stellte fest, dass diese fremde Prozessoren klar benachteiligt hätten. Das dürfe in Zukunft nicht mehr geschehen und ist ebenfalls in der Anordnung geregelt. Diese legt auch fest, dass Intel weiterhin Lizenzen für die Entwicklung und den Verkauf von x86-Prozessoren durch AMD und VIA Technologies vergeben muss – auch wenn diese die x86-Prozessoren bei Auftragsfertigern wie Globalfoundries oder TSMC produzieren lassen.

Intel muss ferner insgesamt bis zu 10 Millionen US-Dollar an Firmen auszahlen, die ihre mit Intel-Compilern hergestellte Software neu übersetzen müssen, damit sie auch auf Nicht-Intel-Prozessoren so schnell wie möglich läuft. Strafzahlungen muss Intel allerdings nicht leisten. Intel akzeptiert die FTC-Vorgaben, erkennt aber kein Fehlverhalten an – eine solche Sprachregelung gab es auch bei der Einigung mit AMD (AMD Settlement).

heise online - US-Wettbewerbshüter einigen sich mit Intel

Fragt sich nur ob sich wirklich etwas in der Richtung tut und ob Intel nicht andere kreative Mittel findet weiterhin unlauter Einfluß zu nehmen. Ich glaube kaum, dass bereits Bulldozer von dieser Einigung profitiert.

 

[Techtrancer]

Zambezi Prototyp?

¡¾Ã°ËÀ͵ÅÄÍÆÍÁ»úÒÔ¼°´«ËµÖеÄFM1£¡¡¿-CPU´óÌÖÂÛÂÛ̳-ZOLÖйشåÔÚÏß

ist denk ich ein fake
ES sehen bei AMD normal anderst aus

 

[FM4E]

Bilderquotes sind nicht erwünscht. Bitte entfernen.

 

[giga lightstorm]

Auch gibt es bei x86 Compiler Tricks, wenn z.b. ein AMD Prozessor im System drin ist und der Intel Compiler das weiß, dann kann eine SSE Befehlserweiterung bei AMD x86 CPUs deaktiviert werden, dann ist Intel bei SSE Code schneller, es gibt bezüglich x86 Compiler viele Threads im Netz, einfach google benutzen, die Ingenieure bei AMD wissen das bestimmt auch, hier gibt es Simulationen für Integer oder SSE Code.

Aber die meisten Programme werden wohl nicht auf dem selben System compiliert wo sie später auch ausgeführt werden. Das hieß ja, dass ein auf einem AMD compiliertes Programm dann später auch auf einem Intel langsamer ist, oder? Oder ist das nur eine Optimierung auf Intel? Und gibt es von AMD eigentlich auch optimierte Compiler?

Es ist möglich das Bulldozer in Singlethread gegenüber Sandy Bridge trotz gleicher Anzahl logischer Prozessoren 10% langsamer ist

Was heißt es ist möglich? Weißt du dass es so ist, gibt es Argumente die darauf schließen lassen oder ist das reine Spekulation aus K10.5 Ergebnissen?

 

[mr.dude]

Aber die meisten Programme werden wohl nicht auf dem selben System compiliert wo sie später auch ausgeführt werden. Das hieß ja, dass ein auf einem AMD compiliertes Programm dann später auch auf einem Intel langsamer ist, oder?

Nein, heisst es nicht. Auf welchem System kompiliert wird, ist doch völlig egal. Es zählt nur der dabei entstehende Code, nicht der Compiler. Und natürlich kann auch auf einem AMD System Code mit spezifischen Intel Pfaden erstellt werden. Wenn du willst kannst du auch auf Nicht-x86 Systemen Code für AMD oder Intel erstellen.

Und gibt es von AMD eigentlich auch optimierte Compiler?

Ja, es gibt auch einen Compiler von AMD. Der nennt sich Open64. Das Problem ist nur, dass es bisher keinen richtigen Windows Port davon gibt. Mir ist zumindest keiner bekannt.

 

[Opteron]

Aber die meisten Programme werden wohl nicht auf dem selben System compiliert wo sie später auch ausgeführt werden. Das hieß ja, dass ein auf einem AMD compiliertes Programm dann später auch auf einem Intel langsamer ist, oder? Oder ist das nur eine Optimierung auf Intel? Und gibt es von AMD eigentlich auch optimierte Compiler?

Ein Kompiler macht, was man Ihm sagt, es gibt z.B. auch sogenannte Cross Compiler, damit kannst Du auf z.B. einer x86 Maschine Quellcode in ein ARM Binary compilieren lassen. Klarerweise kann die x86 Compile-Maschine, damit aber 0 anfangen. Ist aber dem Compiler egal, der tut wie befohlen.

Was beim Intel Compiler passierte war, dass Intel dem Compiler vorschrieb, eine Intelinside Abfrage in die erzeugten Programme einzubauen. Nur wenn ein Intel im System erkannt wurde, gabs guten SSE/2 Code, ansonsten wurde x87 Ersatzcode ausgeführt, der logischerweise langsamer war.

Absolut unnötig, da Intel für sowas schon seit 486er Zeiten die CPUID Flags eingeführt hatte. Damit kann ein Programm zur Laufzeit die CPU abfragen kann, was sie alles kann, also z.B. SSE2 oder eben nur x87 und danach den besten Codepfad ausführen.

Aber naja ... die Konkurrenz ist hart und es werden nicht umsonst Managerseminare über die Kunst der Kriegsführung abgehalten. Da wird mit allen Mitteln gekämpft.

Im Endeffekt war das mit dem Intel Compiler eh egal, denn die meisten Win-Programme werden mit dem Microsoftcompiler übersetzt. Unterschiede gabs nur im Marketing, da sich die Intelinside Abfrage auch und v.a. bei diversen Spec Benchmarks niederschlugen. Da hat AMD mittlerweile durch den genannten open64 compiler aber auch ein Stein im Brett.

 

[jdl]

Aber die meisten Programme werden wohl nicht auf dem selben System compiliert wo sie später auch ausgeführt werden. Das hieß ja, dass ein auf einem AMD compiliertes Programm dann später auch auf einem Intel langsamer ist, oder? Oder ist das nur eine Optimierung auf Intel? Und gibt es von AMD eigentlich auch optimierte Compiler?

AMD hat definitiv nicht die Manpower wie Intel, das sieht man unter anderem an der Qualität der ACML. Diese enthält wie auch Intels MKL "BLAS, LAPACK und FFT". Auf 61xx Opterons ist die MKL Single Threaded etwas schneller, Multithreaded gibt es einen gewaltigen Unterschied. Die MKL skaliert auf einem Opteron sehr viel besser als die ACML.

Natürlich trickst Intel immer noch herum. Es gibt mittlerweile zwar Compilerswitches die extra Codeoptimierungen für Opterons benutzen. Aber die Intel Compiler erzeugen bei OpenMP Source-Code keinen Code fürs Thread Pinning, so daß hier immer noch mit zum Teil erheblichen Geschwindigkeitseinbußen zu rechnen ist. Man kann das Problem umschiffen, in dem man das Thread Pinning selbst durch eigenen Code aktiviert.

PGI liefert Compiler, die sowohl für Intel wie auch AMD guten Code erzeugen, und die Compiler sind aktuell d.h. sie unterstützen alle aktuellen Revisionen von C, C++ und Fortran. Der Open64 Fork von AMD ist leider nicht so aktuell und unterstützt nur alte Versionen der Sprachen.

PGI und die Intel Compiler sind natürlich auch für Windows erhältlich.

 

[giga lightstorm]

Was beim Intel Compiler passierte war, dass Intel dem Compiler vorschrieb, eine Intelinside Abfrage in die erzeugten Programme einzubauen. Nur wenn ein Intel im System erkannt wurde, gabs guten SSE/2 Code, ansonsten wurde x87 Ersatzcode ausgeführt, der logischerweise langsamer war.

Warum hat man diese Abfrage nicht mittels Patch im Prozessortreiber abfangen können?

 

[daysleeper83]

Die CPUID is soweit ich weiß hardcoded und kann man nicht einfach ändern, geht nur bei VIA CPUs oder mit einer VMWare. Hatte das vor einiger Zeit mal getestet mir "überraschenden" Ergebnissen.

 

[mr.dude]

Warum hat man diese Abfrage nicht mittels Patch im Prozessortreiber abfangen können?

Ein Prozessortreiber ist etwas völlig anderes als zB ein Grafikkartentreiber. Damit kannst du nicht einfach etwas "abfangen". Ein Prozessortreiber kümmert sich maximal um Power-States und dergleichen. An der Ausführung des Codes lässt sich damit aber nichts ändern. Wie daysleeper83 schon schreibt, was CPUID zurückgibt ist fest im Prozessor verdrahtet. Ausserdem wäre es rechtlich problematisch, wenn AMD seine Prozessoren einfach "GenuineIntel" zurückgeben lassen würde. Man bräuchte schon entsprechende Funktionen, um den Hersteller-String zu ändern. Dann könnte das zumindest jeder auf eigene Gefahr nach Wunsch einstellen. Ist aber natürlich keine generelle und damit keine flächendeckende Lösung. Soweit bekannt haben AMD Prozessoren solche Funktionen auch nicht. Das kennt man bisher nur von VIA. Darüber hinaus würde das auch noch lange nicht ausreichen. Der Intel Compiler nutzt noch ganz andere Methoden, um Intel Prozessoren zu identifizieren.

 

[Apollon]

gibt es schon etwas zu den preisen?

 

[N9ne]

Nope... bisher ist noch nichts bekannt. Der wird sich danach richten wie schnell Bulldozer nun wirklich wird, und da dazu auch keine verlässlichen Informationen verfügbar sind gibts auch noch keine Preise.

 

[G3cko]

gibt es schon etwas zu den preisen?

Klar. Irgendwo zwischen 1€ und 1500€...

 

[mr.dude]

gibt es schon etwas zu den preisen?

Es gibt nur etwas zu Systempreisen, siehe hier. Demnach soll ein Bulldozer System bei $700+ liegen.

 

[classic437]

150- 250 schätze ich mal.

 

[giga lightstorm]

150- 250 schätze ich mal.

Das halte ich für eine sehr optimistische Schätzung. Schließlich soll der Systempreis (kleinstes Modell) bei $700 beginnen. Wenn man einfach mal 150 fürs Board und 300 für Ram, HDD und Gehäuse+Netzteil abzieht, sind es immer noch 250 für die CPU.

Ich schätze 200 - 250 für das kleinste Modell (2 Modul).

Kommt natürlich vor allem auch auf die finale Leistung an, und da ist ein hoher Preis dann auch nicht so schlecht...

 

[Der_ZockerMK]

AMD verrät Fähigkeiten der Flex-FPU

Sehr interessant!!

http://www.pcgameshardware.de/aid,8...ntlicht-Software-Optimization-Guide/CPU/News/

http://www.heise.de/newsticker/meld...r-Software-Entwickler-erschienen-1225457.html

 

[classic437]

Wieso ?

150-250 CPU
100 Mainboard
100 Ram
100 Gehäuse + Netzteil
150 Grafikkarte
100 Festplatte/Laufwerke

Macht 700-800 Euro