[Sammelthread] AMD Bulldozer "Zambezi" 32nm "New CPU Architecture" Sockel AM3+ [Part 3]
- Ersteller Duplex
- Erstellt am
Chezzard
Semiprofi
Nein, er muss einfach nur schreiben :" Neue Werte, seht es euch an"
Das lockt die meisten leute an, ob schlecht oder gut stellt sich erst nach dem Klick raus
AIDA(Everest) kannst nicht unterschiedliche Plattformen vergleichen(auch nicht Intel zu Intel oder AMD zu AMD). Der Bench ist im Prinzip unbrauchbar.
Da hast noch mehr Aussagekraft mit ramdrive + hdd(ssd)-benchmark und das ist nicht gearde so prahl noch.
Da hast noch mehr Aussagekraft mit ramdrive + hdd(ssd)-benchmark und das ist nicht gearde so prahl noch.
mr.dude
Urgestein
- Mitglied seit
- 12.04.2006
- Beiträge
- 6.419
Das würde in der Tat schlechte Werte zB bei Super Pi oder FritzChess erklären. Denn solche Anwendungen dürften entscheidend von Prefetching und Branch Prediction abhängen. Auf andere Anwendungen muss das allerdings nicht unbedingt viel Auswirkungen haben.
Also wenn du nur vom L1D sprichst, dann hat dein X2 ganz gewiss keine 128 KiB, sondern nur 64 KiB. Und wenn du den gesamten L1 meinst, dann hat Bulldozer nicht 16 KiB, sondern 96 KiB (64 KiB L1I + 2x 16 KiB L1D). Mal davon abgesehen ist der L2 deines X2 auch nicht 2 MiB gross. 20 Takte scheint korrekt zu sein. Denn genau das steht auch im Optimization Guide ("18-20 cycle load to use latency"). Die 18 Takte beziehen sich vermutlich auf ein Design mit lediglich 1 MiB L2, welches als Option ebenfalls im Optimization Guide erwähnt wird.
Techtrancer
Urgestein
glaub es wird noch tote im luxx geben wenn AMD sich noch bis dahin zeit lässt^^
santa clause
Enthusiast
Also verhindert AMD momentan ein neues TLB-Bug Desaster?
Wieso?
Es ist doch die Rede von Q4 2011. Und Q4 geht doch von Okt.-Dez.
Da wäre 12. Okt. eigentlich noch ziemlich weit vorn.
Techtrancer
Urgestein
mancheiner is ja schon seit monaten kurz vor dem sterben weil AMD mit kaum infos raus rückt 
Chezzard
Semiprofi
Lass mich raten: Du hast einen Guten Freund, naja kein guter freund, eher ein bekannter.
Und dieser Bekannter.....
Und dieser Bekannter.....
get low
Enthusiast
Die ganzen Hardwareseiten reißen sich um jede News zu neuen CPUs, egal ob gut oder schlecht.
Und dann kommen noch die User dazu die auf die Quelle klicken, da kommt einiges zusammen. Selbst einige User die wissen das die Quelle nicht seriös ist, klicken wieder rauf um zu sehen was jetzt wieder für ein Quatsch da steht.
Zuletzt bearbeitet:
El Kaputtano
Banned
- Mitglied seit
- 19.07.2008
- Beiträge
- 702
Es war nicht OBR. Er hat ein ES an einen "Kunden" verkauft und der bencht jetzt die pro Takt Leistung. Denkt einer hier der faked das aus Spass? Es werden einige hier aus den Wolken fallen.
boxleitnerb
Enthusiast
- Mitglied seit
- 11.01.2007
- Beiträge
- 6.546
Das ändert nichts dran, dass das ein ES war. Ich bin zwar auch eher pessimistisch, was BD angeht, aber so fair muss man sein.
Klasse, jetzt will er seine Glaubwürdigkeit wiederherstellen indem er
seine Benches von einem Bekannten veröffentlichen lässt?
Zuletzt bearbeitet:
wo liest du da SEPTember?
fail!
auch wenns schon editiert ist, damals hieß es nach dem versteckten Hinweis in einem Video oft 19. September. Es war dort, wie auch hier, nur "ember 19th" zu lesen.
btw, 30 sec Windows Paint später ist es evtl sogar der 19. Dezember geworden.
Meine Version extra gekennzeichnet ^^
btw, 30 sec Windows Paint später ist es evtl sogar der 19. Dezember geworden.
Meine Version extra gekennzeichnet ^^
Zuletzt bearbeitet:
danke, ich weiss wie man liest!
Hotzi1
Enthusiast
Könnte auch Dezember sein???
Phantomias88
Banned
Und vor allem, in welchem Jahr?Könnte auch Dezember sein???
19 November wäre auf jedenfall ein denkbar schlechter Zeitpunkt, da kommen zuviele Erinnerungen an Barcelona hoch!
Könnt ihr den Kinderkram einfach mal lassen?
Zum Schreiben in den L1-Cache braucht man keinen Prefetcher - glaub' ich.
Sofern AIDA halbwegs richtig misst, liegt man beim Schreiben in den L1-Cache um den Faktor 3 unter dem Vorgänger, beim Lesen aus dem L2 um den Faktor 2. Das wird wohl nicht so vorgesehen sein, also wohl ein schwerwiegender Bug der in irgend einem Stepping dann verschwindet.
Habe wo anders auch gelesen, dass Bulldozer wohl wirklich die 20 Takte Zugriffszeit auf den L2-Cache als Design-Ziel haben soll. Frag' mich warum AMD diesen Weg geht, Modulkonzept hin oder her, Intel geht ja genau den umgekehrten Weg. :-?
Zum Schreiben in den L1-Cache braucht man keinen Prefetcher - glaub' ich.
Sofern AIDA halbwegs richtig misst, liegt man beim Schreiben in den L1-Cache um den Faktor 3 unter dem Vorgänger, beim Lesen aus dem L2 um den Faktor 2. Das wird wohl nicht so vorgesehen sein, also wohl ein schwerwiegender Bug der in irgend einem Stepping dann verschwindet.
Habe wo anders auch gelesen, dass Bulldozer wohl wirklich die 20 Takte Zugriffszeit auf den L2-Cache als Design-Ziel haben soll. Frag' mich warum AMD diesen Weg geht, Modulkonzept hin oder her, Intel geht ja genau den umgekehrten Weg. :-?
Cokebei3Grad
Enthusiast
@heilquelle
Gipsel ausm 3DC hat dazu was feines geschrieben:
"Der Prefetch wirkt sich natürlich erst so richtig bei Zugriff auf den L2 aus (es gibt zwei Hardware-Prefetcher: der erste analysiert L1D-Zugriffe und fetched in den L1 um L1-Misses zu vermeiden [sehr wichtig bei dem relativ kleinen L1], der andere analysiert Speicherzugriffe und fetched in einen speziellen Prefetch-Buffer im Speichercontroller, also nicht direkt in einen Cache, letzterer Prefetch scheint ja schon zu funzen). Ich schrieb ja nicht umsonst explizit "L2->L1 Prefetch".
Der lädt also bei der Bandbreitenmessung des L2 (mit sequentiellen, also einfach zu vorhersagenden Zugriffen) beim ersten Zugriff eine Cacheline vom L2 in den L1 (Latenz 18-20 Takte laut Optimization Guide, paßt auch in etwa mit dem Wert in AIDA). Aber anstatt dann schon den Transfer der nächsten Cacheline vorsorglich anzuschieben, passiert erst mal gar nichts. Erst beim Zugriff auf die nächste Cacheline wird der Transfer initiiert, was dann wieder die volle L2-Latenz kostet. Ein bißchen hilft noch die Länge der LSU-Pipe, aber die schafft es nur, die L1-Zugriffe mit der L2-Latenz zu überlappen (so daß das keine zusätzliche Verzögerung bedeutet), nicht die volle L2-Latenz zu maskieren (edit: wobei die 40 Einträge in der load-queue der LSU bei maximal 2 Zugriffen/Takt auch schon bis zu 20 Takte Latenz auffangen könnten, die sind also offenbar ebenfalls teilweise deaktiviert).
Rechnen wir mal nach: Alle 64Byte eine Verzögerung von 18 Takten macht knapp 3,6 Byte pro Takt * 4,2 GHz = 15GB/s. Ziemlich genau das, was AIDA mißt, was allerdings eigentlich zu wenig ist. Oder Du gehst davon aus, daß der L2 nur mit 2x32Bit angebunden ist "
BD wird Jahre entwickelt, mehrmals verschoben um dann langsamer als der Vorgänger zu sein, wer glaubt denn sowas
Gipsel ausm 3DC hat dazu was feines geschrieben:
"Der Prefetch wirkt sich natürlich erst so richtig bei Zugriff auf den L2 aus (es gibt zwei Hardware-Prefetcher: der erste analysiert L1D-Zugriffe und fetched in den L1 um L1-Misses zu vermeiden [sehr wichtig bei dem relativ kleinen L1], der andere analysiert Speicherzugriffe und fetched in einen speziellen Prefetch-Buffer im Speichercontroller, also nicht direkt in einen Cache, letzterer Prefetch scheint ja schon zu funzen). Ich schrieb ja nicht umsonst explizit "L2->L1 Prefetch".
Der lädt also bei der Bandbreitenmessung des L2 (mit sequentiellen, also einfach zu vorhersagenden Zugriffen) beim ersten Zugriff eine Cacheline vom L2 in den L1 (Latenz 18-20 Takte laut Optimization Guide, paßt auch in etwa mit dem Wert in AIDA). Aber anstatt dann schon den Transfer der nächsten Cacheline vorsorglich anzuschieben, passiert erst mal gar nichts. Erst beim Zugriff auf die nächste Cacheline wird der Transfer initiiert, was dann wieder die volle L2-Latenz kostet. Ein bißchen hilft noch die Länge der LSU-Pipe, aber die schafft es nur, die L1-Zugriffe mit der L2-Latenz zu überlappen (so daß das keine zusätzliche Verzögerung bedeutet), nicht die volle L2-Latenz zu maskieren (edit: wobei die 40 Einträge in der load-queue der LSU bei maximal 2 Zugriffen/Takt auch schon bis zu 20 Takte Latenz auffangen könnten, die sind also offenbar ebenfalls teilweise deaktiviert).
Rechnen wir mal nach: Alle 64Byte eine Verzögerung von 18 Takten macht knapp 3,6 Byte pro Takt * 4,2 GHz = 15GB/s. Ziemlich genau das, was AIDA mißt, was allerdings eigentlich zu wenig ist. Oder Du gehst davon aus, daß der L2 nur mit 2x32Bit angebunden ist "
BD wird Jahre entwickelt, mehrmals verschoben um dann langsamer als der Vorgänger zu sein, wer glaubt denn sowas
Zuletzt bearbeitet:
In den nächsten 4 Wochen zu 95%.
Ausgeliefert wird bereits, und bisher hat AMD immer 1 Monat nach "production" präsentiert.
20 Takte sind nicht viel, die kann man durch Prefetcher und große OoO Fenster in den Schedulern und LD/STr Units schön "einebnen".
Das war bisher ja AMDs Schwachstelle, der K10 hatte lausige 8 Plätze im Int core pro ALU/AGU, das ist nicht besonders tief.
Jetzt gibts 40 für 2ALU Pärchen, ne ganz andere Größenordnung.
Wie unwichtig ein schneller, kleiner L2 ist, sieht man ja daran, dass Intel erst auf nen fullspeed L3 gewechselt ist, der ein nettes Plus verursacht. War davor bei Nehalem OC ja auch schon der Fall.
Das geht wohl nur, wenn die Daten auch 'vorhersehbar' gebraucht werden. Multipliziert man nur Matrizen ist das fein, hat man etwas komplizierteren Code bin ich mir da nicht mehr so sicher, ob einem die Latenz nicht auf die Füße fällt.
Als Gegenargument in multithreaded-Applikationen könnte man den Turbo heran ziehen. Warten viele Ausführungseinheiten regelmäßig auf viele Daten sinkt der Verbrauch und es besteht Spielraum für mehr Takt.
Nehalem hat von Haus aus eigentlich einen recht flotten L2-Cache - du meinst Übertakten des L3-Caches bringt dort viel?
Paperlaunch Präsentation vielleicht. Llanos Auslieferung begann Anfang April, Verkaufsstart der Desktop Versionen fiel am 1. Juli und erste Verkaufsnotebooks waren im Juli erhältlich. Es braucht Minimum 2 Monate (bei Notebooks dauert es natürlich tendenziell länger). Also wenn jetzt im August irgendwann die Produktion anlief, stehen frühestens 2 Monate später die CPUs im Laden.
Da gibts nen neuen Prefetcher, der auch kompliziertere Muster erkennt. Intel hat den schon seit Core2 oder Nehalem.
Jupp, die ganzen Übertakter mit DDR3-1600++. Die meinte da oft, dass das RAM einiges brachte, aber übersahen dabei, dass der L3 Cache synchron, mit doppeltem Takt zum Speichertakt läuft, mit DDR3-1600 sind das 3200 Mhz, mit DDR3-2000 entsprechend 4 GHz ^^
Na da widersprichst Du Dir ja schon selbst, bei Llano gings erstmal nur um Auslieferung an OEMs, die brauchen dann nen weiteren Monat um drumherum ein Notebook zu basteln. Desktopstapellauf war da eh später. Aber BD wird gleich an Endkunden vertickert, die CPU war ja jetzt schon bei genügend Händlern gelistet, um das zu wissen. Bin mir sicher, dass sie allerspätestens eine Woche nach dem offiziellen Start im Laden sind.
Trotzdem braucht es Minimum 2 Monate, das zeigt die Vergangenheit. Alles andere kommt einem Paperlaunch gleich. Es braucht eine gewisse Vorlaufzeit für einen weltweiten hard launch. Von gelistet auf Verfügbarkeit besteht ein Unterschied im übrigen.
mr.dude
Urgestein
- Mitglied seit
- 12.04.2006
- Beiträge
- 6.419
AMD strebt immer einen Hardlaunch an. Ausgeliefert wird seit August. Oktober passt also zu den von JF erwähnten 6-8 Wochen für Verfügbarkeit. Llano war eine andere Geschichte. Wie Opteron schon sagte, die ersten Chargen gingen an die OEMs.
Das man jetzt schon gezielt den L3-Cache übertaktet, ist mir echt neu. *g*
Bei Obrovsky gibts noch ein paar Neuigkeiten (etwas weiter unten), die Ergebnisse scheinen sich zu bestätigen:
OBRovsky Blog
Ich hoffe AMD verkauft ihn nicht mit teil-defekter Cache-Anbindung. :O
Bei Obrovsky gibts noch ein paar Neuigkeiten (etwas weiter unten), die Ergebnisse scheinen sich zu bestätigen:
OBRovsky Blog
Ich hoffe AMD verkauft ihn nicht mit teil-defekter Cache-Anbindung. :O