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

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
classic437 schrieb:
Was bringen mir die vielen Kerne/Threads, die die CPU verarbeiten kann, wenn sie im Endeffekt garnicht genutzt werden...
Zum Vergrößern anklicken....
Wenn sie dir nichts bringen, darfst du auch gerne zu einem 2- oder 3-Modul Modell greifen. ;)

classic437 schrieb:
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.
Zum Vergrößern anklicken....
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.
 
Stimmt, mein E6300 fragt mich auch jeden Tag, wann er denn endlich in Rente gehen darf :d

mfg
 
Ü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.
 
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.
 
Zuletzt bearbeitet:
giga lightstorm schrieb:
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.
Zum Vergrößern anklicken....

:rolleyes:
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.
 
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...
 
giga lightstorm schrieb:
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?
Zum Vergrößern anklicken....
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.

giga lightstorm schrieb:
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.
Zum Vergrößern anklicken....
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).
 
Ok Danke.

Ich rechne nun mit einer großen Steigerung der IPC ( > 25%) gegenüber K10.5.
 
Zuletzt bearbeitet:
giga lightstorm schrieb:
Ok Danke.

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

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.
 
Zuletzt bearbeitet:
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.
 
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).
Zum Vergrößern anklicken....

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.
 
Bilderquotes sind nicht erwünscht. Bitte entfernen.
 
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.
Zum Vergrößern anklicken....

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
Zum Vergrößern anklicken....

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?
 
giga lightstorm schrieb:
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?
Zum Vergrößern anklicken....
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.

giga lightstorm schrieb:
Und gibt es von AMD eigentlich auch optimierte Compiler?
Zum Vergrößern anklicken....
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.
 
giga lightstorm schrieb:
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?
Zum Vergrößern anklicken....
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.
 
Zuletzt bearbeitet:
giga lightstorm schrieb:
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?
Zum Vergrößern anklicken....
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.
 
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.
Zum Vergrößern anklicken....

Warum hat man diese Abfrage nicht mittels Patch im Prozessortreiber abfangen können?
 
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.
 
giga lightstorm schrieb:
Warum hat man diese Abfrage nicht mittels Patch im Prozessortreiber abfangen können?
Zum Vergrößern anklicken....
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.
 
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.
 
150- 250 schätze ich mal.
Zum Vergrößern anklicken....

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...
 
Wieso ?

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

Macht 700-800 Euro
 
Anmelden, um zu antworten.

Ähnliche Themen

L
laptop aufrüsten, möglich&sinnvoll?!
Antworten
7
Aufrufe
564
passat3233
P
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh