AMDs CPU-Architekturen-Strategie (Skybridge, K12, Zen, ...)

[Thunder99]

Seinen Post nicht verstanden? Er spricht nur vom nativen 8-Kerner, bestehend zwei "Modulen", nicht von den 16- und 32-Kernern.
Denke schon, aber mein Gedankengang geht dahin, dass Intel ja auch größere CPU´s aus einem Guss baut und nicht als MC Design. Oder ich verwechsle hier was mit Desktop CPU und Server CPU :freak:

[SavageX]

Denke schon, aber mein Gedankengang geht dahin, dass Intel ja auch größere CPU´s aus einem Guss baut und nicht als MC Design. Oder ich verwechsle hier was mit Desktop CPU und Server CPU :freak:

Nun, Intel hat einen schönen und flexiblen Ringbus, den man sehr groß ziehen kann, um viele Kerne auf einem Die miteinander zu verbinden. Das ist schon sehr nett, sorgt aber dafür dass a) nicht jeder Kern gleich schnell auf die restlichen Teile (fremder Cache, PCIe-Controller, Speichercontroller etc.) zugreifen kann (weil man am "falschen Ende" des Rings sitzen kann) und b) dass dieser Effekt umso schlimmer wird, je größer (mehr Teilnehmer) der Ring wird. Deshalb gibt es ja bei den dicken Xeons zwei Ringe, die an bestimmten Stellen miteinander im Austausch stehen. Wie immer beim Entwerfen technischer Systeme: Ist ein Kompromiss, aber einer der offensichtlich gut funktioniert.

AMD scheint nicht so sehr auf Ringe zu stehen, sondern scheint lieber eng-verbundene Cluster zu mögen, die dann möglichst kreuzverbunden werden, wenn nötig über mehrere Ebenen (4-Kern Cluster mit einem L3 zum direkten Austausch, zwei davon on-die verbunden, mehrere 8-Kern Verbunde dann on-package verbunden, darüber hinaus dann über die Platine). Das ist dann eine sehr deutlich hierarchische Struktur, die über Ebenen hinweg unterschiedliche Charakteristika aufweist, aber innerhalb einer Ebene ziemlich konsistent ist.

In beiden Fällen ist der Scheduler gefragt, auf diese Besonderheiten Rücksicht zu nehmen und ich rechne damit, dass das gut klappen wird, lasse mich aber in der Praxis eines Besseren belehren ;)

[Skysnake]

Das wird natürlich klappen, genau wie bei Intel auch....

ABER! Man verliert schon etwas daran. Sieht man ja an den großen Intel CPUs. Die haben zwar zwei Ringbusse, die miteinander verbunden sind, aber unterm Strich ist man eben doch schneller, wenn man jeden Ringbus ein Dual-Channel DDR Interface zuordnet und daraus eben einen Cluster on DIE macht....

Sind zwar nur 5-10% wenn ich es richtig im Kopf habe, aber das läppert sich halt und wird mit jeder größeren CPU schlimmer. KNL hat ja daher bis zu 4 Cluster on DIE ;)

[SavageX]

Ganz richtig. Ich bin sicher, dass der neue 32-Kern Opteron auch ziemlich darunter büßen müsste, wenn man nicht jedem Die seinen Speicher gibt (edit: und zwar mehr, als wenn ich bei Intel einen Ring ohne Speicher lasse). Wenn der Scheduler zusätzlich auch noch dafür sorgt, dass Threads nicht blöd von einem Die zum nächsten hopsen, dann dürfte das doch ganz gut abschneiden.

[mksn7]

Beim KNC hat Intel das ja auf die Spitze getrieben, mit 60 Kernen an einem Ringbus. Teile davon haben sie dann doch noch doppelt ausgelegt, weil das sonst überhaupt nicht skaliert hätte.

Dass das nicht gut ist hat man auch gemerkt:

Von 320GB/s theoretischem Speicherdurchsatz sind noch 53% oder 170GB/s in der Praxis übrig geblieben. CPUs erreichen mehr als 90%, und auch nvidias GPUs schaffen mindest 80-90% (wenn auch bei Kepler manchmal nur wenn die Sonne aus dem richtigen Winkel scheint, weiß nicht wie das bei Maxwell und Pascal weiterging)

Daten aus den L2 Caches anderer Kerne zu lesen ist kaum schneller als aus dem Hauptspeicher, außerdem mit sehr erratischen Performance Messwerten.

Normale non-temporal stores blockieren für ~290 cycles, erst ohne starke Speicherordnung (mit dem "vmovnrngoapd" Befehl, "MOVe No Read Non Globally Ordered Aligned Packed Double") gehen stores einigermaßen fix, vermutlich weil bei ordered stores erst die Kohärenzinformationen beim entsprechenden L2 Tagdirectory (das an irgendeiner Ringbusstation auf dem Chip sitzen kann) eingetragen werden müssen, bevor ein neuer store passieren kann. Bei non-globally ordered kann das überlappen, weil es dann egal ist wenn ein store out-of-order mit einem anderen comitted wird.

Kein Wunder also dass Intel keinen Ringbus mehr in der Größe baut, sondern mehrere kleine Ringcluster für die Xeons und ein 2D-Mesh für KNL. Ob wir wohl für die Xeons in Zukunft einen ähnlichen Aufbau sehen?

[Unicous]

Nachschlag von Ian Cutress.

http://www.anandtech.com/show/10591/amd-zen-microarchiture-part-2-extracting-instructionlevel-parallelism

[mboeller]

Anandtech mal wieder (sehr ausführlich):

http://www.anandtech.com/show/10591/amd-zen-microarchiture-part-2-extracting-instructionlevel-parallelism

die haben sogar einen Appendix mit allen Slides der Hotchip-Präsentation!

shit... 2min zu spät :)

[deekey777]

Anandtech mal wieder (sehr ausführlich):

http://www.anandtech.com/show/10591/amd-zen-microarchiture-part-2-extracting-instructionlevel-parallelism

die haben sogar einen Appendix mit allen Slides der Hotchip-Präsentation!

shit... 2min zu spät :)

Jetzt mal ehrlich:
Ich habe den Artikel schon kurz nach 08:00 Uhr gelesen.

[Unicous]

Jetzt mal ehrlich:
Ich habe den Artikel schon kurz nach 08:00 Uhr gelesen.

Wow, supertoll. Du bist ein Hecht. So etwas wie dich gab es nie.:eek:


edit:

Jemand hat das Press Briefing zu Zen hochgeladen:
sT1fEohOOQ0

Ich schätze aber, da wird man nicht viel mehr hören, als man schon lesen konnte.

[Unicous]

Bits and Chips behauptet, Zen+ würde in 14nmHP, dem Prozess der eigentlich für IBM reserviert ist.


Big news from Malta, Saratoga County: Power9 and ZEN+ will use the same 14nm HP node of GlobalFoundries.

https://twitter.com/BitsAndChipsEng/status/768523085637152768

Außerdem wird behauptet, Zen hätte einen großen Kunden angezogen. Aber gut, das sagt natürlich gar nichts aus.:freak:

I agree with you. For this reason a big customer will use Zen in its servers. The name is still a secret.
https://twitter.com/BitsAndChipsEng/status/768149012688109569

Ersteres ergibt durchaus Sinn, 14LPP scheint mal wieder nicht das Gelbe vom Ei zu sein und HP soll wohl deutlich taktfreudiger sein.

[victore99]

Einen Großen Kunden im Serverbereich? Wer kann das wohl sein...

[Unicous]

Im Grunde genommen kann das natürlich jeder sein, aber ich tippe mal auf China, da sie dort ja unlängst ein Joint-Venture gegründet haben.

[MR2]

Könnte ich mir auch vorstellen, da HP und Co ZEN sowieso verbauen werden.

[y33H@]

Mike, sagte, PCIe-Root und MC alles on Chip ...

[Skysnake]

Alles andere hätte mich jetzt auch SCHWER gewundert.

Ich bin mal auf deine News gespannt :up:

[prinz_valium]

Wann wird 14nm hp denn erwartet?

[Isen]

Steht doch da. 2H2017

[Unicous]

IBM will ab 2H'17 POWER 9 verkaufen, daher vermute ich werden sie spätestens Ende dieses Jahres den tapeout ansetzen um genug Zeit zu haben das Ding für HPC validieren zu können.

[robbitop]

Eine Rückkehr zu SOI? Ich bin da etwas skeptisch.
Was mir zum Blenderbench einfällt. Zen scheint etwas breiter als Broadwell. Mehr Ports und dedizierte Sheduler. SMT könnte bei Zen etwas mehr bringen. Rückschließend darauf, könnte es sein, dass die ST Performance von Zen etwas geringer ist.

[Hübie]

Letzten Endes wird auch der finale Takt sowie Übertaktungspotenzial ausschlaggebend dafür sein, wer sich jetzt was kauft.
Bringt nix, wenn Zen bei 3,5-3,8 GHz dicht macht während Intels bis rauf auf 4,8 wenn nicht sogar 5 GHz gehen. Ich bin da aber einfach mal guter Dinge. :D

[Fliwatut]

Wenn Zen mit 3,5 GHz eine vergleichbare Leistung bietet, reicht das doch völlig, nicht jeder will oder kann übertakten.

[YfOrU]

Mit einer Basisfrequenz von 3,2Ghz sind die 8C/16T Broadwell-E davon heute meilenweit entfernt. Spielraum für OC ist natürlich vorhanden aber oberhalb von 4 Ghz rauscht die Verlustleistung derart brutal durch die Decke das der Gewinn an Performance kaum mehr vertretbar ist. Hinzu kommt das die Kosten für ein sehr gutes LGA 2011-3 Board mit Wasserkühlung (->OC, 4Ghz +) zu den 1000€ für die CPU in Summe ganz schön heftig sind.

[HOT]

Eine Rückkehr zu SOI? Ich bin da etwas skeptisch.
Was mir zum Blenderbench einfällt. Zen scheint etwas breiter als Broadwell. Mehr Ports und dedizierte Sheduler. SMT könnte bei Zen etwas mehr bringen. Rückschließend darauf, könnte es sein, dass die ST Performance von Zen etwas geringer ist.
AMD muss bei GloFo bleiben (bis 2022 AFAIK) und deren Fahrplan sieht nunmal 14LPP -> 14HP -> 7HP vor. Abseits dessen gibts nur noch die Billigprozesse 14LPP+ und 22FDX (sicherlich gibts noch einen 14FDX planar), 10nm FF ohne SOI ist ja schon gecancelt worden. AMD bleibt gar nichts anderes übrig als darauf zu setzen. Die Zukunft von GloFo ist SOI (in jeglicher Hinsicht sogar), also ist das auch AMDs Zukunft, so einfach ist das.

[mboeller]

Eine Rückkehr zu SOI? Ich bin da etwas skeptisch.
Was mir zum Blenderbench einfällt. Zen scheint etwas breiter als Broadwell. Mehr Ports und dedizierte Sheduler. SMT könnte bei Zen etwas mehr bringen. Rückschließend darauf, könnte es sein, dass die ST Performance von Zen etwas geringer ist.

soweit ich weiß: FinFET + SOI, also keine Rückkehr zu SOI sondern eine Kombi aus FinFET und SOI.

wieso sollte SMT beim ZEN mehr bringen als bei Intel? ZEN ist das "Erstlingswerk" von AMD bzgl. SMT. Intel hat damit schon wesentlich mehr Erfahrung. Für Intel wäre es IMHO ja sehr blamabel wenn AMD bereits beim ersten Versuch besser wäre als Intel. Die Diskussionen über SMT beim ZEN (auch in anderen Foren) kann ich deshalb nicht ganz nachvollziehen.

Und ja, im Umkehrschluss müsste das heißen das die Single-Thread-Leistung des ZEN-ES beim Blender-Benchmark höher war als die des Broadwell-E ... ebenfalls nahezu unglaublich. Vor allem wenn man sich die Benchmark-Tabelle auf pcgameshardware angeschaut hat und sieht wie die Bulldozer in dem Benchmark abschneiden.

http://www.pcgameshardware.de/Broadwell-Codename-259477/Specials/Core-i7-6950X-6900K-Benchmark-Test-1196801/

6900K: 143sec
8370K: 465sec

[dildo4u]

Blender scheint dem FX 8370 nicht zu liegen,bei Cinebench,3DMark und x264 Transcoding ist er z.b deutlich schneller als der 3570k.

[mboeller]

Polaris.

falscher Thread?

[Unicous]

@mboeller

Der Vergleich hinkt aber gewaltig, da der 6900K 16 Threads hat und der Piledriver 8.
Hier spielen Singlethread-Leistung und gute Skalierung beim Multithreading speziell bei SMT eine Rolle.

Es geht auch nicht darum, dass Intel mehr Erfahrung hat bei SMT sondern um die Ressourcenverteilung die es AMD in einigen Szenarien ermöglichen könnte bessere Ergebnisse zu erzielen, dass AMDs Implementierung automatisch besser ist muss davon nicht ableiten.

http://cdn.wccftech.com/wp-content/uploads/2016/08/AMD-Zen_SMT-Simaltaneous-Multi-Threading.png

[MR2]

...

Und ja, im Umkehrschluss müsste das heißen das die Single-Thread-Leistung des ZEN-ES beim Blender-Benchmark höher war als die des Broadwell-E ... ebenfalls nahezu unglaublich. ...

Wenn die single thread Leistung niedriger war, SMT aber etwas mehr bringt kann doch sein? Am Ende waren sie ja ziemlich gleich schnell.
SingleThread Leistung höher und SMT niedriger ist doch unwahrscheinlicher.


Opteron schrieb dazu bei P3D:

"..aber bei dem Punkt muss man auch an AMDs Trennung in INT+FP erinnern..Das ist quasi auch eine Auftrennung wenn auch nicht per Thread, aber da bei AMD doppelt soviele Ports wie bei Intel zur Verfügung stehen ist es von vorne herein klar, dass sich 2 Threads bei so einer Architektur nur halb so oft auf die Füße treten als bei Intel - zumindest wenn es sonst keine anderen Flaschenhälse gibt.

Der SMT-Speedup dürfte also definitv besser ausfallen. Wer unbedingt will kann das dann notfalls mit Power8 vergleichen, es geht gaaanz grob in die gleiche Richtung, ich würde es aber nicht machen, da es noch viel zu viel Unterschiede gibt und AMD näher an Intel liegt - mit dem Unterschied bei den Ports.

Die Preisfrage ist wieviel AMD drauflegen kann. Bei Intels 30%-SMT-Speedup hieß es mal, dass das allein nur wenig mehr als das Ausnutzen des Leerlaufs aufgrund der Speicherwartezeiten eines Threads war. Irgendwas zwischen 40-50% wäre also nett, CMT bei Bulldozer hatte schon 60% aufwärts, das wird man wohl nicht erreichen, da bräuchte es vermutlich mind. eine weitere Store-Unit und mehr Cache-Ports."


Es wird schon am Ende so sein. In Spielen und auf den Kern bezogen etwas langsamer, Gesamtpaket aber wird schon passen.
Ein guter Preis für die Plattform und die Dinger gehen weg wie warme Semmeln.
Mein PhenomII X6 sehnt sich nach Ruhestand!

[robbitop]

AMD muss bei GloFo bleiben (bis 2022 AFAIK) und deren Fahrplan sieht nunmal 14LPP -> 14HP -> 7HP vor. Abseits dessen gibts nur noch die Billigprozesse 14LPP+ und 22FDX (sicherlich gibts noch einen 14FDX planar), 10nm FF ohne SOI ist ja schon gecancelt worden. AMD bleibt gar nichts anderes übrig als darauf zu setzen. Die Zukunft von GloFo ist SOI (in jeglicher Hinsicht sogar), also ist das auch AMDs Zukunft, so einfach ist das.

Interessant- gerade weil es noch eine ganze Weile lang so aussah, als wären die Tage von SOI gezählt...
Handelt es sich dabei um FD SOI?

soweit ich weiß: FinFET + SOI, also keine Rückkehr zu SOI sondern eine Kombi aus FinFET und SOI.

wieso sollte SMT beim ZEN mehr bringen als bei Intel? ZEN ist das "Erstlingswerk" von AMD bzgl. SMT. Intel hat damit schon wesentlich mehr Erfahrung. Für Intel wäre es IMHO ja sehr blamabel wenn AMD bereits beim ersten Versuch besser wäre als Intel. Die Diskussionen über SMT beim ZEN (auch in anderen Foren) kann ich deshalb nicht ganz nachvollziehen.

Und ja, im Umkehrschluss müsste das heißen das die Single-Thread-Leistung des ZEN-ES beim Blender-Benchmark höher war als die des Broadwell-E ... ebenfalls nahezu unglaublich. Vor allem wenn man sich die Benchmark-Tabelle auf pcgameshardware angeschaut hat und sieht wie die Bulldozer in dem Benchmark abschneiden.

http://www.pcgameshardware.de/Broadwell-Codename-259477/Specials/Core-i7-6950X-6900K-Benchmark-Test-1196801/

6900K: 143sec
8370K: 465sec

FinFet hat nichts mit SOI zu tun. Genau wie lowk / highk etcpp.

SMT ist ein altes Konzept. Es bringt umso mehr umso weniger die Ressourcen des Kerns ausgelastet sind. Zen ist sehr breit und hat dazu mehr Executionports und jeweils eigene Sheduler. Deshalb ist es nicht unwahrscheinlich, dass SMT auf Zen besser skaliert. Ähnlich bzw noch extremer ist die Skalierung auf Power8.

[Botcruscher]

Soweit zumindest die Theorie. Seit Sandy ist auch alles breiter geworden aber HT hat trotzdem nicht viel profitiert.

[Dino-Fossil]

Aber ist es nicht so, dass HT bis Sandy auch schon mal Performance-Nachteile gebracht hat, was mit Ivy und später weitestgehend der Vergangenheit angehört hat?

[victore99]

Letzten Endes wird auch der finale Takt sowie Übertaktungspotenzial ausschlaggebend dafür sein, wer sich jetzt was kauft.
Bringt nix, wenn Zen bei 3,5-3,8 GHz dicht macht während Intels bis rauf auf 4,8 wenn nicht sogar 5 GHz gehen. Ich bin da aber einfach mal guter Dinge. :D
Und die 6/8/10-Kerner machen wesentlich weniger. 4.4 mit Glück.
Trotzdem: notfalls kommt der Preis und das Segment um 150€, wo es bei intel eh nichts mit OC ist.

[Thunder99]

Bringt nur AMD nichts. Sie MÜSSEN wieder Prozessoren im 200-400€ Bereich anbieten um konkurrenzfähig zu sein. Daher MUSS das Topmodell 4C/8T 4GHz+ haben und der 8C/16T entsprechend weniger (wie bei Intel). Nur dann wird es was mit Umsatz und Gewinn für das Fortbestehen des Unternehmens.

Konkurrenzfähig heißt aber auch 10% langsamer mit 10% geringeren Preis ;)

[MR2]

Die FX 9-irgendwas kosten doch schon 200€+. Das wird schon.

[HOT]

Interessant- gerade weil es noch eine ganze Weile lang so aussah, als wären die Tage von SOI gezählt...
Handelt es sich dabei um FD SOI?
[...]

22FDX -> war mal 28nm FDSOI
14HP -> 14FF + FDSOI
7HP -> 10FF + FDSOI + EUV (IBM ist da ja im Testlauf)
14LPP+ -> Billigversion von 14LPP ohne FDSOI, ist aber eine Eigenentwicklung, entspricht nicht 14LPC von Samsung

[mboeller]

Interessant- gerade weil es noch eine ganze Weile lang so aussah, als wären die Tage von SOI gezählt...
Handelt es sich dabei um FD SOI?



FinFet hat nichts mit SOI zu tun. Genau wie lowk / highk etcpp.


aber kann beides kombinieren! Das ist für einige die Zukunft. Siehe auch :
http://www.soiconsortium.org/pdf/Comparison%20study%20of%20FinFETs%20-%20SOI%20versus%20Bulk.pdf

... die haben natürlich ein Interesse daran es besonders gut darzustellen. Aber die Kombination aus FD-SOI und FinFET ist möglich und hat Vorteile gegenüber Bulk-Finfet wenn man den entsprechenden Präsentationen glauben darf. Siehe auch den Beitrag von HOT über meinem

[StefanV]

Bringt nur AMD nichts. Sie MÜSSEN wieder Prozessoren im 200-400€ Bereich anbieten um konkurrenzfähig zu sein. Daher MUSS das Topmodell 4C/8T 4GHz+ haben und der 8C/16T entsprechend weniger (wie bei Intel). Nur dann wird es was mit Umsatz und Gewinn für das Fortbestehen des Unternehmens.

Konkurrenzfähig heißt aber auch 10% langsamer mit 10% geringeren Preis ;)
Nein, sie müssen einfach nur deutlich mehr absetzen und einen entsprechenden Marktanteil bekommen.
Die Fertigung der nackten CPUs ist einfach so dermaßen billig, dass das ganze auch für relativ wenig verkauft werden kann...

Und da macht es dann schon was aus, wenn man relativ viel umsetzen könnte...

[mboeller]

Soweit zumindest die Theorie. Seit Sandy ist auch alles breiter geworden aber HT hat trotzdem nicht viel profitiert.

Aber ist es nicht so, dass HT bis Sandy auch schon mal Performance-Nachteile gebracht hat, was mit Ivy und später weitestgehend der Vergangenheit angehört hat?


eben! Das sehe ich auch so.
Und dann kommt AMD "so locker flockig" daher und ihr SMT ist im ersten Versuch gleich besser als das von Intel nach mehreren Prozessorgenerationen. Das kann ich nicht glauben.

[Iruwen]

Sie haben sich ja auch genug Zeit gelassen :cool:

[Unicous]

eben! Das sehe ich auch so.
Und dann kommt AMD "so locker flockig" daher und ihr SMT ist im ersten Versuch gleich besser als das von Intel nach mehreren Prozessorgenerationen. Das kann ich nicht glauben.

Nicht besser.:rolleyes:

Anders.(y)

[YfOrU]

Bringt nur AMD nichts. Sie MÜSSEN wieder Prozessoren im 200-400€ Bereich anbieten um konkurrenzfähig zu sein. Daher MUSS das Topmodell 4C/8T 4GHz+ haben und der 8C/16T entsprechend weniger (wie bei Intel). Nur dann wird es was mit Umsatz und Gewinn für das Fortbestehen des Unternehmens.

Das Topmodell bei AMD hat 8C/16T. Gegenüber Intels i7 mit 4C/8T und 91/95W TDP wird wohl 6C/12T platziert.

AMD CPUs mit 4C/8T sind eigentlich ein anderes Thema denn das werden in erster Linie APUs. Also wie bei Intel mit IGP (-> Raven Ridge). Hierüber muss AMD aber nicht mit K SKUs konkurrieren (-> Summit Ridge) sondern vor allen mit den regulären 65W Desktop und 4,5 - 45W Mobile Produkten. Extrem hohe Frequenzen sind hierfür grundsätzlich nicht notwendig solange die IPC halbwegs konkurrenzfähig ist.

[Swissr]

Ja, ein zu Intel ähnlich performanter <100 Watt Prozessor im Preisbereich von 200-300 Euro mit >= 4C/8T und WICHTIG: guten Mainboards mit geringem Idle-Verbrauch wären für mich wirklich ein Kaufgrund um vom meinem Asus Sabertooth 990FX und dem 8320er zu wechseln.

Habe vor kurzem für einen Kumpel ein B85 Board mit I5-6500 zusammengebaut. Idle-Verbrauch mit GTX1070 im Windows: 27 Watt, unter Last max 200 Watt.
Das Ganze in einem Fractal Core 500 fürs Wohnzimmer (kein sonstiger Monitor).
Egal bei welchem Spiel, deutlich leiser als die PS4 oder Xbox. Das hatte mich schon irgendwie beeindruckt :-)

Nichtsdestotrotz würde ich gerne AMD unterstützen.

[S940]

Interessant- gerade weil es noch eine ganze Weile lang so aussah, als wären die Tage von SOI gezählt...
Handelt es sich dabei um FD SOI?

Hab das Paper dazu geladen, heißt:

High Performance 14nm SOI FinFET CMOS Technology with
0.0174μm2 embedded DRAM and 15 Levels of Cu Metallization

Da steht nirgends was von FD .. nur immer von SOI. Wenn ich mich recht erinnere gabs das auch auch mal als letzte normale SOI-Version auf irgendeiner Roadmap.

Werbung machen die in dem Paper auch für Ihr EDRAM ... das wär doch auch was für Zen+, oder? Den L2 auf 1MB vergrößern und dafür etwas langsameren aber deutlich größeren L3 dazu. Oder halt als L4, aber ob das soviel Sinn machen würde? Naja AMD wird schon ne Idee haben, ob, bzw. wie sie das nutzen ;)

So oder es, es freut mich, AMD hatte früher immer IBMs HP-Prozesse benutzt, so schlecht kann das gar nicht werden ;)

[S940]

eben! Das sehe ich auch so.
Und dann kommt AMD "so locker flockig" daher und ihr SMT ist im ersten Versuch gleich besser als das von Intel nach mehreren Prozessorgenerationen. Das kann ich nicht glauben.

Für SMT brauchts in Normalfall keine Superintelligenz, was es braucht sind freie Ports, so dass der 2. Thread Platz hat.

Genau das gibts bei Intel nicht, im Grund ist die Architektur schlecht für SMT, aber bekanntlich hats sogar auf dem P4-Vorteile gebracht. Meistens ist das dann aber nur die Zeit wo Thread 1 auf den Speicher warten muss, sowas gibts natürlich immer und überall in jeder Architektur. Von daher ist SMT per se immer ne gute Idee, aber wenn man es wirklich ausnutzen will, dann braucht man auch noch eine breite Architektur dafür und die hat der Zen. Spezielles Hirnschmalz ist dafür nicht notwendig von daher kannst Du ruhig davon ausgehen, dass Zen mit SMT etwas besser skaliert, v.a. wenn im Programmcode viel INT+FP gemischt ist.

[Der_Korken]

Ich hätte mal eine theoretische Frage: Soweit ich weiß, können aktuelle Prozessoren bei einem Branch auch Code spekulativ ausführen und wenn der Branch tatsächlich genommen die Ergebnisse direkt übernehmen (oder eben verwerfen). Ist es möglich auch beide Branches spekulativ auszuführen, falls genug Ports frei sind? Das könnte bei Zen ja vielleicht etwas bringen, wenn auf einem Core nur ein Thread ausgeführt wird.

[Rabiata]

. Vor allem wenn man sich die Benchmark-Tabelle auf pcgameshardware angeschaut hat und sieht wie die Bulldozer in dem Benchmark abschneiden.

http://www.pcgameshardware.de/Broadwell-Codename-259477/Specials/Core-i7-6950X-6900K-Benchmark-Test-1196801/

6900K: 143sec
8370K: 465sec
Bulldozer war auch kein Ruhmesblatt für AMD :freak:.
Die ersten Versionen haben einzelne Benchmarks gegen den Vorgänger verloren, da muß ich bei Intel ins Jahr 2000 zurückgehen (http://www.anandtech.com/show/661) um etwas vergleichbares zu finden (siehe der Sysmark 2000 Test und SPECviewperf6.1.2 - Awadvs04).

Piledriver als zweite Version hat dann die Rückschritte bei der IPC aufgeholt und zumindest die Blamage vermieden, (manchmal) vom Phenom II geschlagen zu werden. Aber davon, Sandy Bridge oder gar Ivy Bridge einzuholen konnte keine Rede sein.

Da sieht Zen schon sehr viel wettbewerbsfähiger aus :smile:

[Naitsabes]

Werbung machen die in dem Paper auch für Ihr EDRAM ... das wär doch auch was für Zen+, oder? Den L2 auf 1MB vergrößern und dafür etwas langsameren aber deutlich größeren L3 dazu. Oder halt als L4, aber ob das soviel Sinn machen würde? Naja AMD wird schon ne Idee haben, ob, bzw. wie sie das nutzen ;)




Das könnte eventuell für APUs interessant sein. Also als sehr großer Cache auf dem Die (quasi wie bei der XOne, bzw. eher wie bei der Wuu.) Sollte aber eben ein Cache sein und nicht extra angesprochen werden müssen. Also eigentlich wie bei Skylake, nur eben ondie :freak:

[Botcruscher]

Von daher ist SMT per se immer ne gute Idee...
Nö. Sobald der Thread der der läuft in irgend einer Form zeitkritisch wird eben nicht mehr. Es ist nur super wenn irgendwelcher unabhängiger Müll verwurstet wird. Klassiker sind da die P4 Werbe-Beispiele Rendern und Virenscanner. Deswegen werden sich mit SMT immer irgendwelche Negativbeispiele finden lassen. Kerngehopse und Speicherprobleme kommen dann noch dazu.

[iuno]

Also eigentlich wie bei Skylake, nur eben ondie :freak:
Wieso soll es unbedingt on die sein?
Der dram an sich ist doch sicher billig zu fertigen, die Verbindung sollte auch kein Problem sein. Salvage kann man zudem ohne edram verkaufen.
Oder halt gleich hbm, Samsung hat da ja was billiges im petto, wo man keinen si interposer braucht. Bis zen+/raven Nachfolger sollte man das doch hinbekommen

[OBrian]

ja, ich mach mir ja auch Sorgen, wie häufig und wie stark es Nachteile durch SMT geben wird. Bei Intel hat man jahrelang und über viele Generationen daran geschraubt, um es zumindest so hinzukriegen, daß man es anlassen kann, ohne sich Sorgen machen zu müssen. Man kann hoffen, daß AMD nicht bei Null anfängt auf dieser Lernkurve.

Sollte SMT auf Zen natürlich viel besser skalieren, dann ist man auch viel schneller im Plus. Sicher gibt es einige Extremsituationen, wo es bremst, aber meist kommt gleich danach ja wieder was, wo es was bringt, und wenn es dann viel bringt, gleicht sich das mehr als aus.

Naja, man wird abwarten müssen, wie es sich tatsächlich bei echter Software schlägt.

[mczak]

Ich hätte mal eine theoretische Frage: Soweit ich weiß, können aktuelle Prozessoren bei einem Branch auch Code spekulativ ausführen und wenn der Branch tatsächlich genommen die Ergebnisse direkt übernehmen (oder eben verwerfen).

Selbstverständlich, Sprungvorhersage ist absolut essentiell ("normaler" Code besteht aus jeder Menge Branches, durchaus 20%).

Ist es möglich auch beide Branches spekulativ auszuführen, falls genug Ports frei sind?
Möglich ist sowas schon (nennt sich "eager execution", gibt ein paar Studien darüber). Das ist aber schlicht zu teuer da immer beide Varianten auszuführen, so viele freie Ausführungseinheiten hat kein Chip (bei 20% Sprüngen im Code hast du dann auch mehrere in-flight, das wäre dann also möglicherweise locker 8x so viele Befehle (angenommen 3 Ebenen tiefe Sprünge die parallel alle abgearbeitet werden). Auch aus Effizienzgründen wäre das eine Katastrophe.

[Der_Korken]

Möglich ist sowas schon (nennt sich "eager execution", gibt ein paar Studien darüber). Das ist aber schlicht zu teuer da immer beide Varianten auszuführen, so viele freie Ausführungseinheiten hat kein Chip (bei 20% Sprüngen im Code hast du dann auch mehrere in-flight, das wäre dann also möglicherweise locker 8x so viele Befehle (angenommen 3 Ebenen tiefe Sprünge die parallel alle abgearbeitet werden). Auch aus Effizienzgründen wäre das eine Katastrophe.

OK, 20% sind heftig, hätte mit deutlich weniger gerechnet. Wenn das Instruktionsfenster dann mehrere Branches überdeckt, bringt das kaum noch Ertrag, weil man zu sehr in die Breite rechnet.

Hat mich nur mal interessiert, ob sowas schon mal ernsthaft bei CPUs gemacht wurde, um die IPC zu erhöhen.

[mczak]

OK, 20% sind heftig, hätte mit deutlich weniger gerechnet.
Ja da staune ich auch immer wieder, rein subjektiv würde man das wohl deutlich tiefer schätzen... Aber es kommt nicht von ungefähr dass manche CPUs sogar zwei Branches pro Takt bearbeiten können (z.B. intel cpus ab Haswell, die apple arm cores seit a7, und Zen auch).

[BlackBirdSR]

Beim P4 wurden Instruktionen spekulativ ausgeführt (angefangen) , bevor die Daten dazu aus dem L1 Cache geladen waren.
Wenn die Vorhersage dazu falsch war, musste das ganze nochmal ausgeführt werden. (Replay).

Das Ganze kam aber eher durch den hohen Takt und der extrem langen Pipeline zustande. IPC hat das nicht bedeutend viel gebracht, Verlustleistung schon ;)


OK, 20% sind heftig, hätte mit deutlich weniger gerechnet. Wenn das Instruktionsfenster dann mehrere Branches überdeckt, bringt das kaum noch Ertrag, weil man zu sehr in die Breite rechnet.

Hat mich nur mal interessiert, ob sowas schon mal ernsthaft bei CPUs gemacht wurde, um die IPC zu erhöhen.

[robbitop]

Soweit zumindest die Theorie. Seit Sandy ist auch alles breiter geworden aber HT hat trotzdem nicht viel profitiert.

Die Cores haben weniger Ports und Sheduler. Dann bringt ein breiteres Backend bei SMT wenig.

[robbitop]

aber kann beides kombinieren! Das ist für einige die Zukunft. Siehe auch :
http://www.soiconsortium.org/pdf/Comparison%20study%20of%20FinFETs%20-%20SOI%20versus%20Bulk.pdf

... die haben natürlich ein Interesse daran es besonders gut darzustellen. Aber die Kombination aus FD-SOI und FinFET ist möglich und hat Vorteile gegenüber Bulk-Finfet wenn man den entsprechenden Präsentationen glauben darf. Siehe auch den Beitrag von HOT über meinem
Man kann alles mögliche kombinieren. Es hat aber alles nichts mit SOI zu tun. Man ist damals wegen der Kosten und der Nutzung unterschiedlicher Prozesse auf einen einheitlichen Bulk Prozess umgestiegen. Finfet ändert an dieser Situation mWn nichts. Insofern verwundert mich diese Rolle rückwärts. Damals war es PD SOI und jetzt ist es wohl FD SOI.

Dass breitere Designs besser mit SMT skalieren ist nicht zwangsläufig besser. Alles breiter und redundant machen kann jeder. Das hat aber auch Nachteile. Jeder Kern wird größer und leistungshungriger. Und man hat weniger Transistor/Powerbudget für mehr ST Leistung.

Der Extremfall ist EV8 oder aber Power8.

@S940
EDRAM als L4 sollte schon was bringen. Beim i7 5775C (Broadwell mit gt3e) war der IPC Vorteil IMO beachtlich!

[S940]

Man kann alles mögliche kombinieren. Es hat aber alles nichts mit SOI zu tun. Man ist damals wegen der Kosten und der Nutzung unterschiedlicher Prozesse auf einen einheitlichen Bulk Prozess umgestiegen. Finfet ändert an dieser Situation mWn nichts. Insofern verwundert mich diese Rolle rückwärts. Damals war es PD SOI und jetzt ist es wohl FD SOI.
Das hatten wir weiter vorne glaub ich schon mal beschrieben. Mit SOI spart man sich ein paar Belichtungsschritte, hat also einen kleinen Kostenvorteil, der für die saftigen Waferkosten aber wieder draufgeht.
Aber: Je kleiner die Strukturen werden, also je mehr Chips man auf den Wafer bekommt und je mehr double/triple/quadrupel-Belichtung man braucht, desto attraktiver wird ein SOI Prozess.
Wenns dann auch noch mehr Takt als Sahnehäubchen dazu gibt, ein Win-Win-Prozess.
Die Rolle Rückwärts erklärt sich daraus, dass man vor ~5 Jahren mal plante jetzt schon längst EUV einetzen zu können. Aber das ist immer noch nicht fertig, ergo braucht man nen Plan B, der funktioniert und einigermaßen günstig zu haben ist.

Dass breitere Designs besser mit SMT skalieren ist nicht zwangsläufig besser. Alles breiter und redundant machen kann jeder. Das hat aber auch Nachteile. Jeder Kern wird größer und leistungshungriger. Und man hat weniger Transistor/Powerbudget für mehr ST Leistung.
Das stimmt einerseits, andererseits kostet der fette unified scheduler bei Intel aber auch einiges an Transistoren und bedient sich am Powerbudget.

So oder so mach ich mir bei AMD keine Sorgen, die haben ja ihre HDLibs, die sie sicher einsetzen werden. Damit können sie sich sowas leisten.
Edit: Und 256bit FPUs haben sie auch nicht. Die kosten ebenfalls Einiges.

Der Extremfall ist EV8 oder aber Power8.
Ja, wobei ein EV8 in 28 oder gar 14nm Finfet doch ein recht zahmer Vertreter sein dürfte ;)
@S940
EDRAM als L4 sollte schon was bringen. Beim i7 5775C (Broadwell mit gt3e) war der IPC Vorteil IMO beachtlich!
Stimmt, den gabs ja auch noch, Danke fürs Erinnern. Na dann hoffen wir mal, dass sich AMD beim Zen+ ne Packung EDRAM leistet ;)

[OBrian]

wäre HBM statt eDRAM denn nachteilig? Immerhin ist AMD ja schon fleißig am HBM verbauen, sie haben also Controller dafür, LKW mit dem Zeug drin fahren eh auf den Hof, in der Server-APU soll es eh vorkommen, also warum nicht für die CPU mitnutzen?

[iuno]

Ich sehe keinen Grund, warum. Teurer vielleicht...
Das was Samsung machen will, koennte aber auch mit HBM weniger zu tun haben, sondern gerade so ein Zwischending. Die wollen ja das Logik die weglassen und einfach nur dram stacken, so wie ich das verstanden habe. Nur zum Spass machen die das auch nicht, AMD koennte da schon potentieller Kunde sein.

[Hübie]

Jetzt wollte ich noch einmal kurz nachhaken: Irgendwo hier sagte jemand Zen habe doppelt so viele issue-ports als Intel (Skylake eingeschlossen?). Das mag ich gerade nicht so recht glauben. Woher stammt diese Info und wo kann ich mich da mal schlau lesen? Gibt es denn schon mehr zu Zen?

[Locuza]

Jetzt wollte ich noch einmal kurz nachhaken: Irgendwo hier sagte jemand Zen habe doppelt so viele issue-ports als Intel (Skylake eingeschlossen?). Das mag ich gerade nicht so recht glauben. Woher stammt diese Info und wo kann ich mich da mal schlau lesen? Gibt es denn schon mehr zu Zen?
S940 war es denke ich (Opteron im Planet3DNow!).

Zen hat 4-Issue Ports mit jeweils eigenen Schedulern für die ALUs und ebenso zwei Issue-Ports mit eigenen Schedulern für die zwei AGUs.
Die Floating-Point-Unit hängt getrennt an einem eigenen Scheduler mit 4-Issue-Ports für zwei mal MUL und zwei mal ADD.
Zen bietet also insgesamt 10 Ports an:
https://pbs.twimg.com/media/CqlsWToUMAAXKHG.jpg
https://twitter.com/Daniel_Bowers/status/768264672055218176/photo/1

Intel dagegen hat einen fetten gemeinsamen Scheduler an dem Integer- und Floating-Point gemeinsam angeschlossen sind:
https://pbs.twimg.com/media/Cqliq1PVYAUAHiC.jpg:large
https://twitter.com/addisonsnell/status/768253715744591873/photo/1

In dem Schaubild sieht man gleich das für Integer- und FP-Pipes insgesamt 4 Ports zur Verfügung stehen, bei Zen dagegen gibt es 4 Ports für die Integer-Pipes und 4 Ports für die FP-Pipes.
Also 4 (Skylake) vs. 8 (Zen) in dem Fall.

Demgegenüber hat Intel mehr Load/Store-Einheiten.
Insgesamt verwendet Skylake 8 Ports.

Das ist dann praktisch die Grundlage für den Gedanken, dass Zen besser als Intels CPUs bei SMT skalieren wird, da FP- und Integer-Workload die Ports nicht gegenseitig blockieren kann.
Aber die Load/Store-Einheiten haben sicher auch bei der Skalierung etwas zu melden, ebenso hat Skylake an vielen Stellen die größeren Workload-Puffer.
Bezüglich Zen weiß man auch nicht wie viele Instruktionen eine Fetch-Queue für einen Thread beinhaltet.
Es wird sicher interessant sein, wie gut Zen mit SMT skaliert.

[robbitop]

Guten morgen Hübie. Das sind alles Infos aus den letzten 2 Wochen, die jeweils auf allen möglichen Webseiten als Artikel stehen. ;)

Ich fand es bei Haswell damals merkwürdig, dass trotz einer weiteren ALU keine bessere Skalierung bei SMT zustande kam. Issueports und Sheduler zeigten sich damals schon etwas verdächtig IMO. Skylake bekam sogar nich einen weiteren Decoder. Dennoch keine bessere Skalierung...

@HBM/edram
Wie sieht es da eigentlich mit den Latenzen aus? Gerade die waren IIRC bei Fijiis HBM nicht so toll, oder?
Ich würde mich nicht wundern, wenn die Zugriffszeit das wichtigere Element beim IPC Vorteil des L4 vom 5775C war. Skalierung mit der Bandbreite ist idR ja kaum zu erkennen, wenn sie nicht gerade besonders limitiert. Siehe Quadchannel vs Dualchannel auf der X99 Plattform

[S940]

Guten morgen Hübie. Das sind alles Infos aus den letzten 2 Wochen, die jeweils auf allen möglichen Webseiten als Artikel stehen. ;)

Ne das ist Stand Oktober 2015:
http://www.planet3dnow.de/cms/20255-analyse-der-vermuteten-zen-architektur/

;)

@HBM/edram
Wie sieht es da eigentlich mit den Latenzen aus? Gerade die waren IIRC bei Fijiis HBM nicht so toll, oder?
Ich würde mich nicht wundern, wenn die Zugriffszeit das wichtigere Element beim IPC Vorteil des L4 vom 5775C war. Skalierung mit der Bandbreite ist idR ja kaum zu erkennen, wenn sie nicht gerade besonders limitiert. Siehe Quadchannel vs Dualchannel auf der X99 Plattform

Davon gehe ich auch aus, die Latenzen werden der springenden Punkt sein. Die Frage ist aber auch, wie man EDRAM/HBM an den Kern anflanscht. Braucht ja auch nen Cache-Controller dazu, der auf dem Die noch nicht vorgesehen ist. Also das naheliegenste würde wohl sein EDRAM als L3-Ersatz zu nehmen und im Ausgleich, weils langsamer ist, die L2-Caches auf 1MB zu vergrößern. Pi*Daumen sollte flächenmäßig dann zwar keine 100 MB drin sein, aber wenigstens so 16 MB aufwärts pro Quadcluster. Unterm Strich dürfte auch das besser sein, als das aktuelle Setup aus 4x512kB + 1x8MB.

[robbitop]

Was damals aber noch unbestätigt war. Seit 2 Wochen ists bestätigt und überall zu lesen. ;)

[S940]

Was damals aber noch unbestätigt war. Seit 2 Wochen ists bestätigt und überall zu lesen. ;)
Jein, es waren damals auch schon Complier Patches von Entwicklern mit amd.com-Adressen. Das ist auch offiziell.

Aber gut - hätte natürlich sein können, dass AMD die Leute absichtlich hinters Licht hätte führen wollen, das Risiko bestand natürlich, aber aus meiner Sicht ist das nur der Unterschied zw. 99% und 100% ;)

[robbitop]

Und immer muss er das letzte Wort haben. :D

[S940]

Lol, also für so Kindereien wer wo das letzte Wort hat, haben wir eigentlich beide zuviele Postings auf dem Counter ;)

Ich hab in der Zwischenzeit mal genauer nachgeschaut (und bevor ein Edit oben untergeht, besser gleich hier nen extra Post) 16 MB eDRAM L3 war etwas zu konservativ geschätzt:

Bei IBMs 22nm Prozess sind 512 kB L2-SRAM laut Die-Foto etwas kleiner als die Hälfte eines 8 MB eDRAM L3-Cachesegements, also vorsichtig gerechnet ca. ein Verhältnis von 1:6,5. Wenn man jetzt AMDs L2 und L3-SRAM-Größen gleich ansetzt, bliebe somit bei hypothetischen 4x1MB L2 Cache anstatt 6 MB L3-SRAM Cache auch noch Platz für ~40 MB eDRAM L3-Cache.

Also 32 MB könnten es mind. werden, zusammen mit den 1 MB L2 kann das gar nicht so schlecht sein ;)

Edit:
Wobei man sich die Vergrößerung des L2 eventuell auch schenken kann, das eDRAM hat bessere Latenzen als ich dachte:

http://www.anandtech.com/show/10435/assessing-ibms-power8-part-1/8

Schlecht wirds erst, wenn ein Power8 auserhalb seines 8 MB L3-Segment zugreifen muss, aber das geht dann immer noch schneller als wenn man nur 8 MB SRAM-L3 insgesamt hätte und als nächste Stufe aufs noch langsamer RAM, zugreifen müsste.

Also lassen wir den L2 mal bei 512 und nehmen stattdessen 48 MB L3 / 12 MB pro Kern ;)

[Hübie]

Ja, sorry hab halt kaum Zeit viel zu lesen. Danke euch für diese Zusammenfassung. Vielleicht mal alles auf Seite 1 einpflegen.

[robbitop]

Ja aber auf welcher Grundlage möchtest du dich denn an Diskussionen beteiligen, wenn du keine Zeit für die Informationen investieren möchtest? Wer mitreden will, sollte wenigstens halbwegs auf dem Stand sein, wenn es sinnvoll sein soll. Bitte fühle dich nicht persönlich angegriffen - du bist ein feiner Kerl. Es fällt mir halt einfach schon mehrfach auf. :)

[Hübie]

Na ja es ist halt mein Hobby und das kollidiert leider zeitlich öfter mit meinem Studium. Versuche nur die neuesten Insider-Infos abzugreifen. :smile: Kannst ja den Startpost mal mit neuen Infos füttern, dann hat jeder schnell einen Überblick.
Meine erste Anlaufstelle ist halt nicht immer cb oder pcgh etc, sondern 3DC.

[Unicous]

Dresdenboy geht ja seit längerem von einer die size zwischen 180-120mm² aus und The Stilt hat zumindest "bestätigt" dass es weniger als 200mm² sind.


Less than 200mm² is the right answer.

https://forums.anandtech.com/threads/new-zen-microarchitecture-details.2465645/page-112#post-38443309

Für einen "14"nm Prozess und 8 Kerne ist das ein durchaus annehmbares Ergebnis. Bei Broadwell-E (10 Kerne) sind es 246mm².

[Timbaloo]

Für einen "14"nm Prozess und 8 Kerne ist das ein durchaus annehmbares Ergebnis. Bei Broadwell-E (10 Kerne) sind es 246mm².
Aber Broadwell-E hat doch deutlich mehr L3-Chache. Muss wohl das I/O-Zeugs doch recht viel kosten.

[Unicous]

Der Vergleich hinkt natürlich an mehreren Stellen (Quad-Channel,...,), dennoch ist es ein gutes Ergebnis vor Allem da die "14"nm eben dann noch ein wenig gegen die "14"nm von Intel abstinken.

Man hätte ja auch durchaus auch auf 250mm²+ kommen können. Unter 200mm² finde ich dafür mehr als ordentlich.

[fondness]

Aber Broadwell-E hat doch deutlich mehr L3-Chache. Muss wohl das I/O-Zeugs doch recht viel kosten.

Dafür dürfte der Zen 8C sehr viel GMC-Links haben, wenn man da wirklich bis zu vier Cores oder eine GPU auf einem Träger zusammen schnaleln will.

[S940]

Einen Großen Kunden im Serverbereich? Wer kann das wohl sein...

Bin gerade über ein Prozessorgeflüster von vor ein paar Wochen gestolptert:
Bereits jetzt wurde schon der Global-Channel-Chef für die neue Dell-EMC nach dem Zusammenschluss benannt: John Byrne. Das ist ein gut bekannter Name – nein, ich meine nicht den amerikanischen Comic-Autor und Zeichner, der für die Neufassung des Superman verantwortlich war, sondern den langjährigen AMD-Verkaufschef. Dessen letzter Job bei AMD war auch der eines Superman, nämlich für das Business der Prozessoren und diskreten Grafikkarten zu sorgen.
Seit einem Jahr ist er jetzt bei Dell. Vielleicht hängt sein Herz noch an seinem alten Arbeitgeber und er legt sich dafür ins Zeug, dass die neue Dell-EMC sich intensiver mit dem Zen-Prozessor und den neuen AMD-Grafikchips beschäftigen wird, vielleicht auch mal wieder bei den Servern. http://www.heise.de/ct/ausgabe/2016-16-Von-Softbank-und-Superman-3271294.html

Stiller formuliert da sicherlich nur reines Wunschedenken, aber vor einem Jahr wusste der neue Global-Channel-Dell-Chef ganz sicher über Zen Bescheid.

Außerdem verbaute Dell schon früher zu K8-Zeiten AMD-CPUs.
So ein großer OEM braucht vermutlich schon deshalb eine 2. CPU-Quelle, um Intel Rabatte abknöpfen zu können.

[Hübie]

Menschen sind ja immer irgendwie beeinflusst, also wäre es gar nicht abwegig. Ich freue mich sogar wenn endlich wieder Bewegung ins Spiel kommt. Wenn Zen kein kompletter Reinfall wird, dann wechsel ich definitiv zu AMD.

[Oromis16]

Byrne ist nicht der einzige der bei Dell arbeitet und Kontakte zu AMD hat: http://www.bloomberg.com/news/articles/2015-03-20/dell-said-to-hire-former-amd-ceo-rory-read-as-coo

[LadyWhirlwind]

Byrne ist nicht der einzige der bei Dell arbeitet und Kontakte zu AMD hat: http://www.bloomberg.com/news/articles/2015-03-20/dell-said-to-hire-former-amd-ceo-rory-read-as-coo

Grundsätzlich dürften die alle bis zu einem gewissen Mass an AMD Chips interessiert sein, weil es auch die Verhandlungsmacht gegenüber Intel verbessert. Vorallem wenn man mit vergleichbaren Systemen die gleiche Performance kriegt.

[Unicous]

Dell ist ja auch die Adresse wenn es darum geht Monopolstellungen zu brechen.:freak:

Nur weil Byrne und Read da schon eine Weile zu Gange sind (und iirc hatte Read seinerzeit auch noch andere AMDler angeworben) heißt das nicht, dass Kostenkalkulationen gegenüber (ehemaligen?) Sympathien zurückstehen.

Der Herr Dell war und ist in der Hinsicht nie auf Nachhaltigkeit bedacht, was man auch an seinem Führungsstil sehen konnte. Hauptsache man kann Steuern bzw. Geld sparen.:rolleyes:

[dreas]

Der Herr Dell war und ist in der Hinsicht nie auf Nachhaltigkeit bedacht, was man auch an seinem Führungsstil sehen konnte. Hauptsache man kann Steuern bzw. Geld sparen.:rolleyes:

das ist sein job. mit sympatien wird kein geld erwirtschaftet. wenn amd einen günstigen leistungsfähigen chip bringt kann man über einen einsatz nachdenken. dann kämpft man aber immer noch mit dem schlechten image von amd gegenüber seinen kunden.

kohle wird aber mit masse und intel gemacht. das wissen die auch ganz genau. dort mit der amd fahne zu winken bringt nur ein müdes lächeln.

[Skysnake]

Da haste dich aber durchaus geschnitten.

Auch bei großen Firmen gibt es Leute die sogar auch mal einen schlechteren Deal eingehen, damit man sich unabhängiger macht und den Hauptlieferanten auf die Margenbremse drückt. Da ist oft auch einiges an Berechnung mit dabei.

Das mögen war insgesamt nur kleinere Summen sein, aber selbst darüber könnte sich AMD freuen. Und wie es bisher aussieht könnte ZEN ja sogar ein recht guter Deal sein!

Die Abhängigkeit von Intel ist so manchem ein großer Dorn im Auge. Das beflügelt ja sogar BigBlue, die nun nicht gerade für Preisleistungskracher bekannt sind...

[MR2]

http://wccftech.com/amd-am4-motherboards-debut-october/

Zeitgleich mit Bristol Ridge.
Wäre gut, wenn es die Boards bereits eher geben würde um beim Erscheinen von ZEN ausgereift zu sein.

[Unicous]

WTF-Tech Link?

But... why?


Die wahrscheinliche, superergiebige Quelle:

[...]
After some conversation the MSI rep told me that he is expecting to have some AM4 boards in October to demo at random event stuff across the province.

So hopefully this means the boards WIll be out before CPUs become available to the masses. :)
https://www.reddit.com/r/Amd/comments/4zzq5n/am4_motherboards_out_by_end_of_october/

[BlackBirdSR]

Hmmm...

ganz ehrlich?
Das limitiert nicht an den Ports. Da sind mehr als genug vorhanden, selbst bei Skylake.
Im Fall von SMT limitiert das Front-End, da auf der einen Seite Ressourcen halbiert werden, auf der anderen Seite quasi nur jeden 2. Takt eine Ressource zur Verfügung steht... da bist Du mal eben schnell auf 50% der Performance / Thread und weniger.

Wie und ob Zen jetzt hier besser ist, wird sich nicht an den Ports entscheiden;)


S940 war es denke ich (Opteron im Planet3DNow!).

Zen hat 4-Issue Ports mit jeweils eigenen Schedulern für die ALUs und ebenso zwei Issue-Ports mit eigenen Schedulern für die zwei AGUs.
Die Floating-Point-Unit hängt getrennt an einem eigenen Scheduler mit 4-Issue-Ports für zwei mal MUL und zwei mal ADD.
Zen bietet also insgesamt 10 Ports an:
https://pbs.twimg.com/media/CqlsWToUMAAXKHG.jpg
https://twitter.com/Daniel_Bowers/status/768264672055218176/photo/1

Intel dagegen hat einen fetten gemeinsamen Scheduler an dem Integer- und Floating-Point gemeinsam angeschlossen sind:
https://pbs.twimg.com/media/Cqliq1PVYAUAHiC.jpg:large
https://twitter.com/addisonsnell/status/768253715744591873/photo/1

In dem Schaubild sieht man gleich das für Integer- und FP-Pipes insgesamt 4 Ports zur Verfügung stehen, bei Zen dagegen gibt es 4 Ports für die Integer-Pipes und 4 Ports für die FP-Pipes.
Also 4 (Skylake) vs. 8 (Zen) in dem Fall.

Demgegenüber hat Intel mehr Load/Store-Einheiten.
Insgesamt verwendet Skylake 8 Ports.

Das ist dann praktisch die Grundlage für den Gedanken, dass Zen besser als Intels CPUs bei SMT skalieren wird, da FP- und Integer-Workload die Ports nicht gegenseitig blockieren kann.
Aber die Load/Store-Einheiten haben sicher auch bei der Skalierung etwas zu melden, ebenso hat Skylake an vielen Stellen die größeren Workload-Puffer.
Bezüglich Zen weiß man auch nicht wie viele Instruktionen eine Fetch-Queue für einen Thread beinhaltet.
Es wird sicher interessant sein, wie gut Zen mit SMT skaliert.

[robbitop]

Skylake bekam einen 5. Decoder und skalierte auch nicht besser als vorherige Generationen in SMT. Außerdem sollten 4 Decode für SMT doch eigentlich schon ordentlich sein. Selten ist die IPC pro Thread >2 soweit ich weiß. Oder willst du auf etwas anderes hinaus?
Power8 hat andererseits 8 Decoder - aber der kann/muss auch SMT8 ausführen und skaliert selbst bis SMT4 noch recht ordentlich. Insofern sollten Skylakes 5 Decoder für SMT2 doch mehr als genug sein, um nicht andauernd zum Flaschenhals zu werden, oder?

[BlackBirdSR]

5. Decoder und breitere Execution und bessere Port Verteilung.
Trotzdem aber nicht besser? Was sagt uns das?

Mit ca 2 mOps / Takt liegst du ganz gut.
Es gehen aus dem mOp Loop Buffer und cache auch nur 4 mOps / Takt raus.
Die Decoder sind auch nicht geshared, sondern bedienen abwechselnd einen Thread. Damit schonmal halbiert.
Fetch, Scheduler, Caches (mOps), alles geteilt.
Threads können nicht priorisiert werden.
Dann noch der abnehmende Grenzertrag...

Wenn Zen Threads intelligent ungleich behandeln kann, könnte das Vorteile bringen. Aber an den Ports liegt es nicht.




Skylake bekam einen 5. Decoder und skalierte auch nicht besser als vorherige Generationen in SMT. Außerdem sollten 4 Decode für SMT doch eigentlich schon ordentlich sein. Selten ist die IPC pro Thread >2 soweit ich weiß. Oder willst du auf etwas anderes hinaus?
Power8 hat andererseits 8 Decoder - aber der kann/muss auch SMT8 ausführen und skaliert selbst bis SMT4 noch recht ordentlich. Insofern sollten Skylakes 5 Decoder für SMT2 doch mehr als genug sein, um nicht andauernd zum Flaschenhals zu werden, oder?

[robbitop]

Und der/die Scheduler? Wie sieht es damit als potenzieller Flaschenhals aus?

Int und FP scheinen sich bei Intel die Ports zu Teilen. 4 Ports für Int/FP und 4 Ports für Load/Store. Zen hat dedizierte Ports für alles. Und je einen eigenen Scheduler für FP und Int.

Dass die Decoder pro Takt nur einen Thread bedienen können, klingt ...beschränkt. Wozu 5 Decoder, wenn ich praktisch nie mehr als 2..3 Instruktionen pro Takt aus einem Thread extrahieren kann? Das hieße ja, dass in jedem Takt 1-2 Decoder nichts tun...? SMT ändert an deren Auslastung nichts, weil ja offenbar jeder Thread jeden 2. Takt an die Reihe kommt. Und da ich von seriellen Aufgaben ausgehe, kann man auch nichts vorziehen...

[Skysnake]

Skylake bekam einen 5. Decoder und skalierte auch nicht besser als vorherige Generationen in SMT. Außerdem sollten 4 Decode für SMT doch eigentlich schon ordentlich sein. Selten ist die IPC pro Thread >2 soweit ich weiß. Oder willst du auf etwas anderes hinaus?
Power8 hat andererseits 8 Decoder - aber der kann/muss auch SMT8 ausführen und skaliert selbst bis SMT4 noch recht ordentlich. Insofern sollten Skylakes 5 Decoder für SMT2 doch mehr als genug sein, um nicht andauernd zum Flaschenhals zu werden, oder?
Power8 ist da wohl etwas speziell. Da kannste wenn ich mich richtig erinnere gar nicht mit einem Thread das FrontEnd auslasten, weil einiges nicht geshared wird.

Das ist schon sehr anders als bei AMD und Intel. Deswegen hat Power8 aber auch SMT8 und nicht nur SMT2.

[robbitop]

Anscheinend hat Power8 einiges doppelt. Vor allem wohl auch die Execution. Geht fast ein wenig in die Richtung CMT.

[Hübie]

Werden die Decoder bei Skylake denn über einen Ringbus bedient oder parallel über ein Interconnect? Das ist mir irgendwie entfallen. Über einen Ringbus macht es ja Sinn Redundanzen zu haben, auch wenn das Protokoll seit Ivy eigentlich schon ausgefeilt ist (shift, block etc).
Ansonsten sehe ich, ausgenommen von speziellen Szenarien, auch wenig Sinn im fünften Decoder...
Was Skylake half war ja der geteilte Cache wenn nur ein Thread gescheduled wird.

[robbitop]

Was genau meinst du mit geteiltem Cache?

[BlackBirdSR]

Ganz klar, bei geteilten Scheduler Ressourcen hält jeder Thread weniger Instruktionen vor. Das mindert die Leistung des einzelnen Threads.

Die Decoder sind sicherlich so ausgelegt, dass ein Teil davon Peaks abdeckt, also die letzten 5% mehr performance für 20% mehr Aufwand.. Kennen wir ja.
Zum anderen, ist es der Verlustleistung zuträglich, wenn nicht alles auf Peak läuft.

Die Ports bei Intel können alle 4 Alus auf einmal bedienen, was wohl eher selten vorkommt. Es kommen ja noch load Store etc.
Würde mich nicht wundern, wenn Zen auch nicht annähernd mehr auslastet und viel davon der thermischen Problematik geschuldet ist.
Die Zeiten sind vorbei, wo peak performance ohne Rücksicht auf Verlustleistung erzielt werden kann. (siehe AVX)

Bei den Ausfuhrungseinheiten kommt dann noch Latenz und Durchsatz ins Spiel. Was bringt es, wenn jeden Takt 5 bis 6 mOps abgesetzt werden könnten, aber die Einheiten noch gar nicht Zur Verfügung stehen. Das ist bei Intel imo durchaus berücksichtigt.

Ich meine damit nur: mit einem Vergleich der Ports wird es nicht getan sein. A



Und der/die Scheduler? Wie sieht es damit als potenzieller Flaschenhals aus?

Int und FP scheinen sich bei Intel die Ports zu Teilen. 4 Ports für Int/FP und 4 Ports für Load/Store. Zen hat dedizierte Ports für alles. Und je einen eigenen Scheduler für FP und Int.

Dass die Decoder pro Takt nur einen Thread bedienen können, klingt ...beschränkt. Wozu 5 Decoder, wenn ich praktisch nie mehr als 2..3 Instruktionen pro Takt aus einem Thread extrahieren kann? Das hieße ja, dass in jedem Takt 1-2 Decoder nichts tun...? SMT ändert an deren Auslastung nichts, weil ja offenbar jeder Thread jeden 2. Takt an die Reihe kommt. Und da ich von seriellen Aufgaben ausgehe, kann man auch nichts vorziehen...

[Affinator]

Dass die Decoder pro Takt nur einen Thread bedienen können, klingt ...beschränkt. Wozu 5 Decoder, wenn ich praktisch nie mehr als 2..3 Instruktionen pro Takt aus einem Thread extrahieren kann? Das hieße ja, dass in jedem Takt 1-2 Decoder nichts tun...? SMT ändert an deren Auslastung nichts, weil ja offenbar jeder Thread jeden 2. Takt an die Reihe kommt. Und da ich von seriellen Aufgaben ausgehe, kann man auch nichts vorziehen...

Die Decoder sind ja nicht auf ILP angewiesen. Solange x86-Instruktionen lokal im Cache liegen, können auch alle 5 Decoder voll durcharbeiten und mOps erstellen und weiterreichen. Die Abhängigkeiten zwischen den Operationen werden ja erst ab Issue relevant. Dafür gibt es ja direkt nach den Decodern einen Haufen Queues um die sich anhäufenden Operationen zwischenzuspeichern, falls Issue und Execution nicht schnell genug sind um die dekodierten Instruktionen abzuarbeiten.


Ein Beispiel von meinem Arbeitgeber: Es bringt nichts wenn du 10 Rohkarossen in der Stunde fabrizieren kannst, wenn der einzige Lackierer im Haus drei Stunden je Durchlauf braucht ;-)

[Nakai]

Was können die 5 Decoder von Intel? Bei Intel gibt es immer die Unterscheidung zwischen Complex-Decoder und Simple-Decoder. Wieviele hat Skylake von diesen jeweils? Haswell hatte 3 Simple-Decoder(pro 1 microOp)+1 Complex-Decoder (4 microOps).
Insgesamt konnte man dort dann nur 4 mOPs bis hin zum ReorderBuffer bringen.

Skylake hat das alles etwas erweitert. Aber was kann der 5te Decoder?

AMD hat 4 große Decoder, also welche 1-2 macroOPs erreichen. Man kann auch 6 dieser macroOPs zur Execution weiterreichen. Da ist Zen imo schon etwas stärker als Intel aufgestellt.

[BlackBirdSR]

Ja ich frage mich auch gerade, woher die Info mit dem 5. Decoder kommt?
Das habe ich nicht hinterfragt, und einfach übernommen vom Post oben.

IMO hat Skylake immernoch 4 Stk., kann 5 µOps weitergeben bzw. 6 aus dem µOps-Cache.

Dispatch ist auch 6µOps.

[S940]

Es gehen aus dem mOp Loop Buffer und cache auch nur 4 mOps / Takt raus.
Nö, Skylake kann 6 mOps aus dem µOp-Cache laden, nicht 4, das ist eine der Neuerungen. Sieht man auch auf dem Architektur-Bild, wenn man genau hinschaut. Da steht ne 6 beim µOp Cache und die 5 beim Decodern.
(Edit: siehe auch unten, die Posts haben sich überschnitten).

Darin, dass der Dekoder allein die Instruktionen nicht schnell genug herbekäme stimm ich zu. Mir gehts deshalb auch nur um den Instruktionsstream aus dem µOp-Cache.

Da wirds interessant, denn AMD kann a) vermutlich auch 6 mOps pro Takt aus den µOp-Cache laden (zumindest gehen soviel von der µOp-Queue zur Dispatch-Queue. Wenn der Input aus dem µOp-Cache nicht auch wenigstens 6 mOps betrüge, wäre soviel Bandbreite in der späteren Pipelinestufe überflüssig bis sinnlos.

Bei 2+2 mOps, die man pro Takt bei 2 Threads im Durchschnitt sehen wird, würde ich Dir zustimmen, da wären 4 Ports genug. Aber jetzt haben wir halt maximal 3+3. Der Fall wird zwar nicht sooft vorkommen, da das Mittel wie besagt bei ~2 Ops liegt, aber ist halt nur ein Mittel. Im Peak-Fall sind die 4 Ports von Intel dann zu wenig.

Die Preisfrage wird nur sein: Wie oft kommen solche Fälle vor?

Ich meine damit nur: mit einem Vergleich der Ports wird es nicht getan seinDas ist ebenfalls klar, dass Front-End muss breit genug sein, aber da hat AMD mit dem doppelt so großen Instruktion-Cache und vermutlich auch größerem µOp-Cache ebenfalls rangeklotzt.
Intel hingegen dürfte wenig Motivation zur I-Cache Vergrößerung haben, weil ihre Ports sowieso limitieren.
Merkwürdig ist z.B. auch der Sachverhalt, dass 6 mOps aus dem µOp-Cache kommen können, aber nur 4 aus der Renamer zum Scheduler, siehe Diskussion hier:
http://www.agner.org/optimize/blog/read.php?i=415

Intel wird sich das sicher gut überlegt haben. Einziger Grund dürfte sein, dass das Kosten/Nutzenverhältnis schlecht ist, was wiederum darin begründet sein dürfte, das sich der Nutzen in Anbetracht von nur 4 INT/FP-Ports sowieso in Grenzen halten würde.

Also ich stimm Dir da in allen Punkten zu, sehe bei AMD neben den breiten Portdesign aber auch das dazu nötigere breitere Front-End.

Sollte sich herausstellen, dass AMD irgendwo noch nen Flaschenhals mit max. 4 mOps im Front-End wie bei Intel hätte, dann brächten die vielen schönen Ports in der Tat nix.

Zitat von robbitop http://www.forum-3dcenter.org/vbulletin/images/3dc/insanedruid/buttons/viewpost.gif (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=11144584#post11144584) Skylake bekam einen 5. Decoder und skalierte auch nicht besser als vorherige Generationen in SMT. Außerdem sollten 4 Decode für SMT doch eigentlich schon ordentlich sein. Selten ist die IPC pro Thread >2 soweit ich weiß. Oder willst du auf etwas anderes hinaus?
5. Decoder und breitere Execution und bessere Port Verteilung.
Trotzdem aber nicht besser? Was sagt uns das?
Dass der Flaschenhals nach wie vor im Renamer sitzt ;) (Die Execution wurde auch nicht breiter, bei Skylake wie bei Haswell gibts 8 Ports. Es gab bei Skylake nur Feintuning in Form einer Umordnung der Exec-Units an den Ports.)

EDIT:

Ja ich frage mich auch gerade, woher die Info mit dem 5. Decoder kommt?
Das habe ich nicht hinterfragt, und einfach übernommen vom Post oben.

IMO hat Skylake immernoch 4 Stk., kann 5 µOps weitergeben bzw. 6 aus dem µOps-Cache.
Ok, sollte die BW aus dem µOp-Cache geklärt sein. Ansonsten zur 5: Siehe oben, steht auf dem Architekturbildchen. In der c't 27/15 stehts auch auf Seite 103. Also das stimmt schon.
Edit2: Siehe nächstes Posting 2 Postings tiefer.

[Nakai]

Ja ich frage mich auch gerade, woher die Info mit dem 5. Decoder kommt?
Das habe ich nicht hinterfragt, und einfach übernommen vom Post oben.

IMO hat Skylake immernoch 4 Stk., kann 5 µOps weitergeben bzw. 6 aus dem µOps-Cache.

Dispatch ist auch 6µOps.

Mhh, bei Haswell waren es nur 4 µOps von den Decodern und es waren eben 4 Decoder. Evtl hat man bei Skylake noch einen SimpleDecoder hinzugefügt. Hatte Broadwell E nicht auch 5 Decoder? Man findet wenig im Inet.

[Dino-Fossil]

Die wahrscheinliche, superergiebige Quelle:

https://www.reddit.com/r/Amd/comments/4zzq5n/am4_motherboards_out_by_end_of_october/

Das vermute ich auch. Und ein paar Demo-Produkte != Verfügbarkeit ab Oktober.
Aber wäre ja auch egal, wenn es vorraussichtlich keine Prozessoren vor Dezember/Januar gibt.

[S940]

Mhh, bei Haswell waren es nur 4 µOps von den Decodern und es waren eben 4 Decoder. Evtl hat man bei Skylake noch einen SimpleDecoder hinzugefügt. Hatte Broadwell E nicht auch 5 Decoder? Man findet wenig im Inet.

Da wurde anscheinend wirklich nur die Bandbreite vergrößert, nicht die Anzahl der Decoder. Siehe auch auf dem Skylake-Schema, da sieht man nur 4 Boxen bei den Decodern, obwohl die 5 danaben steht. Gut, das könnte jetzt noch ein copy/paste-Fehler sein, das Bildchen gabs so ähnlich schon früher bei Sandy, aber man kanns auch über den Complex-Decoder erklären, der läuft bei Intel ja parallel und kann pro Takt 1-4 µOps erzeugen.

Im Intel Optimization manual gibts bei Sandy-Bridge hier einen Eintrag, wo dieser Decoder 2 µOps liefert:
An instruction with RIP relative addressing is not micro-fused in the following cases:
• An additional immediate is needed, for example:
• CMP [RIP+400], 27
• MOV [RIP+3000], 142
• The instruction is a control flow instruction with an indirect target specified using RIP-relative
addressing, for example:
• JMP [RIP+5000000]
In these cases, an instruction that can not be micro-fused will require decoder 0 to issue two micro-ops,resulting in a slight loss of decode bandwidth.
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

Sowas könnte Skylake jetzt mit den 5 µOps/Takt erledigen. Ansonsten brächte es aber mangels weiterem Decoder nicht gerade viel. Anscheinend wars den Aufwand aber wert.

[Nakai]

Da wurde anscheinend wirklich nur die Bandbreite vergrößert, nicht die Anzahl der Decoder. Siehe auch auf dem Skylake-Schema, da sieht man nur 4 Boxen bei den Decodern, obwohl die 5 danaben steht. Gut, das könnte jetzt noch ein copy/paste-Fehler sein, das Bildchen gabs so ähnlich schon früher bei Sandy, aber man kanns auch über den Complex-Decoder erklären, der läuft bei Intel ja parallel und kann pro Takt 1-4 µOps erzeugen.

Im Intel Optimization manual gibts bei Sandy-Bridge hier einen Eintrag, wo dieser Decoder 2 µOps liefert:

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

Sowas könnte Skylake jetzt mit den 5 µOps/Takt erledigen. Ansonsten brächte es aber mangels weiterem Decoder nicht gerade viel. Anscheinend wars den Aufwand aber wert.

Wie Decoder von Intel, wenn 4 Stück verwendet werden, erreichen einen maximalen Durchsatz von 7 µOps (4 Complex + 3 Simple). Der Complex-Decoder kann 1 - 4 µOps dekodieren. Das Verhältnis 1:3 ergibt sich aus dem Verhältnis von komplexen Instruktionen zu simplen Instruktionen bzgl. X86-64-Code. AMD macht das anders. Da kann jeder Decoder "alles". Jeder Decoder kann alles dekodieren und 1 - 2 macroOps pro Takt dekodieren. macroOps != µOps, jedoch sind macroOps/µOps eher typische RISC-Instruktionen.

Wieviele Instruktionen nun an die Execution geliefert werden, kann man im Diagramm nicht sehen. Womöglich sind es 6.

[S940]

Wie Decoder von Intel, wenn 4 Stück verwendet werden, erreichen einen maximalen Durchsatz von 7 µOps (4 Complex + 3 Simple). Der Complex-Decoder kann 1 - 4 µOps dekodieren. Das Verhältnis 1:3 ergibt sich aus dem Verhältnis von komplexen Instruktionen zu simplen Instruktionen bzgl. X86-64-Code. AMD macht das anders. Da kann jeder Decoder "alles". Jeder Decoder kann alles dekodieren und 1 - 2 macroOps pro Takt dekodieren. macroOps != µOps,
Das ist schon alles klar, frag mich nur, obs der erhöhte Durchsatz von 5 statt 4 wirklich bringt. Schließlich kann der Cplx-Dec auch mehr als 2 µOps generieren. Das bringt also nur in nem Teilfall etwas. Aber Intel wirds schon wissen. Vermutlich gabs ausreichend Fälle, wo 2µOps erzeugt werden.

Wieviele Instruktionen nun an die Execution geliefert werden, kann man im Diagramm nicht sehen. Womöglich sind es 6.
Ne 4, das ist der erwähnte Renamer-Flaschenhals, siehe die Diskussion bei Agner Fog (Link oben).

[Nakai]

Das ist schon alles klar, frag mich nur, obs der erhöhte Durchsatz von 5 statt 4 wirklich bringt. Schließlich kann der Cplx-Dec auch mehr als 2 µOps generieren. Das bringt also nur in nem Teilfall etwas. Aber Intel wirds schon wissen. Vermutlich gabs ausreichend Fälle, wo 2µOps erzeugt werden.


Ne 4, das ist der erwähnte Renamer-Flaschenhals, siehe die Diskussion bei Agner Fog (Link oben).

Tatsächlich? Dann wird Zen da einen Vorteil haben.

[S940]

Tatsächlich? Dann wird Zen da einen Vorteil haben.Sag ich ja die ganze Zeit ^^

Was mir gerade noch aufgefallen ist: Wie implementiert Intel bei Skybridge die angegebenen 2x4 µOp-Retire / 4 pro Thread?
Steht bei Anantech:
the new design allows each thread in a core to retire four micro-ops in one cycle.http://www.anandtech.com/show/9582/intel-skylake-mobile-desktop-launch-architecture-analysis/5

Das Retire hängt doch an den Result-Bussen, die haben aber doch nix mit SMT zu tun, oder?

Bei Zen erklären sich die 8 Retire pro Takt relativ einfach aus 4xINT und 4xFP, in einem Schaubild sieht man da auch die Pfeile von den ALUs (aber nicht von den AGUs, wie es sich gehört) zur Retire Unit. Aber bei Skylake frag ich mich wie das pro Thread gehen soll. Vermutlich haben sie auch "nur" extra Leitungen von den FP/INT-Pipes zum ROB gelegt, also quasi 2 pro Port.

[robbitop]

Ja ich frage mich auch gerade, woher die Info mit dem 5. Decoder kommt?
Das habe ich nicht hinterfragt, und einfach übernommen vom Post oben.

IMO hat Skylake immernoch 4 Stk., kann 5 µOps weitergeben bzw. 6 aus dem µOps-Cache.

Dispatch ist auch 6µOps.
http://www.anandtech.com/show/10591/amd-zen-microarchiture-part-2-extracting-instructionlevel-parallelism/7

"Decode: 5 uops/cycle"

[S940]

http://www.anandtech.com/show/10591/amd-zen-microarchiture-part-2-extracting-instructionlevel-parallelism/7

"Decode: 5 uops/cycle"
Das ist leider wieder nur die Bandbreite. Gefragt war aber, ob es wirklich nen weiteren simple Decoder gibt.

[robbitop]

Hätte ich daraus jetzt geschlussfolgert.

[Nakai]

Nicht zwingend. Intel kann schon 7 mops decodieren pro Takt. Aber womöglich wäre ein zusätzlicher Decoder notwendig. Solche Designs sind normalerweise sehr generisch. Man kann an vielen Stellschrauben drehen und einfach mehr Einheiten skalieren. Evtl wird die Bandbreite eben durch mehr Einheiten erreicht, weil die Architektur so konzipiert ist.

[S940]

Hätte ich daraus jetzt geschlussfolgert.

Könnte man machen, aber es gibt auch noch ne andere Möglichkeit wie Nakai schon geschrieben hat. Details siehe Posting auf der letzten Seite:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=11144881#post11144881

100% sicher ist der 5. Decoder damit leider nicht.

[MR2]

http://seekingalpha.com/article/4003352-amd-confirmation-zen-troubles
Hier hat sich wieder mal jemand paar Gedanken zu Zen s Performance gemacht ;-)

[S940]

http://seekingalpha.com/article/4003352-amd-confirmation-zen-troubles
Hier hat sich wieder mal jemand paar Gedanken zu Zen s Performance gemacht ;-)

Finde ich sehr merkwürdig, der Artikel beginnt mit 3 Benchmarks:

- Ashes of Singularity (geleakt)
- Cinebench (offizielle Folie, die eine Verdopplung der Leistung von Orochi auf Summit Ridge verspricht)
- Blenderdemo von AMD, welches Gleichstand mit nem i7 6900 8Kerner suggeriert.

Schon auf Seite 2 gehts aber nur noch um Cinebench, es wird gemutmaßt, was Orochi sein könnt, man einigt sich auf nen FX-8100, was durchaus ok ist und schlussfolgert dann - zusammen mit den Ashes Benches - dass die Performance weiterhin lausig sein wird und AMDs Position nur etwas verbessert:
This, however, won't change the competitive nature of the market. Going from the data we have, AMD will still be forced to use 8-core chips to compete with Intel 4-core chips. The benchmarks we have, flawed as they might be, indicate that this is the most likely outcome. The same benchmarks indicate that the multi-thread gains versus the FX-8350 should be slightly less than 40%, because the gain on IPC and SMT are then partially lost on lower frequencies.

We now have 2 different benchmarks confirming these conclusions: The Ashes of the Singularity benchmark, and the Cinebench R15 benchmark, though the Cinebench R15 reality was rather hidden.

Offene Frage die bleibt: Wie passt das Blenderdemo zu ihren angeblichen "Daten", die auf reiner Spekulation beruhen?

Also das einzige Fazit das man ziehen kann ist nur eins: Dass bei denen auf Seite 6 schon vergessen wurde, was man auf Seite 1 schrieb :freak:

Da sind Schätzungen basierend auf der µArchitektur - die sehr passabel ausschaut und auf Nehalem <> Sandy-IPC hoffen lässt (je nachdem ob die Software AVX256 Code nutzt oder nicht) - eindeutig besser. Zwar fehlen für Leistungsaussagen dann noch die Faktor Herstellungsprozess / Takt, aber bei der obigen Spökenkiekerei fehlen ein paar 100 mehr :freak:

[Nakai]

Haswell sollte man erreichen. Zen kann pro Takt 10 mOps dispatchen(!).
Man hat zwar nur zwei LD/ST-Units, aber der FPU-Teil besitzt auch eine 128b Store-Pipe.

Zen ist eine unglaublich flache Architektur. Straight-forward, Clean-Sheet und sehr breit. Der ALU-Teil ist eher an K8 angelehnt, während die AGU/LD/ST eher nach Bulldozer aussieht. Der FPU-Teil sieht irgendwie wie eine Mischung aus Baumaschine und Wildkatze aus. Die Wildkatzen hatten eine mehrstufige Dekodierung mit dedizierten Integer und FP-Decodern. Das gibt es bei Zen nicht. Zens FPU sieht eher wie eine Baumaschinen-FPU mit Wildkatzen-Units aus.

[N0Thing]

Da sind Schätzungen basierend auf der µArchitektur - die sehr passabel ausschaut und auf Nehalem <> Sandy-IPC hoffen lässt (je nachdem ob die Software AVX256 Code nutzt oder nicht) - eindeutig besser. Zwar fehlen für Leistungsaussagen dann noch die Faktor Herstellungsprozess / Takt, aber bei der obigen Spökenkiekerei fehlen ein paar 100 mehr :freak:

Erhofft sich ernsthaft jemand einen IPC-Level von Zen zwischen Nehalem und Sandy Bridge?? :confused:
Das wäre für mich persönlich der worst case, denn dann wäre Zen für jeden, der eine Sandy Bridge CPU oder ein neueres Modell benutzt, in keinster Weise relevant oder interessant.

[Monsta]

Naja wenn ich "günstig" 8 Sandbridge Kerne bekomme mit modernen Schnittstellen wär das sicher für einige eine Aufrüstoption.

[Oromis16]

Stimmt, aber 8 Haswellkerne wärens für einige mehr ;)
[Identischer Takt vorausgesetzt]

[Hübie]

Erwartet wird Haswell IPC. Selbst wenns dann nur Ivy ist fände ich es Grund genug umzuschwenken. =)
Letztendlich wird entscheiden wie es in der Praxis unter 4k aussieht. Dazu müssen Reviewer halt Frameverläufe und Frametimes publizieren. Also wird es wieder nur eine sehr beschränkte Auswahl an Reviews geben.

[Undertaker]

Imo wäre durchgängig (nicht nur in einigen Spezialfällen und vor allem nicht nur mit SMT, falls das denn besonders gut skaliert) Haswell-IPC eine äußerst große, positive Überraschung. Taktraten von ~3,5 GHz darf man wohl durchaus erwarten, damit wäre man aus dem Stand auf dem Level des 6900K für 1.000 Euro. Das klingt einfach zu gut um wahr zu sein, vor allem hätte man dann cherry-picked Herstellerbenchmarks mit noch deutlich größeren Vorsprüngen gesehen.
Ich glaube auch nicht, dass euer oberflächliches Abzählen von Decodern, Ports etc. zielführend ist. Wie gut Sprungvorhersage, Trefferrate und Praxistempo der Caches usw. am Ende wirklich funktionieren, lässt sich dadurch nun einmal nicht abschätzen, und gerade das kann einen immensen Einfluss auf die letztendliche Performance haben.
Wenn im Anwendungs- und Spielemittel ein 6800K mit 6 Kernen erreicht wird, ziehe ich meinen Hut. Wenn es noch mehr wird, muss ich mir etwas neues überlegen. :D

[fondness]

Was vor allem viele vollkommen ignorieren ist die TDP. AMD gibt für den 8 Kerner nur 95W an. Wenn man damit Haswell IPC bei ~3,5Ghz erreichen würde, wäre die Perf/Watt deutlich über Intel. Das ist schon alleine angesichts der Fertigungsnachteils kaum realistisch.

Ich glaube auch nicht, dass euer oberflächliches Abzählen von Decodern, Ports etc. zielführend ist. Wie gut Sprungvorhersage, Trefferrate und Praxistempo der Caches usw. am Ende wirklich funktionieren, lässt sich dadurch nun einmal nicht abschätzen, und gerade das kann einen immensen Einfluss auf die letztendliche Performance haben.

Das ist natürlich korrekt. Allerings macht es auch keinen Sinn, mehr Ausführungseinheiten zu verbauen, als man füttern kann, denn das kostet nr unnötig Strom. Deshalb sagen solche Dinge häufig schon etwas über die IPC aus.

[robbitop]

Meiner Meinung nach sollte eine hohe Framerate in geringen Auflösungen im CPU Limit auch ein gut genuges Indiz für das Verhalten in hohen Auflösungen sein. Nur dass in hohen Auflösungen sehr wahrscheinlich die GPU immermehr zum Bottleneck wird. Ich wüsste nicht, warum eine absolut gesehen starke CPU zu schlechten Frametimes in hoher Auflösung führen sollte. Eine schwache CPU sicher eher. Aber den Unterschied zwischen beiden sieht man bei geringen Auflösungen IMO gut genug.

Edit: ich bin noch ein wenig vorsichtig mit der Erwartung zu Zen. Es gibt mit Blender (als einzigen handfesten Bechmark zu Zen) nur einen Synthie, der sehr gut von Parallelisierung und FP profitiert.
Die Int Performance bei unsortiertem Realworldcode könnte eine andere sein. AMD könnte hier den best case gezeigt haben.

Auch hinsichtlich Taktraten machen mich die 3 Ghz ein wenig stutzig. Die bisherigen Gerüchte sprachen bisher von moderaten Taktraten - auch für 4C - was nicht unbedingt nur für eine reine TDP Limitierung spricht sondern ggf für eine Taktwand.

[iuno]

Was vor allem viele vollkommen ignorieren ist die TDP. AMD gibt für den 8 Kerner nur 95W an.
Das ist auch noch ein Punkt, den ich kritisch sehe.
Ich hoffe, dass das nur fuer die "Standardmodelle" gilt und mit OC auch wesentlich mehr drin ist. ein entsprechend schneller 8C darf ja auch mal gut ueber 100W verbraten. Schlecht waere, wenn der Takt nicht ginge, auch bei deutlich hoeheren Spannungen und Verbrauch. Ansonsten sehe ich das genau wie Hübie

[Hübie]

IPC = instructions per cycle, also 3 vs 3 GHz oder 2 Hz vs 2 Hz. ;) Der erreichbare absolute Takt ist natürlich für die Performance am Ende ebenso wichtig, aber dafür hat man einen stark abnehmenden Grenznutzen. Zen @4,3 GHz mit OC würde bei Haswell IPC alles stemmen können was man ihm entgegen wirft, nur halt in den Tabellen nicht an der Spitze - und da muss AMD mit seinem Preis ansetzen und bestechen.

Bisher konnte AMD sich stets selber manipulieren, von daher muss ich mich zusammenreißen und was schlechtes erwarten. :D

[S940]

Haswell sollte man erreichen. Zen kann pro Takt 10 mOps dispatchen(!).

Ne, nach dem Dispatch sind das dann µOps ;) Reicht aber völlig aus, als Input kommen ja max. nur 6 Mops.

Man hat zwar nur zwei LD/ST-Units, aber der FPU-Teil besitzt auch eine 128b Store-Pipe.

Zen ist eine unglaublich flache Architektur. Straight-forward, Clean-Sheet und sehr breit. Der ALU-Teil ist eher an K8 angelehnt, während die AGU/LD/ST eher nach Bulldozer aussieht. Der FPU-Teil sieht irgendwie wie eine Mischung aus Baumaschine und Wildkatze aus. Die Wildkatzen hatten eine mehrstufige Dekodierung mit dedizierten Integer und FP-Decodern. Das gibt es bei Zen nicht. Zens FPU sieht eher wie eine Baumaschinen-FPU mit Wildkatzen-Units aus.
Da geh ich überall mit, die FPU könnte die FMA-Pipe BDs haben und ADD/MUL von Cat, aber man kennt halt die Latenzen der Befehle noch nicht, da könnte AMD noch was gedreht haben. Ich denke, dass Zen da nicht so pfeilschnell sein wird, da man alle ALU doppelt vorhält. Grund könnte sein schlechtere Latenzen auszugleichen. Wenn z.B. ein ADD 2 Takte braucht, wie in der BD-FPU, dann ist das kein so großer Beinbruch, wenn man 2 Pipes davon hat, die sich dann (bei nur einem Thread) abwechseln können und Ergebnisse jeden Takt ausspucken.
Aber es wird auch Code geben, der mal 2 Adds gleichzeitig berechnen würde, da muss man einfach von App zu App schauen und auch das drumherum der OoO-Puffer in Betracht ziehen.
Erhofft sich ernsthaft jemand einen IPC-Level von Zen zwischen Nehalem und Sandy Bridge?? :confused:
Das wäre für mich persönlich der worst case, denn dann wäre Zen für jeden, der eine Sandy Bridge CPU oder ein neueres Modell benutzt, in keinster Weise relevant oder interessant.
Die Schätzung ist das Minimum ;) Nach oben ist die Skala natürlich offen.

a) Für Sandy-IPC spricht der µOp-Puffer
b) Für Nehalem sprechen die kleineren 128 bit FPUs (auch wenns mehr davon gibt, wer weiss schon ob Software die auch ausnutzen würde)

c) Und für nach oben offen sprechen die breitere Architektur, der größere L1I-Cache und die Queues die ca. auf Haswell-Niveau liegen.

Aber Punkt c) ist dann der oben genannte Effekt, dass man abwarten muss wie die Effekte pro Software sind, das ist also am schlechtesten zu prognostizieren. a) und b) sind dagegen relativ sicher.

[Zergra]

Das ist auch noch ein Punkt, den ich kritisch sehe.
Ich hoffe, dass das nur fuer die "Standardmodelle" gilt und mit OC auch wesentlich mehr drin ist. ein entsprechend schneller 8C darf ja auch mal gut ueber 100W verbraten. Schlecht waere, wenn der Takt nicht ginge, auch bei deutlich hoeheren Spannungen und Verbrauch. Ansonsten sehe ich das genau wie Hübie
Was Spielt die TDP für eine Rolle ? Die kann man doch im Bios einfach hochschrauben. :confused:

[robbitop]

b) Für Nehalem sprechen die kleineren 128 bit FPUs (auch wenns mehr davon gibt, wer weiss schon ob Software die auch ausnutzen würde)

256bit FPUs bringen doch nur bei AVX2 etwas. Realworld also quasi irrelevant, oder?

[iuno]

Was Spielt die TDP für eine Rolle ? Die kann man doch im Bios einfach hochschrauben. :confused:
Kontext lesen?
Es geht um IPC, Perf/W und max. moeglicher Takt, nicht um die absolute TDP an sich.

[Nakai]

Ne, nach dem Dispatch sind das dann µOps ;) Reicht aber völlig aus, als Input kommen ja max. nur 6 Mops.


Ich schrieb mOps, weil "macro" Ops bei AMD. Intel nennt das µOps.

AMD kann pro Instruktion eben bis zu 2 mOps dekodieren. Intel eben bis zu 4 µOps.
Von diesen mOps kann AMD pro Takt 10 maximal schedulen, weil man eben 10 Ports hat.

Da geh ich überall mit, die FPU könnte die FMA-Pipe BDs haben und ADD/MUL von Cat, aber man kennt halt die Latenzen der Befehle noch nicht, da könnte AMD noch was gedreht haben. Ich denke, dass Zen da nicht so pfeilschnell sein wird, da man alle ALU doppelt vorhält. Grund könnte sein schlechtere Latenzen auszugleichen. Wenn z.B. ein ADD 2 Takte braucht, wie in der BD-FPU, dann ist das kein so großer Beinbruch, wenn man 2 Pipes davon hat, die sich dann (bei nur einem Thread) abwechseln können und Ergebnisse jeden Takt ausspucken.
Aber es wird auch Code geben, der mal 2 Adds gleichzeitig berechnen würde, da muss man einfach von App zu App schauen und auch das drumherum der OoO-Puffer in Betracht ziehen.

Ich bin mir sehr sicher, dass die AMD-Darstellung der FPU stark geschönt wurde. Die Pipes können bestimmt mehr Funktionalitäten übernehmen, welche noch nicht gezeigt wurden.

Mal auf Aigner warten, wenn er Zen in die Finger bekommt. ;)

Zen wird abseits von dem FPU-Teil eben eher auf Haswell liegen, imo. Sobald AVX-256 oder mehr verwendet wird, wird Intel einen Vorteil haben.
Ansonsten kann man mit den kleineren FPUs sehr stark an Resourcen sparen.
Die großen FPUs verschlingen unglaublich an Ressourcen.

[S940]

256bit FPUs bringen doch nur bei AVX2 etwas. Realworld also quasi irrelevant, oder?

Jupp, wenn Deine Welt nicht aus AVX256 besteht ;) Dennoch muss mans in der Abschätzung halt berücksichtigen. Bei irgendwelchen Video De/Encodern war AVX256 - wenn ich mich recht erinnere - ja ganz brauchbar.

Ist man also Video-Enthusiast, dann sollte man eher mit 8 Nehalem-Kernen als mit 8 Sandy-Kernen rechnen. Ist immer noch ne Menge Holz, aber schon deutlich weniger als Haswell.

@Nakai:
Ich schrieb mOps, weil "macro" Ops bei AMD. Intel nennt das µOps.
Schon klar, aber wie lange gibts die Mops in der Pipe? Ich denke nur im Frontend, im Dispatcher werden sie dann in µOps aufgesplittet, dafür spricht eben die größere Bandbreite am Output. Irgendwas muss da passieren, ansonsten hätte man sich die 6+4 Ports auch sparen können.

Beim K10 wurden die MacroOps erst in den Schedulern aufgebrochen, aber da gabs auch noch AGU+ALU-Päärchen mit einem gemeinsamen Scheduler. Nachdem die AGUs nun aber extra sind und jede ALU/AGU einen eigenen Scheduler hat, muss das ebenfalls einen Level höher passieren, da sind wir dann wieder beim Dispatch.

Mal auf Aigner warten, wenn er Zen in die Finger bekommt.
Also die Ilse ist ne Frau, also "sie" nicht "er" und dann bleibt noch die Frage, was sie mit nem Zen anfangen sollte. Irgendeine geheime Wahlkampfstrategie berechnen lassen, um doch noch Seehofer beerben zu können? Na das werd ich mal schnell dem Söder stecken, dass der eine Abwehrstrategie entwerfen kann ;) ;) ;) ;) (Nix für ungut ;))

[HOT]

256bit FPUs bringen doch nur bei AVX2 etwas. Realworld also quasi irrelevant, oder?
Der einzige belastbare Benchmark ist Blender und ausgerechnet der nutzt AVX2, dort ist man auf Augenhöhe zu Broadwell. Das passt nicht so richtig zu euren Einschätzungen finde ich.

[Setsul]

Es ist relativ einfach: Er ist Analyst und wird dafür bezahlt das zu fabrizieren.

Vor 3 Tagen wurde der Artikel veröffentlicht in dem er basierend auf den AotS Benchmarks darauf schließt dass Zen zu langsam ist. Die Benchmarks gibt es jetzt aber schon länger.
Zu der Zeit gab es sogar schon die Blender Benchmarks. Schon da passten die nicht in sein Konzept.
Er ist nur auf die Effizienz eingegangen, Kurfassung: Der 6900K braucht bei 3GHz keine 140W, Zen ist also nicht effizienter als Broadwell-E. Das beide ungefähr gleich schnell waren in Blender wird ignoriert, es geht sofort zurück zu AotS, wo der 6900K schneller sein sollte als ein i5, der schneller war als das Zen ES, Schlussfolgerung Zen ist langsamer und weniger effizient als Broadwell-E.
Dass jede Logik, die von einem Benchmark, das ähnliche Leistung bei ähnlichem Verbrauch zeigt, schlechtere Effizienz folgern kann, kompletter Schwachsinn ist, brauche ich eigentlich nicht zu erwähnen.
Ich nehme mal an dass ihn jetzt viele darauf hingewiesen haben, dass Zen nicht in Blender ähnlich schnell sein kann, wenn es doch angeblich so viel langsamer sein soll.

Wenn er jetzt zugibt, dass er Mist gebaut hat, 2 Tage nach dem ursprünglichen Artikel, es liegt also nicht an neuen Informationen, dass sich die Vorhersage als falsch herausgestellt hätte, dann würde seekingalpha in wohl kaum mehr Artikel über das Thema schreiben lassen und ihn dafür bezahlen.
Also muss man das Ganze irgendwie rechtfertigen.


Und jetzt wird es Zeit für Textbelege. Achtung, das wird lustig.
Am Ende kommt das heraus:
We now have 2 different benchmarks confirming these conclusions: The Ashes of the Singularity benchmark, and the Cinebench R15 benchmark, though the Cinebench R15 reality was rather hidden.
Richtig, wir haben keine Ahnung was dort überhaupt getestet wurde. Selbst wenn man Orochi = FX-81xx als gegeben ansieht, sind Taktraten für beide komplette Spekulation. Er nimmt den worst case, den FX-8100 an.

Aber lassen wir das, kommen wir zu den harten Zahlen:
In the comment section to the article, I also indicated the 2 other benchmarks which could bolster the opposite view. These were:
- The blender rendering shown by AMD, where a Zen-based 8-core CPU finished slightly ahead of what was presumed to be an Intel i7 6900K 8-core CPU underclocked to 3 Ghz.
- And perhaps most importantly, the Cinebench R15 multi-thread benchmark where AMD claimed a 100% gain over a previous AMD generation. Here's the relevant slide:
https://staticseekingalpha.a.ssl.fastly.net/uploads/2016/8/31/1006811-14726479615670774_origin.jpg
Sieht hier jemand eine Beschriftung an der Y-Achse? Also woher kommen die 100%?
Dann kommen viele wunderschöne Rechnungen, basierend auf einer Zahl, die nirgends steht.

Fassen wir zusammen:
-Es wurden 2 unbekannte CPUs verglichen
-mit unbekannten Taktraten
-Zen war schneller, aber die Folie gibt nicht an wieviel
-wenn man sich die ganze Folie ansieht, dann sieht man, dass sie vom Mai ist

Jetzt will er mir erzählen, dass das größeres Gewicht hat ("most importantly"), als das Blender Benchmark:
-mit bekannten CPUs
-mit bekannten Taktraten
-mit messbarem Unterschied (faktisch Gleichstand)
-von diesem August.

Ah ja.


Keine Sorge, ich hab versprochen, dass es lustig wird.
Zum Einstieg:
This discrepancy was based on IPC (76% difference) since frequencies were similar and a 40% improvement in IPC isn't going to cure that. Moreover, a drop in frequency forced by the 8-core nature of the chip will degrade IPC gains.
Niedrigerer Takt = niedrigere IPC
Könnte natürlich nur schlechte Formulierung sein.

On situations needing single-thread performance, even an Intel i5 will remain more competitive than a Summit Ridge chip. The improvement in IPC does allow Summit Ridge (and presumably, the 4-core Zen chips as well) to be competitive on single-thread performance with the Intel i3.
Wir reden also von einem 8C Summit Ridge.
8 Kerne.
Nochmal zum mitschreiben:
The improvement in IPC does allow Summit Ridge (and presumably, the 4-core Zen chips as well) to be competitive on single-thread performance with the Intel i3.
Also ein Zen 8C soll single threaded mit einem i3 mithalten können, aber nicht mit einem i5?
Nehmen wir doch mal sein geliebtes Cinebench R15.
http://www.anandtech.com/bench/CPU/1028
i5-6600: 169
i3-6320: 166,58
i7-6900K: 153

Das ist das absolute Gegenteil eines Problems.

On situations needing multi-thread performance, an Intel i5 won't necessarily be better - but then again, it already wasn't. Yet, an Intel i7 will remain competitive versus the Summit Ridge, and an 8-core Intel chip will still trounce it (though at a significant price difference).
Aha, Zen soll also single threaded fast so schnell sein wie ein i5, aber multi-threaded mit doppelt sovielen Kernen + SMT kaum daran vorbeikommen.


Meine Schlussfolgerung ist: Er hat absolut keine Ahnung.


In Sachen AotS: Wenn man sich den ersten Artikel durchliest muss man entweder lachen oder weinen. http://seekingalpha.com/article/4002864-amd-zen-likely-good-enough
Taktraten, Kerne und SMT werden einfach völlig ignoriert.

Ich meine wenn man das hier zu Grunde legt
http://cdn.wccftech.com/wp-content/uploads/2016/08/AMD-Zen-ES-AotS-Benchmarks.jpg
http://core0.staticworld.net/images/article/2016/02/dx12_cpu_ashes_of_the_singularity_beta_2_average_cpu_frame_rate_high_quality_19x 10-100647718-orig.png
Dann kommt man auf 82-84% der IPC von Haswell, also knapp unter Sandy Bridge.
Das kann natürlich noch an vielen anderen Dingen liegen, zum Beispiel dass Windows falsch scheduled bezüglich SMT. Nicht gerade unwahrscheinlich, wenn man sich zurückerinnert.

Zufälligerweise kommt er am Ende auf den gleichen Schluss (Zen < Sandy Bridge IPC), aber wohl nur durch Glück.
Er hat einfach bei den Benchmarks nach den entsprechenden CPUs gesucht (man sieht an den Screenshots die vielen unterschiedlichen User) und dann die Ergebnisse direkt übernommen.

Es gibt nur ein klitzekleines Problem dabei: Da stehen nur die Standardtaktraten, nicht mit was die CPU tatsächlich lief. Beim 6700K ist es natürlich schwerer zu vergleichen wegen des hohen Basistaktes / niedrigen Turbos und SMT, aber es sind auch mindestens 2 (Basis) bis 12% (Turbo) zuviel.
Wenn man annimmt, dass der i5-6500 nicht übertaktet war, lässt es sich wunderschön ausrechnen, dass der i5-6600K 14-15% schneller ist, als er sein dürfte, wenn er perfekt linear mit dem Takt skaliert. Nachdem beide ansonsten identisch sind, kann es aber nur der Takt sein.
Logische Schlussfolgerung: Er hatte doch Recht, IPC geht mit dem Takt Hand in Hand! Das bedeutet auch, dass der i7-6700K single threaded nicht 7% schneller ist als der i5-6600K, wie uns Takt und Benchmarks weismachen wollen, sondern eigentlich 20%!

Es liegt definitiv NICHT daran, dass der i5-6600K mit irgendwas jenseits der 4.5 GHz lief.

Jetzt mal im Ernst: Er kann anscheinend eine Suchfunktion und einen Taschenrechner benutzen, hat aber keine Ahnung was die Zahlen bedeuten.

[Rabiata]

a) Für Sandy-IPC spricht der µOp-Puffer
b) Für Nehalem sprechen die kleineren 128 bit FPUs (auch wenns mehr davon gibt, wer weiss schon ob Software die auch ausnutzen würde)

c) Und für nach oben offen sprechen die breitere Architektur, der größere L1I-Cache und die Queues die ca. auf Haswell-Niveau liegen.

Aber Punkt c) ist dann der oben genannte Effekt, dass man abwarten muss wie die Effekte pro Software sind, das ist also am schlechtesten zu prognostizieren. a) und b) sind dagegen relativ sicher.
Als Indiz für mehr IPC gibt es die AMD Blender-Demo, bei der offenbar Broadwell-Niveau erreicht wurde. Ist zwar nur ein Benchmark, möglicherweise mit Cherrypicking seitens AMD, aber klingt schon vielversprechend.

[MR2]

Ok. Danke��

[N0Thing]

Niedrigerer Takt = niedrigere IPC
Könnte natürlich nur schlechte Formulierung sein.

Niedrigerer Takt = niedrigere IPC hat er nicht geschrieben, sondern dass sich die Zugewinne bei der Performance, welche durch die höhere IPC erreicht wurden, durch einen niedrigeren Takt vermindern.
Ist ja auch logisch, weniger Takt bedeutet weniger Leistung bei gleicher IPC.

Aber das ändert nichts an seinen seltsamen Schlussfolgerungen. ;)

[S940]

Der einzige belastbare Benchmark ist Blender und ausgerechnet der nutzt AVX2, dort ist man auf Augenhöhe zu Broadwell. Das passt nicht so richtig zu euren Einschätzungen finde ich.

Tja da gibts dann 2 Erklärungsmöglichkeiten:

a) Es kommen nur wenige 256 bit Instruktionen, die die AMD-FPU problemlos in 128bit Häppchen verarbeiten kann.

b) Es kommen zuviel 256 bit Instruktionen, aufgrunddessen der Intel runtertaktet und/oder ein anderer Flaschenhals in der Intel-Architektur auftritt, z.B. L1I-Cachegröße.

[Hübie]

Woher kommt plötzlich die Info, der Broadwell-E lief nur mit 3 GHz? Klar takten die Dinger bei AVX2 herunter, aber doch erst wenn Temp XY erreicht ist oder?
Ich hab den Link zu seekingalpha jetzt mal nicht angeklickt, weil da offenbar viel Schrott steht. Dachte die Seite gehöre zu der gehobenen Klassifizierung..:confused:

[Schaffe89]

Von K12 hat man AFAIK lange nichts mehr gehört. Ob der auch unter die Räder gekommen ist?

Nachdem sie Sykbridge schon gecancelt haben war es eigentlich nur noch eine Frage der Zeit bis es K12 komplett erwischt. Der ARM Markt ist viel zu stark umkämpft und es gibt dort viel zu geringe Margen zu erwirtschaften.
Ich denke das Projekt wurde genau dann ins Leben gerufen als AMD verkündet hat, man wolle leistungsmäßig nicht mehr mit Intel konkurrieren, was natürlich völliger Blödsinn war.
Was ist eigentlich mit HSA und Zen+ GCN5.0?

[Timbaloo]

Woher kommt plötzlich die Info, der Broadwell-E lief nur mit 3 GHz? Klar takten die Dinger bei AVX2 herunter, aber doch erst wenn Temp XY erreicht ist oder?
Die 3GHz kommen von AMD. Und das nicht plötzlich sondern direkt bei der Vorstellung der Blender Benchmarks.

[fondness]

Nachdem sie Sykbridge schon gecancelt haben war es eigentlich nur noch eine Frage der Zeit bis es K12 komplett erwischt. Der ARM Markt ist viel zu stark umkämpft und es gibt dort viel zu geringe Margen zu erwirtschaften.

Es gibt nichts vergleichbares zu K12 am ARM-Markt. Das Ding wäre definitiv King of the Hill. Allerdings ist das auch das Problem, es gibt keinen Markt für das Ding. Im Servermarkt konnte sich ARM entgegen den Erwartungen nämlich nicht durchsetzen. Ich gehe auch davon aus, dass K12 wenn überhaupt nur sehr spät kommt.

[Tesseract]

256bit FPUs bringen doch nur bei AVX2 etwas. Realworld also quasi irrelevant, oder?

AVX1 ist das ganze 256bit-float-zeug, AVX2 hat dann zusätzlich 256bit-int + einige zusatzfunktionen wie gather.

Klar takten die Dinger bei AVX2 herunter, aber doch erst wenn Temp XY erreicht ist oder?

temp oder power limit. SIMD ist pro verarbeitetem wert aber energieeffizinter, d.h. wenn eine CPU bei SIMD runtertaktet ist der durchsatz wohl schon wesentlich höher als das maximum was der core skalar jemals erreichen könnte.

[HOT]

Woher kommt plötzlich die Info, der Broadwell-E lief nur mit 3 GHz? Klar takten die Dinger bei AVX2 herunter, aber doch erst wenn Temp XY erreicht ist oder?
Ich hab den Link zu seekingalpha jetzt mal nicht angeklickt, weil da offenbar viel Schrott steht. Dachte die Seite gehöre zu der gehobenen Klassifizierung..:confused:
Braodwell taktet wie Haswell herunter. Aber ausgerechnet Broadwell-E taktet ja bei AVX2-Last deutlich feingranularer und bietet somit erheblich bessere AVX2-Leistung als die vorigen Intel-CPUs. Und genau dagegen hält SummitRidge. Find ich jetzt schon ziemlich krass.

Tja da gibts dann 2 Erklärungsmöglichkeiten:

a) Es kommen nur wenige 256 bit Instruktionen, die die AMD-FPU problemlos in 128bit Häppchen verarbeiten kann.

b) Es kommen zuviel 256 bit Instruktionen, aufgrunddessen der Intel runtertaktet und/oder ein anderer Flaschenhals in der Intel-Architektur auftritt, z.B. L1I-Cachegröße.

a.) wär für AMD kein Problem, da das sowieso eher der Fall ist bei anderer Software, aber irgendwie bezweifel ich das.
und bei b.) würd ich auch sagen jo, nur dummerweise ist es ausgerechnet Broadwell-E mit seinen AVX2-Verbesserungen...

[robbitop]

Der einzige belastbare Benchmark ist Blender und ausgerechnet der nutzt AVX2, dort ist man auf Augenhöhe zu Broadwell. Das passt nicht so richtig zu euren Einschätzungen finde ich.
Was ich so gelesen habe, ist, dass alle Welt vermutet (da Open Source), dass man es auf beiden Plattformen mit 128bit Instruktionen laufen lassen hat. Alles andere wäre super merkwürdig, wenn man bei gleicher Kernzahl, gleichem Takt und halber FPU Breite gleich schnell wäre. Liegt IMO auf der Hand.

[HOT]

Nach dem Abdanken von Read hat Su eigentlich ganz schön an ihren Vorgängern orientiert, den ganzen Experimentalscheiss weggeworfen, die Katzen-Entwicklung minimiert und Zen-CPU und 14nm-GCN sowie deren Kernsoftware forciert.
Kann schon sein, dass K12 ebenfalls Geschichte ist. Auf jeden Fall aber wird man das Teil verzögern, bis man wieder etwas mehr Luft hat. Skybridge und sowas war natürlich Humbug, das hab ich ja von Anfang an in Frage gestellt den Unsinn.
Und noch einen Strategiewechsel gab es: Nachdem AMD mehr als ein Jahrzehnt Prophet gespielt hat und versucht hat möglichst zukunftssicher zu sein mit den Architekturen hat man diese Vorgehen auch über Bord geworfen. Zen ist exakt auf die damaligen Anforderungen optimiert, das nehme ich denen ab. Das wird mMn auch bei Navi der Fall sein. Wenn man sich das CMT-Projekt anschaut, dass man über 10 Jahre vor sich hergeschleppt hat bis man es im Epic-Fail dann realisierte und wenn man sich anschaut, dass GCN vor allem mit den neuen APIs wirklich effizient ist und mit DX11 eigentlich schwer unterfordert ist...

[HOT]

Was ich so gelesen habe, ist, dass alle Welt vermutet (da Open Source), dass man es auf beiden Plattformen mit 128bit Instruktionen laufen lassen hat. Alles andere wäre super merkwürdig, wenn man bei gleicher Kernzahl, gleichem Takt und halber FPU Breite gleich schnell wäre. Liegt IMO auf der Hand.
... es sei denn, Broadwell ist da eben doch nicht so effizient wie gedacht.

[S940]

Naja das ließe sich einfach nachprüfen, schließlich können wir einfach selbst benchen.

Blender gibts hier:
https://www.blender.org/download/

Nen Benchmark mit BWM hier:
http://blenchmark.com/article/benchmark-your-cpu-or-gpu

Ich hab nen Nehalem, den kann ich mal fest ohne Turbogedöns auf 3 oder 4 GHz laufen lassen. Dann vergleichen wir mit Sandy/Haswell/Skylake, sollten sich hier ja finden lassen, oder?

Wenn mein Nehalem gut mithalten kann, wüssten wir, dass es nicht viel AVX gibt. Wenn die Sandys davonrennen, dass es entweder viel gibt, wenns moderat schneller ist, dann dürfte es der µOp-Cache sein.

[Timbaloo]

Interessant wäre da evtl auch wie gut SMT auf intel bei Blender funzt, da es ja schon ein paar Stimmen gab die prognostizierten, dass Zen bei SMT stärker profitieren könnte.

[Setsul]

Ist man also Video-Enthusiast, dann sollte man eher mit 8 Nehalem-Kernen als mit 8 Sandy-Kernen rechnen. Ist immer noch ne Menge Holz, aber schon deutlich weniger als Haswell.
Sandy schafft doch nur 256b pro Takt.
Nehalem 128b?
Also bei über 75% der IPC*Takt von Sandy wäre es näher Sandy als an Nehalem.
In AotS waren es nach meiner Rechnung 82-84% der IPC von Haswell, nur knapp unter Sandy. Also keine Panik.
Trotzdem wäre knapp unter Sandy natürlich enttäuschend, bei 40% über Excavator sollte ungefähr Haswell das IPC Ziel sein, aber mit niedrigerem Takt.


Niedrigerer Takt = niedrigere IPC hat er nicht geschrieben, sondern dass sich die Zugewinne bei der Performance, welche durch die höhere IPC erreicht wurden, durch einen niedrigeren Takt vermindern.
Ist ja auch logisch, weniger Takt bedeutet weniger Leistung bei gleicher IPC.

Aber das ändert nichts an seinen seltsamen Schlussfolgerungen. ;)
"degrades IPC gains"
Vielleicht übersetze ich das falsch, aber normalerweise heißt das "reduziert/verschlechtert". Ansonsten hätte man eher "offsets" ~ "gleicht aus" oder ähnliches geschrieben.
Vom restlichen technischen Niveau traue ich ihm das wirklich zu.



@Rest:
Ich schaue mal ob ich den AVX Anteil im Blender Benchmark herausfinden kann.

EDIT: S940 hat ne ähnliche Idee, ich poste dann mal "bald" Ergebnisse von Haswell, könnten ja nützlich sein.

[HOT]

Gibts die echten 256Bit AVX2 nicht erst ab Haswell? Sandy hat doch nur 128Bit AVX oder? Und Nehalem hat gar kein AVX sondern nur SSE4.2...

[S940]

Ich hab mal den BlenderBench mit dem BMW laufen lassen, Hintergrundapps zugemüllt, alles mögliche offen, Ergebnis 3:43 Minuten.

Takt: 4 GHz Core / 3,6 GHz Uncore

Ginge frisch nach dem Windowsstart vermutlich noch etwas schneller, aber ich muss jetzt erstmal weg. Installieren geht problemlos, also Freiwillige vor.

[S940]

Gibts die echten 256Bit AVX2 nicht erst ab Haswell? Sandy hat doch nur 128Bit AVX oder? Und Nehalem hat gar kein AVX sondern nur SSE4.2...

Jupp, Sandy hat ne 256bit AVX FPU, muss die Daten dafür aber in 2 Takten ranschaufeln. Haswell schafft das in einem.

Von daher wärs interessiert, wieweit Haswell und Sandy auseinanderliegen.

Falls auch noch AVX2-Code ausgeführt werden würde, würde das das Ergebnis natürlich verfälschen, aber naja ... probieren kann mans mal.

Welcher Complier wird für die Windows Binaries eigentlich verwendet? Nachdem das ne OpenSource-Sache ist, nehm ich an GCC?

[S940]

Doch nochmal schnell neu gestartet, biete nun 3:35 Minuten.

[N0Thing]

"degrades IPC gains"
Vielleicht übersetze ich das falsch, aber normalerweise heißt das "reduziert/verschlechtert". Ansonsten hätte man eher "offsets" ~ "gleicht aus" oder ähnliches geschrieben.
Vom restlichen technischen Niveau traue ich ihm das wirklich zu.

Ja, das ist die übliche Übersetzung und da es um die IPC gains geht und nicht um die IPC, spricht er nicht von einer Reduzierung der IPC bei geringerem Takt, sondern von geringerer Performancesteigerung trotz besserer IPC, weil der Takt zu niedrig sei.

Spielt für den Rest aber wie gesagt auch keine Rolle. Ich hätte das im Englischen auch anders formuliert.

[iuno]

SMT bringt bei Blender afair sehr viel.

Man koennnte auch mal mit und ohne avx2 durchbauen und dann messen.
Edit: ich teste das mal...


Welcher Complier wird für die Windows Binaries eigentlich verwendet? Nachdem das ne OpenSource-Sache ist, nehm ich an GCC?
Nein, die offiziellen builds verwenden nicht GCC, sondern den msvc compiler - obwohl die GCC builds idR schneller waren, zumindest vor einiger Zeit noch. Für Linux geht sowohl gcc als auch llvm.

Wenn man Blender Benchmarks macht bitte dran denken die tile size auf 16*16 zu setzen, das macht bei CPUs am meisten Sinn.

[Setsul]

EDIT: @Nothing: Ja aber die IPC Zugewinne sind nicht kleiner geworden, deshalb Verwirrung.

Schneller Test ergab
5.504,45 Mrd. µops retired
23,67 Mrd. AVX

[iuno]

Hab wie oben gesagt mal ohne avx2 Unterstuetzung gebaut. Man merkt es schon, es ist aber nicht die Welt (~5%).

build|run 1|run 2
avx2|2:41.73|2:42.67
avx|2:49.58|2:49.71


Skylake, 4C/8T, 4,0 GHz
Der bekannte BMW-Test (bmw27)

[Setsul]

Also wenn Zen trotz AVX2 2% schneller ist als Broadwell-E dann wäre das schon enorm.
Blender wird der best case sein, sonst hätte uns AMD das nicht gezeigt, aber es verspricht schon Gutes, egal ob es AVX oder AVX2 ist.

[iuno]

Das sind aber ja nun eher Nuancen, SMT bringt afair dagegen sehr viel. Ich kann daher mit der SMT Theorie auch noch am meisten anfangen.
Wer Lust und Zeit hat, kann ja mal mit und ohne HT messen. Wie gesagt: tile size bitte auf 16*16 und wenn moeglich mehrere Durchlaeufe, falls es Ausreisser gibt.

[Skysnake]

Was vor allem viele vollkommen ignorieren ist die TDP. AMD gibt für den 8 Kerner nur 95W an. Wenn man damit Haswell IPC bei ~3,5Ghz erreichen würde, wäre die Perf/Watt deutlich über Intel. Das ist schon alleine angesichts der Fertigungsnachteils kaum realistisch.
[quote]
Mit der Effizienz steht und fällt ZEN. Wenn Zen da wirklich besser sein sollte als Intel, dann kann das Ding ein richtig fetter Erfolg werden, selbst wenn die absolute Leistung etwas niedriger sein sollte als mit Broadwell. Das interessiert an sich nicht. Nimmt man halt mehr Kerne. Also insbesondere für HPC. Allerdings bin ich da etwas skeptisch wegen der nur 128Bit FPU.

[quote]
Das ist natürlich korrekt. Allerings macht es auch keinen Sinn, mehr Ausführungseinheiten zu verbauen, als man füttern kann, denn das kostet nr unnötig Strom. Deshalb sagen solche Dinge häufig schon etwas über die IPC aus.
Ja kann man erwarten, allerdings würde ich bei AMD keien Pfifferling darauf verwetten... Die haben es einfach schon ZU oft verkackt. AMD glaube ich apriori erstmal nicht wirklich mehr viel. Fakten müssen her.

Was Spielt die TDP für eine Rolle ? Die kann man doch im Bios einfach hochschrauben. :confused:
Ja, aber die TDP gibt an, wie das Ding @default läuft, und so laufen sicherlich 99,99xx% aller CPUs. Das ist also die wichtige Metrik, zumal OC immer auch zumindest teilweise etwas mit Glück zu tun hat. Ach und btw. wenns unten effizient ist, hat man viel Luft bis man wirklich ineffizient ist ;)

256bit FPUs bringen doch nur bei AVX2 etwas. Realworld also quasi irrelevant, oder?
Kommt darauf an. ZEN soll ja auch sehr stark im Serverbereich und HPC wildern. HPC seh ich damit etwas kritisch.

Woher kommt plötzlich die Info, der Broadwell-E lief nur mit 3 GHz? Klar takten die Dinger bei AVX2 herunter, aber doch erst wenn Temp XY erreicht ist oder?
Ich hab den Link zu seekingalpha jetzt mal nicht angeklickt, weil da offenbar viel Schrott steht. Dachte die Seite gehöre zu der gehobenen Klassifizierung..:confused:
Wenn ich es richtig im Kopf habe, dann sollte das bei Broadwell-E nicht zwingend so sein. Es gibt da so eine lustige Tablelle mit den Taktraten bezüglich AVX und Last auf den Kernen. Das ist erstmal unabhängig vom Power/Temp limit.

Wenn du AVX ausführt auf HAswell, takten ALLE! Kerne 400MHz runter. Wenn du aber aktuell in einer Turbostufe bist die mehr als 400MHz über der BaseFrequency liegt, dann haste aber noch immer einen Turbo. Durch AVX verlierst du da aber wie gesagt immer die 400MHz. Bei Broadwell-E ist es dann nur noch der Kern, auf dem auch AVX läuft. Auch sind meines Wissens nach die Latenzen besser geworden, bezüglich dem wieder hochtakten, wenn kein AVX mehr für eine gewisse ZEit aufgeführt wurde. Das war/ist bei Haswell wohl ziemlich grottig. Warum man schon einiges an AVX2 Code auf ALLEN! Cores ausführen muss. Sonst ist man durch den recht lange reduzierten Takt unterm Strich doch langsamer als ohne. Davon wissen leider die Compilr wohl nichts. Ist zumindest mein Eindruck

AVX1 ist das ganze 256bit-float-zeug, AVX2 hat dann zusätzlich 256bit-int + einige zusatzfunktionen wie gather.

temp oder power limit. SIMD ist pro verarbeitetem wert aber energieeffizinter, d.h. wenn eine CPU bei SIMD runtertaktet ist der durchsatz wohl schon wesentlich höher als das maximum was der core skalar jemals erreichen könnte.
Jup, der Durchsatz sollte dennoch höher sein. Bei HAswell war eben das lange FEnster des niedrigen Takts selbst bei wenigen instructionen auf einerm Core (genaues weiß man nicht bezüglich wieviele Instructionen) hat aber weh getan. DAs ist mit Broadwell-E sehr sehr sehr viel besser geworden.

Jupp, Sandy hat ne 256bit AVX FPU, muss die Daten dafür aber in 2 Takten ranschaufeln. Haswell schafft das in einem.

Von daher wärs interessiert, wieweit Haswell und Sandy auseinanderliegen.

Falls auch noch AVX2-Code ausgeführt werden würde, würde das das Ergebnis natürlich verfälschen, aber naja ... probieren kann mans mal.

Jup, kommt halt darauf an, wie lange man die Werte in den Registern halten kann und währenddessen schon mal neue Werte prefetchen kann.

Ich finde so ein design aber prinzipiell eher hässlich. Wenn ich so breite FPUs habe, dann sollen die Datenpfade auch so breit sein. Allers andere führt nur zu Knoten im Hirn :freak:


Welcher Complier wird für die Windows Binaries eigentlich verwendet? Nachdem das ne OpenSource-Sache ist, nehm ich an GCC?
Keine Ahnung, hatte sogar ganz vergessen, dass das OpenSource ist.

Wenn du mir Link und ein akzeptables Makefile hast, dann könnte ich das eventuell mal für nen Haswell 12C mit GCC und ICC bauen. Jeweils eben mit und ohne AVX für Linux. Sooo viel Zeit habe ich aber nicht, daher wäre es schon gut, wenn das ohne Aufwand schnell machbar wäre.

SMT bringt bei Blender afair sehr viel.

Man koennnte auch mal mit und ohne avx2 durchbauen und dann messen.
Edit: ich teste das mal...


Nein, die offiziellen builds verwenden nicht GCC, sondern den msvc compiler - obwohl die GCC builds idR schneller waren, zumindest vor einiger Zeit noch. Für Linux geht sowohl gcc als auch llvm.

Wenn man Blender Benchmarks macht bitte dran denken die tile size auf 16*16 zu setzen, das macht bei CPUs am meisten Sinn.
Wie gesagt, einfach mal ne config schicken ;)

EDIT:

Ach und für die Leute die Linux benutzen und das Ding selbst bauen.

Schaut euch einfach mal Scorep+PAPI an und für die Auswertung noch Scalasca. Das sind alles drei Freeware/Opensource Tools, mit denen ihr euch anzeigen lassen könnt wieviele Instructionen pro Funktion aufgerufen wurden, und auch ob das dann AVX verwendet etc. Verwende ich sehr viel auf der Arbeit, allerdings mit HAswell, der KEINEN support hat um AVX Instruktionen zu erkennen die ausgeführt werden.... :kotz::down:

[Setsul]

@iuno: Es geht eben genau darum, dass es nur Nuancen sind. Wenn 2x128b statt 2x256b kaum spürbar sind in der Praxis, wäre damit schonmal ein Teil der Bedenken ausgeräumt.
Die Frage ist auch nicht wie viel SMT bringt, sondern wie viel es auf breiteren Architekturen bringt. Man müsste z.B. Sandy und Haswell vergleichen.

@Skysnake:
Für HPC gäbe es noch das APU Ding. Alles was sich so gut vektorisieren lässt, dass der Unterschied groß wird, dürfte sich auf die GPU auslagern lassen. Dann wäre das eher noch ein Vorteil.

[Skysnake]

Es gibt nichts vergleichbares zu K12 am ARM-Markt. Das Ding wäre definitiv King of the Hill. Allerdings ist das auch das Problem, es gibt keinen Markt für das Ding. Im Servermarkt könnte sich ARM entgegen den Erwartungen nämlich nicht durchsetzen. Ich gehe auch davon aus, dass K12 wenn überhaupt nur sehr spät kommt.
NAja, die ARM Kisten sind wohl auch alle ziemlich bescheiden bei der Nutzung ihrer MEmory Controller, sprich es kommt einfach zu wenig Bandbreite real an. Latenzen wohl das Selbe in Grün.

AMD würde man da schon zutrauen das richtig zu machen. Vielleicht haben Sie aber auch einfach rechtzeitig von der Entwicklung bei ARM Wind bekommen bezüglich den Vectorerweiterungen und einen "kleinen" Reset gemacht beim Design. Wäre wohl durchaus sinnvoll. Ich würde daher mal K12 noch 6-12 Monate geben. Erst wenn dann nichts kommt ist das Ding tot.

[iuno]

Wenn du mir Link und ein akzeptables Makefile hast, dann könnte ich das eventuell mal für nen Haswell 12C mit GCC und ICC bauen. Jeweils eben mit und ohne AVX für Linux. Sooo viel Zeit habe ich aber nicht, daher wäre es schon gut, wenn das ohne Aufwand schnell machbar wäre.


Wie gesagt, einfach mal ne config schicken ;)

EDIT:

Ach und für die Leute die Linux benutzen und das Ding selbst bauen.

Schaut euch einfach mal Scorep+PAPI an und für die Auswertung noch Scalasca. [...]
Win? https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake
Linux? https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Generic_Distro/CMake
Abhaengigkeiten installieren (Pakete sind nach Distributionen entsprechend im Wiki aufgelistet: https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux)

https://git.blender.org/blender.git

submodule laden, make ausfuehren (convenience Makefile, dann ueber cmake, aber alles automatisiert, ist auch schnell gebaut). Einfacher geht's fast nicht ;)

edit: ach ja, ich habe einfach in der intern/cycles/CMakeLists.txt die Ueberpruefung auf avx2 raus genommen und
CXX_HAS_AVX2 FALSE
gesetzt

Das Demo file gibts hier: https://developer.blender.org/F280042
Kachelgroesse einstellen: wenn man die Datei mit Blender oeffnet, rechts ueber der Textbox unter dem Reiter "Performance" bei Tiles steht Center, X:960, Y:540. Bei beiden Zahlenfeldern 16 eintragen.

zum Unteren: schaue ich mir bei Gelegenheit mal an ;)

[Rabiata]

Woher kommt plötzlich die Info, der Broadwell-E lief nur mit 3 GHz? Klar takten die Dinger bei AVX2 herunter, aber doch erst wenn Temp XY erreicht ist oder?
Ich hab den Link zu seekingalpha jetzt mal nicht angeklickt, weil da offenbar viel Schrott steht. Dachte die Seite gehöre zu der gehobenen Klassifizierung..:confused:
Wenn ich den Kommentar zur Zen-Demo richtig verstehe, hat AMD den Broadwell-E auf 3 GHz heruntergetaktet um einen Vergleich bei gleichem Takt zu haben (das Zen Engineering Sample konnte wohl nur 3 GHz). Das könnte man als Manipulation kritisieren, da der Broadwell-E normalerweise 3,2 GHz schafft.

Von SeekingAlpha halte ich jetzt aber auch nicht viel. Das scheint eine Seite für Börsenzocker zu sein, wobei ein erheblicher Teil der Artikel eher Propaganda als seriöse Info ist.

[Rabiata]

NAja, die ARM Kisten sind wohl auch alle ziemlich bescheiden bei der Nutzung ihrer MEmory Controller, sprich es kommt einfach zu wenig Bandbreite real an. Latenzen wohl das Selbe in Grün.

AMD würde man da schon zutrauen das richtig zu machen. Vielleicht haben Sie aber auch einfach rechtzeitig von der Entwicklung bei ARM Wind bekommen bezüglich den Vectorerweiterungen und einen "kleinen" Reset gemacht beim Design. Wäre wohl durchaus sinnvoll. Ich würde daher mal K12 noch 6-12 Monate geben. Erst wenn dann nichts kommt ist das Ding tot.
Die Frage ist auch welche Software drauf laufen soll. Die meiste Serversoftware gibt es sicherlich schon in x86, also hat K12 da keinen Vorteil und müßte über die Kosten- und/oder Energieeffizienz punkten.

Mit anderen Worten, K12 müßte Broadwell und demnächst auch Zen in Performance/Watt oder Performance/Dollar schlagen. Wenn das nicht drin ist, hat K12 keine Daseinsberechtigung.

[Oromis16]

Im Changelog von Blender 2.72/2.73 steht, dass AVX2 nur einstellige Prozentverbesserungen gebracht hat (Entwickler: Thomas Dinges, Haswell).
Kann also durchaus sein, dass AMD das drinnen gelassen hat um später nicht dafür zerrissen zu werden.

Das mit der Benachteiligung durch die halbierte Speicherbandbreite des Broadwell-E ist mMn auch Mist, in der Szene sah man eine einzige Textur und weit unter einer Million Vertices.

[Skysnake]

Win? https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake
Linux? https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Generic_Distro/CMake
Abhaengigkeiten installieren (Pakete sind nach Distributionen entsprechend im Wiki aufgelistet: https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux)

https://git.blender.org/blender.git

submodule laden, make ausfuehren (convenience Makefile, dann ueber cmake, aber alles automatisiert, ist auch schnell gebaut). Einfacher geht's fast nicht ;)

edit: ach ja, ich habe einfach in der intern/cycles/CMakeLists.txt die Ueberpruefung auf avx2 raus genommen und
CXX_HAS_AVX2 FALSE
gesetzt

Das Demo file gibts hier: https://developer.blender.org/F280042
Kachelgroesse einstellen: wenn man die Datei mit Blender oeffnet, rechts ueber der Textbox unter dem Reiter "Performance" bei Tiles steht Center, X:960, Y:540. Bei beiden Zahlenfeldern 16 eintragen.

zum Unteren: schaue ich mir bei Gelegenheit mal an ;)
Mäh, das kannste vergessen. Ich hätte es halt mal kurz auf nem Cluster-Node laufen lassen, aber die dependencies bekomme ich da nicht installiert....

[Tesseract]

Wenn du AVX ausführt auf HAswell, takten ALLE! Kerne 400MHz runter.

das betrifft doch nur bestimmte xeon-modelle soweit ich weiß. die consumer-serien werden natürlich trotzdem meist runtertakten weil das power limit schnell mal erreicht ist, aber bei den K-modellen hab ich sowas noch nie gesehen.

[iuno]

Im Changelog von Blender 2.72/2.73 steht, dass AVX2 nur einstellige Prozentverbesserungen gebracht hat (Entwickler: Thomas Dinges, Haswell).
Kann ich ja in dem Fall bestaetigen.
Quelle:
https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Cycles
commit: https://developer.blender.org/rB866c7fb6e63d
This kernel is compiled with AVX2, FMA3, and BMI compiler flags. At the moment only Intel Haswell benefits from this, but future AMD CPUs will have these instructions as well.

@Skysnake: schade :(

[S940]

Hab wie oben gesagt mal ohne avx2 Unterstuetzung gebaut. Man merkt es schon, es ist aber nicht die Welt (~5%).

build|run 1|run 2
avx2|2:41.73|2:42.67
avx|2:49.58|2:49.71


Skylake, 4C/8T, 4,0 GHz
Der bekannte BMW-Test (bmw27)

Ach ans Selbstbauen dachte ich gar nicht. Wenn das sowieso so einfach ist, dann bau doch bitte auch noch ne Version mit maximal SSE4.2, also als Zielplattform Nehalem.
(Und wenn Du lustig bist und es geht auch noch ne Version mit AVX128, das gibts bei einigen Compilern für Bulldozer, hat ggü. SSE den Vorteil der kürzeren Befehle, entlastet den I-Cache, keine Ahnung obs was bringt, aber wenn Du zuviel Zeit haben solltest ... ;))

So oder so 128bit Code hätte die höchste Aussagekraft, da wir die Unschärfe des µOp-Caches rausbekommen und Deine BIOS/RAM-Einstellungen garantiert gleich sind.

Ein Haswell mit dem 128 bit-Code dürfte im Groben einen guten Näherungswert für die Zen-Performance liefern. Unterschied wäre nur die Architekturbreite.

Wäre jetzt v.a. spannend, wieviel schlechter Haswell mit dem 128bit Compilat abschneiden würde und ob man der Unterschied in einem Bereich liegt, den man bei Zen als SMT-Vorteil zugestehen könnte.

[iuno]

Ach ans Selbstbauen dachte ich gar nicht. Wenn das sowieso so einfach ist, dann bau doch bitte auch noch ne Version mit maximal SSE4.2, also als Zielplattform Nehalem.
(Und wenn Du lustig bist und es geht auch noch ne Version mit AVX128, das gibts bei einigen Compilern für Bulldozer, hat ggü. SSE den Vorteil der kürzeren Befehle, entlastet den I-Cache, keine Ahnung obs was bringt, aber wenn Du zuviel Zeit haben solltest ... ;))

So oder so 128bit Code hätte die höchste Aussagekraft, da wir die Unschärfe des µOp-Caches rausbekommen und Deine BIOS/RAM-Einstellungen garantiert gleich sind.

build|run 1|run 2
avx2|2:41.73|2:42.67
avx2 (prefer 128b)|2:46.37|2:44.15
avx|2:49.58|2:49.71
sse|2:58.08|2:57.59


Ist also nochmal etwa derselbe Schritt, etwas groesser.
Bin auch kein Experte. Ich habe halt AVX2 (256-Bit?!) und AVX schrittweise beim kompilieren deaktiviert.
Im Zusammenhang von Cycles (dem verwendeten Renderer) wird auch nur SSE4.1, nicht 4.2 benutzt.

edit: okay, habs glaub gefunden. gcc hat noch -mprefer-avx128 ich probiere das gleich mal aus...
edit2: in Tabelle eingefuegt, mit dem prefer 128b Flag ist es etwas langsamer

[S940]

Perfekt, super Danke!!

Naja, was man hier dann sieht, ist ein sehr ernüchterndes Bild. 256 bit bringts bei Blender nicht. Das offeriert gerade mal ein mageren Performancevorteil von ~2%.

Dass das sooo wenig ist, verwundert dann doch etwas. Dagegen ist der Sprung von SSE(128 bit) zu AVX2(128bit) geradezu phänomenal mit ca. 7%. (noch ein extra Danke dafür, hätte nicht gedacht, dass das soviel ausmacht, war jetzt im Nachhinein besehen, sehr interessant)

Die kürzeren AVX-Befehle nutzen also mehr als 256bit, d.h. wir haben eher ein Limit im Front-End.

Unterm Strich ist es dann keine Leistung vorherzusagen, dass eine Architektur mit besserem Frontend (größerem I-Cache) und etwas besserer SMT-Skalierung, die 2% Nachteil locker auf- und überholen dürfte.

Anders gesagt: Blender dürfte Zen sehr gut liegen, was überhaupt nicht verwunderlich wäre, da man Cherry-Picking bei der öffentlichen Vorführung schließlich erwarten durfte. Das unterstützt das Gefunde eher.

Offene Fragen: Ein Haswell mit ICC-Complilat könnte aus Haswell vielleicht noch mehr rausholen, aber in Form eines fairen Vergleiches könnte man AMD keine Vorwürfe machen, wenn sie beiden Architekturen ein GCC-Compilat vorsetzt - zumindest solange der Intel Chip die 256-Bit-Version bekommt.

[Oromis16]

Anders gesagt: Blender dürfte Zen sehr gut liegen, was überhaupt nicht verwunderlich wäre, da man Cherry-Picking bei der öffentlichen Vorführung schließlich erwarten durfte. Das unterstützt das Gefunde eher.

So würde ich's in jedem Fall unterschreiben.

Gab leider ein paar die sich beschwert haben, dass Blender auf AMD optimiert sei - was so rum nicht der Fall ist.

[Unicous]

Ich möchte euch nicht ärgern, aber The Stilt hatte das in ähnlicher Weise schon vor ein paar Tagen durchexerziert


(ab https://forums.anandtech.com/threads/first-summit-ridge-zen-benchmarks.2482739/page-22#post-38431662)


und ist zum selben Ergebnis gekommen.

[Oromis16]

Hab ich selbst auch (http://extreme.pcgameshardware.de/prozessoren/450378-leserbericht-warum-blender-vermutlich-nicht-auf-zen-optimiert-ist.html), aber man übersieht halt schnell mal irgendein winziges Detail - deswegen: Diskutieren bis man den Fehler findet :D

[S940]

Hmm seh ich jetzt nicht so, dass das Gleiche gemacht wurde.

Was ihr und auch Stilt gemacht habt war, einfach 2 unterschiedliche Systeme zu vergleichen, die Hardware variiert also.

Und die Aussage, dass AVX2 nur ein paar Pünktchen verbessere war allein auch nicht aussagekräftig, da sie ggü. AVX1-Code getätigt wurde, der aber ja auch schon 256-Bit breit war. Das war also kein Anhaltspunkt für den Speedup im Vergleich zu SSE oder noch besser zu 128 bit breitem AVX-Code.

Es ist halt was anderes 1 und dasselbe System zu nehmen und nur die Software zu variieren. Iunos Tests sind einige Stufen aussagekräftiger/sicherer, da man Hardwareunterschiede definitiv ausschließen kann und allein der Softwarefaktor ausschlaggebend ist.

Davon ab frag ich mich aber, was da beim Bulldozer abläuft. Laut Stilt bringt CMT NULL Vorteile. Das heißt also, dass bereits ein Thread die FPU voll auslastet und/oder das Front-End dicht macht.

Stilt hatte jetzt nur nen Piledriver, wäre jetzt noch interessant, was ein Steamroller oder Excavator reißen würde, da wurde das Front-End ja deutlich ausgebaut (2 unabhängige Decoder, größerer I-Cache), Excavators größere L1D-Caches könnten ggf. auch noch helfen.
Das schockt mich jetzt schon etwas, auch wenn klar war, dass BD grottig ist/war, aber überhaupt kein Vorteil von CMT ist katastrophal. Bleibt nur der Strohhalm, dass es SR oder XV besser machen würden. Prinzipiell aber auch Schnee von gestern, Zen steht ja vor der Tür.

Edit:
@Oromis:
Was meinst Du hier:
a)Wie unschwer zu erkennen ist liegt AMD in Blender im Vergleich zu anderen Raytracern gegenüber Intel hinten. [Relevant ist der blaue Balken: Je weiter rechts der blaue Balken endet desto besser kommt Intel im Verhältnis zu AMD zurecht] Ich seh bei dem Bild: http://img.tweakpc.de/images/2016/08/23/Benchmarkwerte.png keine Balken. Oder bezieht sich das auf was anderes?

b)So wirdAVX2 beispielsweise wird unterstutzt - eine Erweiterung die Broadwell-E hat, Zen aber nicht
Zen hat sehr wohl AVX2 ;) Wird halt nur in 2 Happen abgearbeitet. Wie wir jetzt wissen ist das aber zumindest bei Blender fast egal. Hauptsache ist, dass die Instruktionen dank VEX-Präfix kompakter sind. Für das Präfix hätte der Intelmitarbeiter/-team, der sich das ausgedacht hat, ne Medaille verdient ;)

Für diejenigen, die es nicht wissen: Alle alten SSE-Befehle gibts auch als AVX-Version mit kürzerem VEX-Präfix. Das zeigt schon, wie wichtig das Intel ist/war. Ist ja auch cool, anstatt den I-Cache vergrößern zu müssen, verkleinert man "einfach" den Code und hat nen ähnlichen Effekt für lau ;)

[iuno]

in der Videoversion sind Balken dabei ;) https://youtu.be/XxS6oJuSkck?t=75
Für diejenigen, die es nicht wissen[...]
nope, aber interessant :up:

[S940]

in der Videoversion sind Balken dabei ;) https://youtu.be/XxS6oJuSkck?t=75


Ahh die Video-Version. Alles klar, merci und gute Nacht :)


Edit:
Hab jetzt doch noch die nächsten Seiten bei Anandtech gelesen und in der Tat hat der Stilt unterschiedliche Compliate mit ohne AVX2 erzeugt. Die hat er auch online gestellt:
https://1drv.ms/u/s!Ag6oE4SOsCmDhEHafXXr3vrRqo-N

Also ja er hat fast das Gleiche gemacht, nur an AVX128 hat er nicht gedacht ;)

Merkwürdig finde ich jetzt noch seine Erkenntnis, dass SMT auf Intel verdammt gut skaliert, fast 60%.
Das passt mit der Aussage, dass CMT überhaupt nicht skaliert eigentlich nicht zusammen.

Eine gute SMT-Skalierung bedeutet generell einen "luftigen" Code, der genug Platz für den 2. Thread in den Rechenwerken lässt. Wieso funktioniert das dann aber nicht auch mit CMT? Zumindest bei Intel sind die FP-Units also nicht ausgelastet und können mehr Arbeit aufnehmen, bei AMD aber nicht. Irgendwas muss bei AMD den Kern komplett dicht machen. Es bleibt eigentlich nur das Front-End übrig. Da muss bei Blender irgendwas gründlich schief laufen.

Falls es der µOp-Cache sein sollte, müsste das SMT-Speedup auf meinem Nehalem deutlich schlechter ausfallen. Ich teste das morgen mal aus.

[Oromis16]

Also bei mir wird das Balkendiagram im Test direkt über der Verlinkung der genauen Benchmarkwerte aufgelistet, bei euch nicht? :eek:

[iuno]

Wenn du es dort im Forum als Anhang hochgeladen hast, koennen nicht angemeldete Nutzer es nicht sehen.

Ich habe jetzt auch mal den Thread auf Anandtech gelesen, The Stilt kommt schon zu anderen Ergebnissen als ich, allerdings hat er auch unter Windows mit dem ICC getestet. Mit Haswell misst er kaum einen Unterschied, selbst wenn AVX komplett aus ist.

Now I made an additional build (57.5MB) with only SSE2, SSE3 and SSE4.1 kernels enabled (CCX_HAS_AVX & CCX_HAS_AVX2 = False).

On Piledriver there was no difference what so ever, and on Haswell the difference pretty much falls withing the margin of error (< 1.5%).
https://forums.anandtech.com/threads/first-summit-ridge-zen-benchmarks.2482739/page-25#post-38443254

[Gipsel]

@iuno: Es geht eben genau darum, dass es nur Nuancen sind. Wenn 2x128b statt 2x256b kaum spürbar sind in der Praxis, wäre damit schonmal ein Teil der Bedenken ausgeräumt.Naja, wie es aussieht sind es ja eher 2x 128bit MUL + 2x 128Bit ADD (die zu 2x 128bit FMAC gebridged werden können) vs. 2x 256bit FMAC. Solange kein FMA benutzt wird sondern getrennte Additionen und Multiplikationen, muß der Durchsatz bei einem halbwegs ausgeglichenem Instruktionsmix gar nicht so weit auseinander liegen. Man halt halt schlicht 4 Pipes statt nur 2 für die arithmetischen Instruktionen. Im worst case hat man natürlich einen Faktor 2 (bzw. sogar noch einen Tick mehr, weil bei Intel ein dritter Port Shuffles und sowas machen kann). Und übrigens dupliziert erst Skylake die vADD- und vMUL- Einheiten sowohl an Port 0 sowie 1 (bis Broadwell gab es zwar 2 FMACS, aber reine Multiplikationen bzw. Additionen gehen ohne Umbiegen auf die FMACs [was Strom und Latenz kostet] nur in jeweils einem Port), also erst dann hat man auch mit reinen Additionen oder Multiplikationen immer mehr Durchsatz als Zen. Und Zen könnte einen mehr oder weniger deutlichen Vorteil bei Code haben, der nur mit 128Bit Vektor-Instruktionen arbeitet. Davon kann der dann nämlich bis zu 4 pro Takt durchziehen, die Intels nur zwei (bis drei inklusive der nichtarithmetischen Operationen).

[iuno]

Ich probiere gerade mit The Stilts Builds rum.
Das laeuft auf Windows erschreckend langsam, selbst die icc builds. Wenn unter Windows eh alles gleich langsam ist (avx,avx2,sse), kann man die ganze Testerei eh vergessen.

edit (der Vollstaendigkeit halber, auch wenn es wohl nichts meher bringt):

Ich hatte nicht erwartet, dass es so gravierend ist. Die Ergebnisse schwanken aber auch viel mehr, man bekommt kaum 2 gleiche runs hin. Ich habe jetzt halt mal jeweils die 2 besten genommen.

build|run 1|run 2
Linux
gcc (avx2)|2:41.73|2:42.67
gcc (avx2, prefer 128b)|2:46.37|2:44.15
gcc (avx)|2:49.58|2:49.71
gcc (sse)|2:58.08|2:57.59
Windows
icc (avx2)|3:38.22|3:38.02
icc (avx)|3:40.49|3:37.89
icc (sse)||
official 2.77a|3:39.19|3:37.44

Mit gcc@Windows habe ich jetzt mal nicht probiert, weil hier nichts eingerichtet ist.
Den sse build von The Stilt kann ich leider nicht testen, weil Onedrive sie "nicht auf Viren ueberpruefen kann" :rolleyes:

[S940]

Ich probiere gerade mit The Stilts Builds rum.
Das laeuft auf Windows erschreckend langsam, selbst die icc builds. Wenn unter Windows eh alles gleich langsam ist (avx,avx2,sse), kann man die ganze Testerei eh vergessen. Ich hatte nicht erwartet, dass es so gravierend ist

Dann teste mal spasseshalber bei Dir bitte noch die Auswirkungen von SMT.
Das klingt jetzt so, das Win irgendwelchen Mist baut, was die IPC senkt und SMT deshalb überproportional gewinnt.

Unter Linux müsstest Du folgerichtig dann anstatt +60% ein deutlich geringeres SMT-Speedup haben.

Wer hätts gedacht, dass es am OS liegt.

Aber solche Späße gibt es auch im BOINC-Bereich. Da gibts manche Apps, die unter Linux deutlich schneller laufen, obwohl laut Entwickler der gleiche Sourcecode zugrunde liegt. Oft ist es dann sogar ausreichend ein Linux-Compilat in einer virtualisierten Umgebung unter Windows laufen zu lassen :freak:

@Oromis16:
Ne ich seh leider nix, ist das irgendwas Animiertes anstatt eines "normalen" Bildlinks? Dachte es wäre vielleicht der Werbeblocker und oder die fehlende Registrierung, aber auch mit Anmeldung und ohne Blocker seh ich nix, möglicherweise fehlt dann da irgendein Skript oder keine Ahnung was. Wenn ichs mit IE aufmache seh ich wenigstens noch ein kleines Halteverbot-Icon, da hab ich die Sicherheitseinstellungen auf höchste Stufe ist also "normal". Aber egal, so wichtig ists ja nicht.

[Skysnake]

Ist halt Windows :ugly:

Hat schon seine Gründe, warum faktisch alle HPC Systeme auf Linux setzen. Und selbst da rühmt sich CRAY ja nochmals eine deutlich besseres Linux Distri zu haben, die schneller ist als ein RedHat oder sonst was. Was ich teilweise auch nachvollziehen kann.

[iuno]

Dann teste mal spasseshalber bei Dir bitte noch die Auswirkungen von SMT.
Das klingt jetzt so, das Win irgendwelchen Mist baut, was die IPC senkt und SMT deshalb überproportional gewinnt.

Unter Linux müsstest Du folgerichtig dann anstatt +60% ein deutlich geringeres SMT-Speedup haben.

Wer hätts gedacht, dass es am OS liegt

Windows builds waren schon immer langsamer, aber so einen großen Unterschied hätte ich auch nicht mehr erwartet. GCC builds waren damals auch auf Windows schneller, aber da habe ich gerade keine Lust, das auch noch auszuprobieren, zumal es lt. Wiki eh kaputt ist. Mich überrascht da aber, dass ICC und msvc sich genau nichts schenken.
Denke nicht dass SMT noch einen großen Unterschied macht, win ist ja insgesamt schon viel langsamer.

@Skysnake: Ja, die "normalen" Distris schleppen aus Kompatibilitaetsgruenden fuer teils uraltes Zeug auch noch einiges mit. Intel hat mit Clear Linux auch testweise eine eigene Distri zusammengestellt, die auch nennenswerte Steigerungen bringt. Hoffentlich schauen sich die ganzen Maintainer das mal an, ansonsten halt gentoo :ulol: ;p

@S940: OK, wo ich schon dabei war...
Um das ganze abzuschliessen:
|4C/4T|4C/8T
Linux|3:37|2:41
Windows|5:13|3:37

and the winner is... :ugly:
Mit SMT braucht bei mir 26 bzw. 31% kuerzer, Windows gewinnt also tatsaechlich etwas mehr

Jetzt aber genug OT

[S940]

@Skysnake:
Ja, aber trotzdem muss man sich mal langsam fragen, was da so abläuft.
Wenn sich der Unterschied jetzt auch noch bei Vulkan-Games unter Linux bemerkbar machen sollten, dann muss MS demnächst für Windows noch was zahlen :freak:

Windows builds waren schon immer langsamer, aber so einen großen Unterschied hätte ich auch nicht mehr erwartet. GCC builds waren damals auch auf Windows schneller, aber da habe ich gerade keine Lust, das auch noch auszuprobieren, zumal es lt. Wiki eh kaputt ist.

Ja passt schon, hast schon genug getestet, Danke nochmal ;)


@S940: OK, wo ich schon dabei war...
Um das ganze abzuschliessen:
|4C/4T|4C/8T
Linux|3:37|2:41
Windows|5:13|3:37

and the winner is... :ugly:
Mit SMT braucht bei mir 26 bzw. 31% kuerzer, Windows gewinnt also tatsaechlich etwas mehr

Ja ungefähr ein Unterschied von ~10%.
Witzig. Windows reißt also Löcher in den Code, für die man dann SMT zum Stopfen braucht :freak:

[iuno]

Naja, gaming hat mit HPC nichts zu tun und idR. erzeugen Spiele auch nicht annaehernd diese CPU Last. Es gibt quasi keine einzige moderne Engine, die mindestens gleichwertig auch fuer Linux entwickelt wird. Und dann ist da noch die Sache mit den Treibern.
Wenn Spiele generell 50% schneller laufen wuerden, gaebe es sicherlich mehr Linux Nutzer, das ist aber nicht der Fall sondern das Gegenteil.
Aber das ist hier eh OT

[S940]

Naja, gaming hat mit HPC nichts zu tun und idR. erzeugen Spiele auch nicht annaehernd diese CPU Last.
Naja, Games erzeugen schon auch CPU-Last, vielleicht nicht am Anschlag, aber mit den neuen Schnittstellen DX12/Vulkan wird das auch "besser". Windows bekommt es aber sowieso nicht auf die Reihe damit die Kerne optimal zu füttern, egal ob 100% oder 50% Last. Was genau das für ein Code ist INT/FP/AVX/SSE scheint egal zu sein, das Problem ist ja einzig und allein das OS.
Von daher ist das schon in dieser groben Ansicht vergleichbar.

Es gibt quasi keine einzige moderne Engine, die mindestens gleichwertig auch fuer Linux entwickelt wird. Und dann ist da noch die Sache mit den Treibern.
Wie besagt: Vulkan. Das ist das Zauberwort. Damit werden schon ein paar gute Engines ausgestattet (Cryengine ab Release 5.3. Unreal-Engine von Eic, Id-Tech(Doom), also das ist schon nicht übel) und der Vorteil wäre, dass man dafür keine komplizierten Treiber im traditionellen Sinne mehr benötigt, sondern nur ne dünne Interfaceschicht. Das sollte auch der schlechteste Praktikant von AMD/Nvidia unter Linux fertigbekommen. Mehr braucht es nicht, die Optimierungen sind schon in der jeweiligen Engine enthalten. Von daher bin ich im Moment wg. Gaming@Linux frohen Mutes, aber ja das ist OT, weiteres im Vulkan Thread:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=560968

[Hübie]

Windows builds waren schon immer langsamer, aber so einen großen Unterschied hätte ich auch nicht mehr erwartet. GCC builds waren damals auch auf Windows schneller, aber da habe ich gerade keine Lust, das auch noch auszuprobieren, zumal es lt. Wiki eh kaputt ist. Mich überrascht da aber, dass ICC und msvc sich genau nichts schenken.
Denke nicht dass SMT noch einen großen Unterschied macht, win ist ja insgesamt schon viel langsamer.

@Skysnake: Ja, die "normalen" Distris schleppen aus Kompatibilitaetsgruenden fuer teils uraltes Zeug auch noch einiges mit. Intel hat mit Clear Linux auch testweise eine eigene Distri zusammengestellt, die auch nennenswerte Steigerungen bringt. Hoffentlich schauen sich die ganzen Maintainer das mal an, ansonsten halt gentoo :ulol: ;p

@S940: OK, wo ich schon dabei war...
Um das ganze abzuschliessen:
|4C/4T|4C/8T
Linux|3:37|2:41
Windows|5:13|3:37

and the winner is... :ugly:
Mit SMT braucht bei mir 26 bzw. 31% kuerzer, Windows gewinnt also tatsaechlich etwas mehr

Jetzt aber genug OT

Wäre hilfreich, OS, CPU-Modell und Takt zu wissen. Kann gerade überhaupt nix mit den Zahlen anfangen. :redface:

[S940]

Wäre hilfreich, OS, CPU-Modell und Takt zu wissen. Kann gerade überhaupt nix mit den Zahlen anfangen. :redface:
OS steht schon dabei, den Rest hatte er anfangs geschrieben:
Skylake, 4C/8T, 4,0 GHz
Der bekannte BMW-Test (bmw27)

[Hübie]

Wo steht das OS? Ich seh nur Windows und Linux. :|

@iuno: Kannst du dein build mal hoch laden? :D Im Benchmarking Unterforum kannst du deine Ergebnisse ganz ohne OT los werden.

[Setsul]

@Gipsel:
Skylake-E wird die Konkurrenz sein, also bringt das nicht allzu viel.
128b Code ist zwar schön im Vergleich zu Intel, absolut dürfte 256b auch auf Zen schneller sein (Frontend), solange das Bridging nichts kostet.
Latenz von bridged FMAC wäre interessant.

Für den Vergleich mit Broadwell-E versuch ich mal herauszufinden wieviel FMAC in blender steckt. AVX an sich scheint nicht viel zu sein und das sagt natürlich alles nichts über andere Programme, aber interessant zu wissen wäre es schon. Leider ist es etwas ekelhaft, weil Haswell mir das natürlich nicht direkt verraten will. Disassembler/Debugger sollte aber funktionieren, ist nur mehr Aufwand.

@iuno/S940: Valve sollte Source 2 auf Linux recht viel Aufmerksamkeit schenken, wenn das mit Steam Machines noch etwas werden soll. Aber das kann natürlich noch bis 202x dauern.

EDIT: Hat sich eigentlich schon jemand darüber Gedanken gemacht bei welchen (wievielen) Ports Branches landen bei Zen?

[S940]

Wo steht das OS? Ich seh nur Windows und Linux. :|
Aso Du willst es noch genauer? Wozu? Er wird schon ein Windows haben, dass mit SMT umgehen kann ;)

@iuno/S940: Valve sollte Source 2 auf Linux recht viel Aufmerksamkeit schenken, wenn das mit Steam Machines noch etwas werden soll.
Das versteht sich von selbst, deswegen hab ichs gar nicht mit aufgezählt ;)
EDIT: Hat sich eigentlich schon jemand darüber Gedanken gemacht bei welchen (wievielen) Ports Branches landen bei Zen?

Guckst Du hier:
http://www.planet3dnow.de/cms/20255-analyse-der-vermuteten-zen-architektur/

In den INT-Pipes ganz unten stehen die Besonderheiten/Abweichungen:
1xIDIV, 1xIMLU, 2xCALL (= Branch). Ist seit letzter Woche auch so von AMD bestätigt.

[Skysnake]

Windows builds waren schon immer langsamer, aber so einen großen Unterschied hätte ich auch nicht mehr erwartet. GCC builds waren damals auch auf Windows schneller, aber da habe ich gerade keine Lust, das auch noch auszuprobieren, zumal es lt. Wiki eh kaputt ist. Mich überrascht da aber, dass ICC und msvc sich genau nichts schenken.
Denke nicht dass SMT noch einen großen Unterschied macht, win ist ja insgesamt schon viel langsamer.

Die Compiler sind an sich aller ziemlich ähnlich was die Performance anbelangt. Wo Intel meinem Eindruck nach besser ist, ist wenn es um Prefetching und die Anzahl der multiplen Codepfade geht. Habe aber schon öfters inzwischen Code gesehen, der mit dem GCC schneller läuft als mit dem ICC.

@Skysnake: Ja, die "normalen" Distris schleppen aus Kompatibilitaetsgruenden fuer teils uraltes Zeug auch noch einiges mit. Intel hat mit Clear Linux auch testweise eine eigene Distri zusammengestellt, die auch nennenswerte Steigerungen bringt. Hoffentlich schauen sich die ganzen Maintainer das mal an, ansonsten halt gentoo :ulol: ;p

Das meine ich jetzt nicht mal, sondern die ganzen Hintergrunddienste die auf einem normalen Linux laufen. Jeder beschissene Interrupt oder sonstige OS trap haut dir halt hunderte µs bis ms an Rechenzeit weg. Wenn du feingranulare Synchronisation hast durch z.B. OpenMP Parallelisierung Dann kann dir das alle Cores quasi für die Zeit anhalten. DAs ist dann schon ziemlich beschissen, und du freust dich, wenn das möglichst selten passiert. MAn kann durch so etwas mit einer normalen Distri aber schnell mal einen einstelligen Prozentsatz an Leistung verlieren. Daher bin ich eigentlich ein Verfechter davon, dass das "drecks OS" seinen eigenen Kern bekommt, und AUF GAR KEINEN FALL! auch nur irgend etwas auf den Kernen ausführen darf, auf denen der User Code läuft. Fujitsu mit ihrem SPARC und Linux Derivat machen ja wohl so etwas.

@Skysnake:
Ja, aber trotzdem muss man sich mal langsam fragen, was da so abläuft.
Wenn sich der Unterschied jetzt auch noch bei Vulkan-Games unter Linux bemerkbar machen sollten, dann muss MS demnächst für Windows noch was zahlen :freak:

Schau dir doch einfach mal im Taskmanager an, wieviele Hintergrunddienste da laufen. Von Dingern wie MSI Afterburner und Konsorten mal ganz zu schweigen :freak:

[Gipsel]

Zu den Windows/Linux-Unterschieden auch noch mal mein Senf:
Solange man nicht merkliche Zeit im Betriebssystem verbringt (z.B. weil man ständig ein paar Byte alloziert und wieder freigibt), hat das OS kaum einen meßbaren Einfluß auf die Performance. Denn ein Taskswitch kostet nicht so viel Zeit und das sollte so ziemlich Alles sein, was das OS macht (außer es gibt deutliche Unterschiede in der Scheduling Policy, das sollte aber nicht wesentlich sein, da HT schon ewig bekannt ist und es gibt ja laut iuno auch ohne HT deutlichste Unterschiede), wenn ein Programm die CPU auslastet. Mehr als 1-2% für die Hintergrunddtasks sollten doch nie und nimmer draufgehen, oder da läuft was falsch.

Die Resultate sehen ehrlich gesagt für mich so aus, als würde die Autovektorisierung nicht wirklich funktionieren. Ansonsten sollten die Ergebnisse schon Unterschiede zwischen den verschiedenen Befehlssätzen zeigen. Das kann man sich bei den Compilern übrigens anzeigen lassen, ob Schleifen autovektorisiert wurden und wenn nicht, warum nicht. Manchmal kann man das dann durch aggressivere Compilereinstellungen erzwingen, aber vermutlich muß man Pragmas vor die entsprechenden kritischen Schleifen stellen oder gar die Datenstrukturen von Blender anfassen, damit das funktioniert. Eigentlich würde ich mich fast wundern, warum man bei so etwas performancekritischem wie einem Renderer nicht schon von vornherein mit Intrinsics anfängt (wodurch die Performance deutlich unabhängiger von den Compilerfähigkeiten werden sollte). Also in dem Fall, daß sich das bei den verwendeten Algorithmen lohnen sollte. Wenn einer Lust hat, kann er ja mal etwas genauer in den Quellcode von Blender schauen, was der da eigentlich genau macht.

[Hübie]

Aso Du willst es noch genauer? Wozu? Er wird schon ein Windows haben, dass mit SMT umgehen kann ;)


Es gibt schon signifikante Unterschiede zwischen Win7<->10. Daher meine Neugier. :wink:

[mboeller]

Offene Fragen: Ein Haswell mit ICC-Complilat könnte aus Haswell vielleicht noch mehr rausholen, aber in Form eines fairen Vergleiches könnte man AMD keine Vorwürfe machen, wenn sie beiden Architekturen ein GCC-Compilat vorsetzt - zumindest solange der Intel Chip die 256-Bit-Version bekommt.

Aber selbst wenn AMD gecheated hätte und den Broadwell-E mit AVX-128 gefüttert hätte... der Unterschied wäre mit 2% sehr gering gewesen.

[S940]

Schau dir doch einfach mal im Taskmanager an, wieviele Hintergrunddienste da laufen. Von Dingern wie MSI Afterburner und Konsorten mal ganz zu schweigen :freak:
Ja das kostet sicherlich n Bisschen, aber doch keine ~30%.
Zu den Windows/Linux-Unterschieden auch noch mal mein Senf:
Solange man nicht merkliche Zeit im Betriebssystem verbringt (z.B. weil man ständig ein paar Byte alloziert und wieder freigibt), hat das OS kaum einen meßbaren Einfluß auf die Performance. Denn ein Taskswitch kostet nicht so viel Zeit und das sollte so ziemlich Alles sein, was das OS macht (außer es gibt deutliche Unterschiede in der Scheduling Policy, das sollte aber nicht wesentlich sein, da HT schon ewig bekannt ist und es gibt ja laut iuno auch ohne HT deutlichste Unterschiede), wenn ein Programm die CPU auslastet. Mehr als 1-2% für die Hintergrunddtasks sollten doch nie und nimmer draufgehen, oder da läuft was falsch.
Seh ich auch so.
Die Resultate sehen ehrlich gesagt für mich so aus, als würde die Autovektorisierung nicht wirklich funktionieren. Ansonsten sollten die Ergebnisse schon Unterschiede zwischen den verschiedenen Befehlssätzen zeigen. Das kann man sich bei den Compilern übrigens anzeigen lassen, ob Schleifen autovektorisiert wurden und wenn nicht, warum nicht. Manchmal kann man das dann durch aggressivere Compilereinstellungen erzwingen, aber vermutlich muß man Pragmas vor die entsprechenden kritischen Schleifen stellen oder gar die Datenstrukturen von Blender anfassen, damit das funktioniert. Eigentlich würde ich mich fast wundern, warum man bei so etwas performancekritischem wie einem Renderer nicht schon von vornherein mit Intrinsics anfängt (wodurch die Performance deutlich unabhängiger von den Compilerfähigkeiten werden sollte). Also in dem Fall, daß sich das bei den verwendeten Algorithmen lohnen sollte. Wenn einer Lust hat, kann er ja mal etwas genauer in den Quellcode von Blender schauen, was der da eigentlich genau macht.
Naja, Intrinsics gibts .. nur sind die blöderweise 128 bit :freak:
Hat vor Kurzem erst einer bei Anandtech gepostet:
For blender generic build, or 2.77 release,etc. __m256 style instructions aren't used, instead the intrinsics are __m128. If the switch was made we could see up to 30% improvement on the Broadwell-E processor. Which is technically two full refreshes or one new architecture ahead of AMD.

So einfach mal so auf 256bit umzustellen bringt aber auch nix, denn Dresdenboy entgegnete:
If Blender still uses single precision, those 128 bit vectors fit quite nicely, as 4 vector elements are a good base for the typical coordinate transformations using 4x4 matrices. Colors could be represented as RGBA as well.

So going from 1 vector (128b, 4 floats) to 2 parallel vectors (256b, 8 floats) might just make the code more complicated than bring significant benefits.

Also going to double precision to preserve 4 wide vectors would also cost bandwidth and capacity at other places in a processor (e.g. data caches are being effectively halved, and mem BW as vectors/clock too).

This is also an interesting topic for 3D and physics engines in games.
Also das wars dann wohl mit dem Thema.
Da stellt sich dann nur noch die Anschlussfrage, ob man 256 Bit in einer general purpose CPU überhaupt braucht.

@Hübie:
Achso, alles klar. War mir nicht bewusste, dachte nicht, dass sich da was wegen SMT getan hätte.

@mboeller: Auch richtig, aber man könnte es AMD dann trotzdem vorwerfen, egal wie viel.

[Setsul]

@S940:
Wo hat AMD das bestätigt? Wurden die recht wirren FPU assignments auch so bestätigt?
Ich meinte außerdem eher in Sachen scheduling. Ich nehme mal an, dass die getrennten Scheduler auch dafür gedacht sind, dass man Scheduler + dazugehörige ALU clock/powergaten kann. So oder so konkurrieren int und branch um slots. Andererseits hat man bei Skylake zwar wunderschöne 97 slots immer verfügbar, aber jeder Branch blockiert nicht nur eine ALU sondern eventuell auch noch FP und vector.

Jetzt bitte wilde Spekulationen wie sich das auswirkt.

[S940]

@S940:
Wo hat AMD das bestätigt?

Hier:
https://www.youtube.com/watch?v=sT1fEohOOQ0&feature=youtu.be&t=1079
Wurden die recht wirren FPU assignments auch so bestätigt?Ne dazu hatte Mark explizit nix gesagt, aber Du kannst mal schauen, ob sich die Compliersourcen in der Zwischenzeit geändert haben ;)
Ich meinte außerdem eher in Sachen scheduling. Ich nehme mal an, dass die getrennten Scheduler auch dafür gedacht sind, dass man Scheduler + dazugehörige ALU clock/powergaten kann. So oder so konkurrieren int und branch um slots. Andererseits hat man bei Skylake zwar wunderschöne 97 slots immer verfügbar, aber jeder Branch blockiert nicht nur eine ALU sondern eventuell auch noch FP und vector.

Jetzt bitte wilde Spekulationen wie sich das auswirkt.
Naja, das ist dann nur wieder die alte Diskussion die wir schon vor ein paar Seiten hatten, nämlich das Intel ggü. Zen wegen solcher Multi-Port-Blockaden schlechter mit SMT skalieren sollte.
Anders gesagt: Ja da gibts viel mehr Schedulerplätze, aber Intel muss auch länger suchen, bis es mal passt ;)

Immerhin gibts bei Intel aber ne INT-ALU vergleichbar mit AMDs an Port 6, die keine FP-Verpflichtungen hat. Vermutlich werden alle Branches zu der gemappt, im single-thread Betrieb wird das bestimmt keine Probleme bereiten. Das geschilderte Problem dürfte damit v.a. im SMT-Betrieb auftauchen.

[Setsul]

2 Branches an sich sind klar, weniger wäre Schwachsinn. Aber von den Ports sagt er nichts?
Der Plan war, dass sich jemand anderes die Compilerresourcen nochmal durchgelesen hat oder sonst irgendwo eine Bestätigung gefunden hat, damit ich nicht suchen muss.;)

Ok, das war genau meine Frage. Welche Seite?

Port 6 wurde genau dafür eingeführt, ist mir schon klar. Keine Ahnung wieso Intel Branch2 nicht auf Port 5 legt. Wird irgendwelche lustigen internen Gründe haben.

[S940]

2 Branches an sich sind klar, weniger wäre Schwachsinn. Aber von den Ports sagt er nichts?

Nö, aber 2 an einem Port wäre ebenfalls Schwachsinn :wink:
Außerdem stimmt der Rest der Compiler-Sourcen ja auch, 4 INT, 2 AGUs, 4 FP. Also wirds im Detail sicherlich auch stimmen.

Der Plan war, dass sich jemand anderes die Compilerresourcen nochmal durchgelesen hat oder sonst irgendwo eine Bestätigung gefunden hat, damit ich nicht suchen muss.;)
Hihi, schon klar, leider gibts im Moment aber keinen. Vielleicht schau ichs mir nächste Woche mal an, gab da nämlich noch n interessantes Detail Vortrag, das wollte ich mal nachprüfen.

Ok, das war genau meine Frage. Welche Seite?
Nicht weit weg, vielleicht 5, aber viel wars auch nicht, ich schrieb da nur, dass AMD die bessere SMT-Leistung abliefern dürfte, weil das Design breiter ist. Dann kam noch der Einwurf, dass das egal wäre, da das Front-End der limitierende Faktor wäre, worauf ich entgegnete, dass das ZEN-Frontend auch aufgebrezelt ist.
Port 6 wurde genau dafür eingeführt, ist mir schon klar. Keine Ahnung wieso Intel Branch2 nicht auf Port 5 legt. Wird irgendwelche lustigen internen Gründe haben.
Ja etwas merkwürdig. Langsam frag ich mich aber auch, was die 256 bit sollen. Es kommt ja sogar auch noch AVX512.
Ist schon klar, wieso Intel das macht, weil sie keine leistungsfähigen GPUs haben, aber ihre CPU-Kerne bekommen damit Schlagseite. Gegen absaufende Bulldozer ist/war das natürlich das deutlich geringere Übel, aber im Kampf um Perf/Watt, Max.-Takt, Powerbudget etc. pp, wird das in Zukunft ein Nachteil sein, solange sie die im Desktopbereich übertriebenen Rechenwerke nicht power-gaten können ^^

[Setsul]

Ja, aber man könnte 2 Branch Units haben und dann lustige Sachen machen, auf alle Ports oder ganz außen vor.
Wenn man sich den Rest so anschaut wäre das nicht das ungewöhnlichste. Laut planet3dnow kann nur FP3 die anderen 128b von FMAC zu FP0/1, FP2 kann es nicht. Also entweder stimmt das nicht oder 256b FMAC auf FP0 und 1 blockieren sich gegenseitig. Wenn man bereit ist das im Scheduler zu lösen, macht man eventuell auch andere komische Dinge.

Oder planet3dnow liegt falsch und 2x256b FMAC geht gleichzeitig.

AVX ist einfach Xeon Phi. Auf den normalen Xeons dann für Kompatibilität und das übliche "Wir sind viel besser GPUs, seht ihr? Gleiche Instruktionen auf Xeon und Xeon Phi!".
Und das übliche Marketing "Die neuen CPUs sind doppelt so schnell! Ehrlich!" mit den schönen "peak SP/DP FLOP per cycle"-Tabellen.

[iuno]

@iuno/S940: Valve sollte Source 2 auf Linux recht viel Aufmerksamkeit schenken, wenn das mit Steam Machines noch etwas werden soll. Aber das kann natürlich noch bis 202x dauern.
In Valve setze ich da keine Hoffnungen, aber wie gesagt ist das hier eh OT ;)


Die Compiler sind an sich aller ziemlich ähnlich was die Performance anbelangt. Wo Intel meinem Eindruck nach besser ist, ist wenn es um Prefetching und die Anzahl der multiplen Codepfade geht. Habe aber schon öfters inzwischen Code gesehen, der mit dem GCC schneller läuft als mit dem ICC.
Ja, das glaube ich schon. Aber es war bei Blender eben schon vor Jahren so, dass gcc Builds merklich schneller war. Ich bin dahingehend aber wie gesagt kein Experte und habe auch nicht in den Code reingeschaut. Es ist bekannt, stoert aber offenbar keinen wirklich. Die treibenden Instanzen verwenden wohl eh Linux und dementsprechend keine msvc builds.

Das meine ich jetzt nicht mal, sondern die ganzen Hintergrunddienste die auf einem normalen Linux laufen.
Naja, definiere "normales Linux" ;p
Aber klar, sobald man eine funktionale DE inkl. aller bequemer Automatismen usw. hat, hat man natuerlich haufenweise daemons fuer alles Moegliche laufen, das stimmt natuerlich.

Zu den Windows/Linux-Unterschieden auch noch mal mein Senf:
Solange man nicht merkliche Zeit im Betriebssystem verbringt (z.B. weil man ständig ein paar Byte alloziert und wieder freigibt), hat das OS kaum einen meßbaren Einfluß auf die Performance.
Das meine ich auch, daher hat mich der grosse Abstand auch ueberrascht. Aber wie gesagt, das ist bei der Software schon lange ein Problem, irgendwas passt dort nicht ganz zusammen.

Aber selbst wenn AMD gecheated hätte und den Broadwell-E mit AVX-128 gefüttert hätte... der Unterschied wäre mit 2% sehr gering gewesen.
Naja, man kann ihnen vorwerfen, dass sie den lahmen Windows build genommen haben, der sowieso alles "frisst", z.B. egal ob AVX oder nicht. Es koennte daher aber immer noch sein, dass SMT bei Zen etwas mehr bringt, das bleibt aber reine Spekulation. Nach der Testerei ist mir nur klar geworden, dass es letztlich nichts gebracht hat :ulol:

[mczak]

Und übrigens dupliziert erst Skylake die vADD- und vMUL- Einheiten sowohl an Port 0 sowie 1 (bis Broadwell gab es zwar 2 FMACS, aber reine Multiplikationen bzw. Additionen gehen ohne Umbiegen auf die FMACs [was Strom und Latenz kostet] nur in jeweils einem Port)

Das ist so nicht ganz korrekt. Es geht tatsächlich bloss ein fadd pro Takt bei Haswell/Broadwell, aber der Durchsatz und Latenz von fmul ist derselbe wie für fma.

Und Zen könnte einen mehr oder weniger deutlichen Vorteil bei Code haben, der nur mit 128Bit Vektor-Instruktionen arbeitet. Davon kann der dann nämlich bis zu 4 pro Takt durchziehen, die Intels nur zwei (bis drei inklusive der nichtarithmetischen Operationen).
Mir scheint dafür bei Zen ist Load/Store für den möglichen Durchsatz der FPU schon arg eng. Haswell und neuer kriegen ja problemlos 2x256bit Load und 1x256bit Store hin pro Takt. Die Load/Store Einheit bei Zen wird zwar auch mit 2x128bit Load und 1x128bit Store angegeben - aber der Chip hat bloss 2 AGUs, ich fürchte also es wird bei 1xLoad+1xStore oder 2xLoad pro Takt sustained bleiben. (Bei Sandy/Ivy Bridge ging bei Verwendung von 256bit Operationen (und nur dann!) auch insgesamt 256bit Load und 128bit Store pro Takt sustained, der Chip hatte genau dasselbe Problem mit bloss 2 AGUs und Load 2x128bit + Store 1x128bit, aber für 256bit Operationen wurden die AGUs bloss für einen Takt benötigt - keine Ahnung ob Zen den Trick auch beherrscht aber bei 128bit Operationen bringt der nichts.)

[Skysnake]

Ja das kostet sicherlich n Bisschen, aber doch keine ~30%.

Kann man so Pauschal nicht sagen. Wenn du keine Synchronisation im Code hast, kostet es wirklich fast nichts. Wenn du aber Synchronisation im ms Bereich hast, dann kostet das unter Umständen sehr sehr viel, weil quasi für jeden Schitt dann alle Kerne stehen für diese Zeit.


Naja, definiere "normales Linux" ;p
Aber klar, sobald man eine funktionale DE inkl. aller bequemer Automatismen usw. hat, hat man natuerlich haufenweise daemons fuer alles Moegliche laufen, das stimmt natuerlich.

Nen Ubuntu, RedHead oder Vergleichbar. Also keine explizit optimierten Linux Distris.

Wenn du das mit nem Minimal-kernel vergleichst, auf dem praktisch keine Dienste mehr laufen, dann können da wohl einige Prozentpunkte zusammenkommen. Das ist aber wie oben schon gesagt rein davon abhängig, wie fein du synchonisieren musst. Keine Ahnung, wie das bei Blender ist. An sich würde ich eher nicht davon ausgehen, dass da viel synchronisiert wird, aber manchmal kann man gar nicht so blöd denken wie programmiert wird...


Naja, man kann ihnen vorwerfen, dass sie den lahmen Windows build genommen haben, der sowieso alles "frisst", z.B. egal ob AVX oder nicht. Es koennte daher aber immer noch sein, dass SMT bei Zen etwas mehr bringt, das bleibt aber reine Spekulation. Nach der Testerei ist mir nur klar geworden, dass es letztlich nichts gebracht hat :ulol:
Das "lustige" ist ja, du kannst einCompilat haben, das je nach Input/Parametern mal schneller und mal langsamer ist als ein anderes compilat von einem anderen Compiler.

Hatte er neulich einen Fall, bei dem bei 2^n größen der ICC immer deutlich schneller war ~10%, die anderen größen war dann aber der GCC ~2-5% schneller. Am Ende war der Vorteil von ICC egal, da die Genauigkeit der Lösung mit n zusammen hängt, und die durchgeführten Rechenoperationen mit n^4 skalieren, die 2^(n+1) version dann abr deutlich!!! schneller war als die 2^n Version :freak:

Meine Vermutung ist da ein Problem beim Zugriff auf den Hauptspeicher. Also das man immer wieder auf die gleichen Memory Bänke zugreift und damit sich das Genick bricht. Der ICC generiert wohl einen besseren Prefetch, warum er das deutlich ausgleichen kann, aber am Ende vom Tag ist man eben dennoch langsamer.

Wie gesagt, man kann manchmal nicht so dumm denken, wie es dann real passiert.

[S940]

Die Load/Store Einheit bei Zen wird zwar auch mit 2x128bit Load und 1x128bit Store angegeben - aber der Chip hat bloss 2 AGUs, ich fürchte also es wird bei 1xLoad+1xStore oder 2xLoad pro Takt sustained bleiben.
Dresdenboy hofft da auf das Memfile in der Stack-Engine, die soll ein paar Adressoperationen überflüssig machen. Wieviel genau und ob es reicht wird die Praxis zeigen.
Kann man so Pauschal nicht sagen. Wenn du keine Synchronisation im Code hast, kostet es wirklich fast nichts. Wenn du aber Synchronisation im ms Bereich hast, dann kostet das unter Umständen sehr sehr viel, weil quasi für jeden Schitt dann alle Kerne stehen für diese Zeit.
Ok, aber wozu sollten Hintergrundprogramme großartig synchronisieren?
Klar gibts viel Mist im Code, aber pauschal würde ich jetzt sagen nicht so oft ;)
Da muss irgendwas anderes schief gelaufen sein, sieht man auch an den Bulldozerergebnissen von Oromis (Danke fürs Hochladen bei anandtech) ... Linux ist 1,8x schneller als Windows, das sind doch Abgründe, die sich da auftuen.

[Skysnake]

Ne nicht die Hintergrundprogramme synchen, wobei das aufs Selbe rausläuft, aber unwahrscheinlich ist.

Kleines Beispiel mit 4 Threads und einer OpenMP parallel Loop mit static sheduling von 40 Elementen a 1ms (x) (y=synchronisation am Ende) (?=irgendwas durch das OS von 1 ms. typische Werte sind da wohl durchaus etwas im Bereich von 2 ms. )

Ohne irgendwas
1:xxxxxxxxxx
2:xxxxxxxxxx
3:xxxxxxxxxx
4:xxxxxxxxxx

Mit 2ms shit drin
1:xxxxx??xxxxx
2:xxxxxxxxxxyy
3:xxxxxxxxxxyy
4:xxxxxxxxxxyy

Man braucht also wegen zwei ms OS noise insgesmt 8ms mehr CPU Zeit. Und das obwohl an sich eigentlich nur ein Thread ja langsamer ist als die anderen. So lange man mit OpenMP aber kein nowait angibt, hast du nach jeder LOOP eine implicite barrier. Ein dynamic sheduling würde eventuell noch helfen, aber auch nur, wenn es nicht ziemlich am Schluss passiert. und bei loops mit wenig Elementen haste dann wieder den erhöhten overhead.

Das Problem ist da auch gar nicht, dass das mal passiert, sondern das es wenn du eben über alle Cores derart parallelisierst und kurze loops hast, oder eben sonst wie kurze Zeiten zwischen synchs hast, dann bedeutet jedwede Störung, das du die Zeit praktisch auf allen genutzen cores wartest.

Deswegen kann es teilweise auch durchaus sinn machen eben einen Cores für das OS und die sonstigen Hintergrunddienste usw zu nutzen, und auf den anderen dann zu rechnen. Hängt aber eben davon ab, wie das Problem gelöst ist. Bei Blender würde ich das jetzt eher nicht erwarten, aber wissen kann man es eben nicht, so lange man es sich nicht angeschaut hat.

[Schaffe89]

Nur mal so ein kleiner Hinweis für alle die glauben, dass Zen eine Intel Skylake oder Haswell IPC erreicht.

Der einzige Benchmark der für einen Vergleich etwas taugen würde ist mMn der Benchmark von AotS da dieser mit legacy Code ausgeführt wird und die Situation bezüglich AVX bei Blender einfach nicht einzuschätzen ist und es ne Kirsche ist.

Mal angenommen diese Werte stimmen von AotS, und man weiß dass dieser Benchmark nicht besonders gut mit den Kernen skaliert ( siehe FX8350 vs Intel i5 ), dann müsste der Zen bei angenommenen ~3ghz Takt liegen.

Das sind von 3,0 zu 3,8ghz etwa gut 26% mehr Takt und der Haswell leistet 13% mehr, da muss man schon etwas stutzig werden denn AotS skaliert nicht besonders mit mehr als 8 Threads, siehe Benchmarks mit einem 5XXX Intel CPU.

Bessere IPC als Haswell? Absolut illusorisch. AMD kommt mit Excavator von Llano IPC. +40% liegt man da höchstens auf Sandy Bridge Performance was die Leistung pro Takt angeht.

AMD und der Ashes Benchmarker trollen die Community mit guten Benchmarks, realen Benchmarks werden !deutlich! langsamer sein.
AMD sagt Excavator (der ca 10 bis 20% mehr IPC bei entsprechend hohem Takt hat als Bulldozer) +40%. Das ist maximal Sandy Bridge Niveau und da hält sich meine Begeisterung stark in Grenzen.

Für AMD mag das eine gute Leistung sein. Aber da die CPU´s sogut wie final sind und das AMD Ergebnis sicher mit bisschen Würze entstanden ist und der andere AOT´s Benchmark ziemlich sicher mit einer übertakteten Zen CPU entstanden ist, wird das alles kein Gamechanger werden.

Zen wird ein ähnliches Schicksal wie Bulldozer erleiden. Zu niedrige IPC, zu wenig Takt um auf Leistung zu kommen vielleicht von der Effizienz nicht ganz so weit zurückliegen.

[Setsul]

Ah, es wird wieder Zeit eine Argumentationskette auseinander zu nehmen.

die Situation bezüglich AVX bei Blender einfach nicht einzuschätzen ist und es ne Kirsche ist.
Wo warst du die letzten 2 Seiten?


Mal angenommen diese Werte stimmen von AotS, und man weiß dass dieser Benchmark nicht besonders gut mit den Kernen skaliert ( siehe FX8350 vs Intel i5 ), dann müsste der Zen bei angenommenen ~3ghz Takt liegen.

Also wir halten fest:
-AotS skaliert nicht besonders gut mit Kernen
-Zen liegt deshalb (?!) bei ~3GHz.


Das sind von 3,0 zu 3,8ghz etwa gut 26% mehr Takt und der Haswell leistet 13% mehr, da muss man schon etwas stutzig werden denn AotS skaliert nicht besonders mit mehr als 8 Threads, siehe Benchmarks mit einem 5XXX Intel CPU.

-Zen hat ähnliche oder sogar bessere IPC als Haswell wenn AotS schlecht skaliert
-deshalb muss Zen viel schlechtere IPC als Haswell haben.
Ich kann der Logik nicht ganz folgen.


Bessere IPC als Haswell? Absolut illusorisch. AMD kommt mit Excavator von Llano IPC. +40% liegt man da höchstens auf Sandy Bridge Performance was die Leistung pro Takt angeht.

AMD und der Ashes Benchmarker trollen die Community mit guten Benchmarks, realen Benchmarks werden !deutlich! langsamer sein.
AMD sagt Excavator (der ca 10 bis 20% mehr IPC bei entsprechend hohem Takt hat als Bulldozer) +40%. Das ist maximal Sandy Bridge Niveau und da hält sich meine Begeisterung stark in Grenzen.

Es haben schon viele herumgerechnet was "Excavator +40%" bedeutet. Unter Sandy Bridge ist das sicher nicht.
https://www.reddit.com/r/Amd/comments/44hrj7/a_theoretical_calculation_about_of_zens_single/
Gibt noch viele andere, einfach mal suchen oder selbst rechnen.



Ach ja, ich bin so ehrlich und geb dir sogar etwas das deine Theorie stützt, auch wenn die Argumentation bis jetzt völliger Schwachsinn war.
http://core0.staticworld.net/images/article/2016/02/dx12_cpu_ashes_of_the_singularity_beta_2_average_cpu_frame_rate_high_quality_19x 10-100647718-orig.png

[robbitop]

AoTS ist auch einfach ein Benchmark mit zu vielen Variablen. Wirklich als Legacy würde ich den auch nicht einschätzen. Zumal bei der Übersicht von Wccf Zen taktnormiert (also das Ergebnis vom FX8 von 4 auf 3 GHz heruntergerechnet) 98% schneller war.
Ich wäre zunächst zwar auch skeptisch aber würde auch nicht unbedingt den Teufel an die Wand malen. Ich tippe auch darauf, dass Blender cherrypicked ist - aber wenn das Endergebnis zu sehr davon abweichen würde in realworld würde man sich lächerlich machen.

[S940]

Zen wird ein ähnliches Schicksal wie Bulldozer erleiden. Zu niedrige IPC, zu wenig Takt um auf Leistung zu kommen vielleicht von der Effizienz nicht ganz so weit zurückliegen.
Na das ist ist etwas zu pessimistisch / provokativ formuliert. Was Zen liefert ist erstmal eine passable / konkurrenzfähige Architektur. Das ist schon mal mehr, als BD je wahr. Ob jetzt Sandy/Haswell oder Skylake-Niveau ist egal, die nehmen sich alle nicht viel, solange wir nicht über AVX256 reden.

Damit fällt ein Problem schon mal weg, bleibt nur noch die Unbekannte Globalfoundries. Die haben schon öfters mal einen Prozess an die Wand gefahren, aber mittlerweile haben sie die IBM-Sparte vollends geschluckt, d.h. da ist ne Menge fähiger Mitarbeiter dazugekommen. Wird schon klappen.

Wenn man das dann abhakt bleibt nur noch der Prozess an sich. Das ist nur der Medium-Prozess, eher auf low-power als auf Höchstleistung optimiert.

5 GHz kann man sich also definitiv abschminken, schauen wir mal, ob es wenigstens für 3,8 - 4,0 reicht. Wenn sie das hinbekämen, wäre es schon topp.

[Complicated]

Wer die IPC einer CPU mit einem Spiel messen will weiss sowieso nicht wovon er schreibt. Es gibt kein Spiel dass eine CPU vollständig Auslasten kann und man somit die IPC messen könnte.

Da erübrigt sich auch jegliche seltsame "Rechnung" wie ein Spiel mit Kernen/Takt/Speicher skalieren würde. Die IPC der CPU zu messen mit Software die hauptsächlich in DirectX geschrieben ist für die GPU macht das ganze dann noch lächerlicher. In Spielen ist die CPU lediglich Co-Prozessor der GPU.

Pack den Zen in dieses Testszenario:
http://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/9
Dann kann man mal von IPC sprechen (wenn auch die Softwareauswahl und die Compiler hier genauer betrachtet werden müssen) - vorher nicht. Und schon gar nicht kann man IPC der CPU in FPS ausdrücken die von der GPU generiert werden.

Die Spieletests auf der darauf folgenden Seite sprechen diesbezüglich auch eine deutliche Sprache:
Discrete graphics card performance decreases on Skylake over Haswell.

This doesn’t particularly make much sense at first glance. Here we have a processor with a higher IPC than Haswell but it performs worse in both DDR3 and DDR4 modes. The amount by which it performs worse is actually relatively minor, usually -3% with the odd benchmark (GRID on R7 240) going as low as -5%. Why does this happen at all?

So we passed our results on to Intel, as well as a few respected colleagues in the industry, all of whom were quite surprised. During a benchmark, the CPU performs tasks and directs memory transfers through the PCIe bus and vice versa. Technically, the CPU tasks should complete quicker due to the IPC and the improved threading topology, so that only leaves the PCIe to DRAM via CPU transfers.

Our best guess, until we get to IDF to analyze what has been changed or a direct explanation from Intel, is that part of the FIFO buffer arrangement between the CPU and PCIe might have changed with a hint of additional latency. That being said, a minor increase in PCIe overhead (or a decrease in latency/bandwidth) should be masked by the workload, so there might be something more fundamental at play, such as bus requests being accidentally duplicated or resent due to signal breakdown.

[Setsul]

@Complicated
Läuft doch
http://www.pcgameshardware.de/screenshots/original/2016/06/Overwatch-CPU-R9-Fury-4C4T-2-GHz-pcgh.png
http://www.pcgameshardware.de/Overwatch-Spiel-55018/Tests/Benchmarks-Test-Grafikkarten-1197158/
Problem ist halt, dass die Spiele die wirklich gute, gleichmäßige Auslastung produzieren meistens nicht mehr als 4 Threads benutzen, weil mehr dann einfach unnötig sind.

AotS CPU framerate gerade bei gleicher GPU ist noch weit über Durchschnitt als CPU Benchmark unter Spielen.

Wenn dann würde ich es eher auf Windows schieben. Würde mich überhaupt nicht wundern wenn Windows 10 alle 8 Threads auf die ersten 4 Kerne gesteckt hätte.


Dass Ivy Bridge und Skylake in bestimmten Situationen (RAM bound, nicht mehr IPC rauszuholen, komische dependency chains die das größere ooo window negieren) langsamer sind als der jeweils direkte Vorgänger und dass das an der höheren RAM Latenz liegt ist doch bekannt? Gerade Skylake ist echt enttäuschend im Vergleich zu den internen Veränderungen. Keine Ahnung wieviel am L2 liegt, aber ich nehme an das hat Intel gern geopfert für mehr Kerne.

[gmb]

Skylake geht erst mit schnellen DDR4 richtig ab in Spielen. Anandtech testet games im GPU Limit, davon mal abgesehen. Für IPC Vergleiche sinnlos.

[MR2]

Spiele sind schon ein erster, wichtiger Indikator für die IPC einer CPU. Das kann man doch nicht abstreiten. Bisher war es doch immer so.
Ich habe mir die letzten Tage massig alte CPU Tests von Computerbase durchgelesen. Jede Generation , egal Intel oder AMD, welche in Spielen einen Satz nach vorn gemacht hat, hatte auch ne stärkere IPC als die Konkurenz.


" Ein klarer Vorsprung und dies, obwohl die Spiele in den getesteten Auflösungen stellenweise von der Grafikkarte limitiert werden - dachten wir zumindest bis jetzt."
"Besonders beeindruckt hat uns dabei die sehr gute Spieleleistung des neuen Athlon 64 3200+ - trotz Single Channel und "nur zwei Gigahertz". Hier liegt er im Rating sogar gute 5,5 % vor dem Intel-Pendant mit 3,2 GHz."

"Diesen thermischen Problemen gegenüber standen und stehen ein stromsparender Athlon 64 und Dual-Core Athlon 64 X2 von AMD, der Intel insbesondere in Spielen Kopfzerbrechen bereitet."

"In Sachen Computerspiele führt an AMDs Athlon 64-Prozessoren so schnell kein Weg vorbei. Erwartungsgemäß setzt sich der neue Athlon 64 FX an die Spitze des Testfeldes. Allein der neue Speichercontroller wirkt hier wahre Wunder. Hohe Bandbreiten gepaart mit niedrigen Latenzen zahlen sich in Spielen aus. "

"Sehr gut ist die reine Prozessorleistung der „Sandy Bridge“-CPUs. Das nicht einmal 300 Euro teure Flaggschiff Intel Core i7-2600 geht – umgangssprachlich gesagt – schlichtweg „ab wie Schmidts Katze“. Dabei ist insbesondere die Leistung in Spielen nichts anderes als herausragend. Hier düpiert das Modell jeden bisher erhältlichen Prozessor und hebt die Messlatte teilweise so hoch, dass wir mit einer GeForce GTX 580 als aktuell schnellste Grafiklösung schon wieder an das Grafiklimit stoßen. "

So zieht sich das durch alle Tests. Wenn ich mir dagegen den Bulldozer Test durchlese..;D



Intel versprach damals 40% mehr Leistung bei 40% weniger Verbrauch von Conroe zum PentiumD 950..
Dagegen verbraucht Excavator schon weniger Strom. Hoffentlich reichen die 40% mehr IPC. Ich bin leicht optimistisch :-)

[gmb]

Davon gehe ich auch aus. Bringt Zen eine gute IPC in Spielen, sollte das generell so sein. Abgesehen von AVX2.

Für Complicated zur Erklärung bezüglich leicht geringerer GPU Werte:
http://www.anandtech.com/show/9607/skylake-discrete-graphics-performance-pcie-optimizations

[MR2]

Spiele sind schon ein erster, wichtiger Indikator für die IPC einer CPU. Das kann man doch nicht abstreiten. Bisher war es doch immer so.
Ich habe mir die letzten Tage massig alte CPU Tests von Computerbase durchgelesen. Jede Generation , egal Intel oder AMD, welche in Spielen einen Satz nach vorn gemacht hat, hatte auch ne stärkere IPC als die Konkurenz.


" Ein klarer Vorsprung und dies, obwohl die Spiele in den getesteten Auflösungen stellenweise von der Grafikkarte limitiert werden - dachten wir zumindest bis jetzt."
"Besonders beeindruckt hat uns dabei die sehr gute Spieleleistung des neuen Athlon 64 3200+ - trotz Single Channel und "nur zwei Gigahertz". Hier liegt er im Rating sogar gute 5,5 % vor dem Intel-Pendant mit 3,2 GHz."

"Diesen thermischen Problemen gegenüber standen und stehen ein stromsparender Athlon 64 und Dual-Core Athlon 64 X2 von AMD, der Intel insbesondere in Spielen Kopfzerbrechen bereitet."

"In Sachen Computerspiele führt an AMDs Athlon 64-Prozessoren so schnell kein Weg vorbei. Erwartungsgemäß setzt sich der neue Athlon 64 FX an die Spitze des Testfeldes. Allein der neue Speichercontroller wirkt hier wahre Wunder. Hohe Bandbreiten gepaart mit niedrigen Latenzen zahlen sich in Spielen aus. "

"Sehr gut ist die reine Prozessorleistung der „Sandy Bridge“-CPUs. Das nicht einmal 300 Euro teure Flaggschiff Intel Core i7-2600 geht – umgangssprachlich gesagt – schlichtweg „ab wie Schmidts Katze“. Dabei ist insbesondere die Leistung in Spielen nichts anderes als herausragend. Hier düpiert das Modell jeden bisher erhältlichen Prozessor und hebt die Messlatte teilweise so hoch, dass wir mit einer GeForce GTX 580 als aktuell schnellste Grafiklösung schon wieder an das Grafiklimit stoßen. "

So zieht sich das durch alle Tests. Wenn ich mir dagegen den Bulldozer Test durchlese..;D



Intel versprach damals 40% mehr Leistung bei 40% weniger Verbrauch von Conroe zum PentiumD 950..
Dagegen verbraucht Excavator schon weniger Strom. Hoffentlich reichen die 40% mehr IPC. Ich bin leicht optimistisch :-)
edit:

Die Bristol Ridge Frequenzen sehen für 28nm ganz gut aus für 65Watt und IGPU

http://products.amd.com/Lists/APU/AllItems.aspx?Paged=TRUE&p_ID=199&PageFirstRow=96751&&View=%7BC155402C-EFC9-4976-98DD-79FDC5CF7F7B%7D

[S940]

Dass Ivy Bridge und Skylake in bestimmten Situationen (RAM bound, nicht mehr IPC rauszuholen, komische dependency chains die das größere ooo window negieren) langsamer sind als der jeweils direkte Vorgänger und dass das an der höheren RAM Latenz liegt ist doch bekannt? Gerade Skylake ist echt enttäuschend im Vergleich zu den internen Veränderungen. Keine Ahnung wieviel am L2 liegt, aber ich nehme an das hat Intel gern geopfert für mehr Kerne.

Jupp, wundert mich auch nicht soo stark. Der L3 wurde deutlich langsamer und der L2 um 1 Takt, sowie mit schlechterer Trefferrrate ausgestattet - sodass man häufiger auf den langsameren L3 zugreifen muss.

Mag bei "braven" Apps durch all die anderen Verbesserungen kaschiert werden, aber wenn man sah, wieviel Spiele von den größeren L3-Caches der Intel-6++Kerner profitieren und wie auch die AMD-Chips immer von NB-OC profitierten, dann ist das heiße Thema bei Games v.a. Cache+Speicherlatenz.

So gesehen wären noch fehlende Features ggü. Intel aus Gamer-Sicht möglicherweise ziemlich irrelevant - solange L2 und L3 passabel ausfallen.
Hoffen wir mal, dass der L2 ein paar Kohlen aus dem Feuer holt und die Rechenwerke nicht allzulange warten lässt. Ich hoffe auf <15 Takte.

[Schaffe89]

Ah, es wird wieder Zeit eine Argumentationskette auseinander zu nehmen.

Wo konnte eigentlich festgestellt werden, dass Blender für eine Leistungsmessung taugt? Eigentlich würde eher Ashes taugen, ist erstmal legacy Code und zweitens nicht von AMD ausgewählt.

Wo warst du die letzten 2 Seiten?

Hab mir das schon alles durchgelesen und mehrere Videos geschaut unter anderem das von Oromis usw.
Aber reicht das für eine klare abschließende Aussage? Finde ich eher nicht.
Es ist so absurd, dass AMD Broadwell IPC bei gleichem Takt erreichen soll.
Da sitzt entweder der Wurm im Detail und AMD µarchitektur und FPU ist besonders für diesen Benchmark zugeschnitten und verliert eher bei integerlastigen workloads.

Die Messungen eines Spiels wie Ashes of the Singularity sind mir eigentlich wesentlich sympathischer als ein von AMD ausgesuchter workload.
Gerade hier liegt ein 8C/16T Zen aber nochmal besser als im Blender auf der Straße. Bei vermuteten nur 3ghz Takt über alle Kerne gegenüber den 3,8ghz des Intelprozessors bei keiner stattfindenden Skalierung über 6 Threads, wäre das Ergebnis extrem gut. Viel zu gut leider, das wäre deutlich oberhalb der +40% mehr IPC, denn seit Piledriver hat sich bei AMD IPC mäßig bei Desktoptakraten kaum mehr etwas gerührt.

Erst wenn Excavator in Q4 als APU kommt, kann man sich mal ein Bild von der IPC von Excavator machen, nach meiner Informationslage ist diese bei Desktoptaktraten nicht erwähnenswert besser (~5%) wie Piledriver ohne L3 also Trinity.

Das erinnert mich an die Vorabbenchmarks von den früheren AMD Produkten und frappierend an den rx480 Launch. Erst locker und alles Top, dann später overall die Enttäuschung.

auch wenn die Argumentation bis jetzt völliger Schwachsinn war.

Ok danke.:D
Scheinbar fällt es nur mir auf wie astronomisch gut die Ergebnisse in diesen bisherigen Tests sind, im Verhältnis zu AMD´s +40% Promise?
Da müsste AMD ja tiefstapeln und das schafft AMD´s Marketing nicht, niemals. Das sind immer die gleichen Hyper.

Also die Ergebnisse die bisher vorliegen sind zu gut um wahr zu sein.
Wenn jetzt die Taktbarkeit noch gegen 4GHZ geht, dann steht mit diesen bisherigen minimalistischen Ergebnissen, einer "Konkurrenzfähigkeit" nicht mehr viel im Wege.

Davon gehe ich auch aus. Bringt Zen eine gute IPC in Spielen, sollte das generell so sein..
So war es ja immer schon, nur wenn man halt ein bisserle auf die Spiele schaut unter anderem auf PCGH Benchmarks, dann reichen +40% und ein offenbar konservativer Takt von maximal ~4ghz nicht aus um da ran zukommen.

[reaperrr]

Erst wenn Excavator in Q4 als APU kommt, kann man sich mal ein Bild von der IPC von Excavator machen, nach meiner Informationslage ist diese bei Desktoptaktraten nicht erwähnenswert besser (~5%) wie Piledriver ohne L3 also Trinity.
???
Es hat doch schon IPC-Vergleiche zwischen Trinity/Richland, Kaveri und Carrizo gegeben (Athlon X4 845 basiert auf CZ), Excavator hat bei gleichem Takt zwischen 15-20% mehr IPC als PD in den meisten Anwendungsfällen. Trotz zugunsten geringerem Verbrauch und geringerer Fläche halbiertem L2 pro Modul, was laut AMD ca. 5% IPC gekostet hat.

[Nightspider]

Skylake geht erst mit schnellen DDR4 richtig ab in Spielen. Anandtech testet games im GPU Limit, davon mal abgesehen. Für IPC Vergleiche sinnlos.

Gab es dazu im letzten halben Jahr eigentlich nochmal neue Tests irgendwo?

Imo wird noch viel zu selten und oberflächlich getestet wie sich der Speicher auf die CPU Performance auswirkt.

Manche Spiele zeigen mit eDRAM oder DDR-4000 ja scheinbar schon bis zu 20 oder gar 25% mehr Leistung im CPU Limit.

Bin mal gespannt ob Zen auch von so schnellem RAM profitieren wird.
Zen kommt ja mit Quad Channel Support wenn ich mich nicht irre oder?

[Isen]

Nein. 8/16 kommt mit Dual.
Naples hat quad respektive als 32/64er sogar Octa-Channel.

[iuno]

Bei Geekbench ist ein Ergebnis von einem 64C ES aufgetaucht: http://browser.primatelabs.com/v4/cpu/105227

Das Ergebnis ist nicht gut (und vermutlich ziemlich wertlos), aber die Entdeckung imho interessant.
Heisst "2 processors, 64 cores", dass es ein 2 Sockel System ist oder wird das MCM als 2 CPUs erkannt? :uponder: Imho schon ersteres oder? So ein Board wuerde ja auch kuerzlich gezeigt, fuer ein MCM wird es wohl noch etwas laenger dauern.

[Loeschzwerg]

Dual-Sockel, erkennt man an den Caches (trotz fehlerhafter Anzeige). Zwei 16 Kerner mit SMT?

Interessant ist auch die Bezeichnung "2S1451A4VIHE4_29/14_N" verglichen zu 1D2801A2M88E4_32/28_N und 2D2801A2M88E4_32/28_N.

Also "S" für Server und Boost bis 2.9GHz.

[Isen]

Heisst "2 processors, 64 cores", dass es ein 2 Sockel System ist oder wird das MCM als 2 CPUs erkannt? :uponder: Imho schon ersteres oder? So ein Board wuerde ja auch kuerzlich gezeigt, fuer ein MCM wird es wohl noch etwas laenger dauern.

Handelt sich um Dual Sockel, genau das, was AMD da gezeigt hatte.

Ach... zu lahm. ^^

In dem Bench @1.44 GHz noja :D

Irgendwie das Gefühl, dass es beim Desktop Zen bei 3,4Ghz All Core und 3,6 Boost handeln wird. Hoffentlich geht da mit OC noch was.

[BlackBirdSR]

Ist doch eine nette Möglichkeit, relativ einfach die Performance der CPU trotz Optimierungen 7nd leicht höherem Takt zu begrenzen.... ;)

Man will ja auch später nochmal 5% liefern, und nochmal und nochmal ;)


Jupp, wundert mich auch nicht soo stark. Der L3 wurde deutlich langsamer und der L2 um 1 Takt, sowie mit schlechterer Trefferrrate ausgestattet - sodass man häufiger auf den langsameren L3 zugreifen muss.

Mag bei "braven" Apps durch all die anderen Verbesserungen kaschiert werden, aber wenn man sah, wieviel Spiele von den größeren L3-Caches der Intel-6++Kerner profitieren und wie auch die AMD-Chips immer von NB-OC profitierten, dann ist das heiße Thema bei Games v.a. Cache+Speicherlatenz.

So gesehen wären noch fehlende Features ggü. Intel aus Gamer-Sicht möglicherweise ziemlich irrelevant - solange L2 und L3 passabel ausfallen.
Hoffen wir mal, dass der L2 ein paar Kohlen aus dem Feuer holt und die Rechenwerke nicht allzulange warten lässt. Ich hoffe auf <15 Takte.

[Schaffe89]

???
Es hat doch schon IPC-Vergleiche zwischen Trinity/Richland, Kaveri und Carrizo gegeben (Athlon X4 845 basiert auf CZ), Excavator hat bei gleichem Takt zwischen 15-20% mehr IPC als PD in den meisten Anwendungsfällen.

Kannst du den Test verlinken? Das würde mich doch jetzt ziemlich überraschen.
Nach den Tests von PCGH des Excavator Athlons hatte der im Vergleich zu Kaveri keinerlei IPC Steigerung, mutmaßlich !hoffentlich! natürlich wegen des halbierten L2.

[Setsul]

Wo konnte eigentlich festgestellt werden, dass Blender für eine Leistungsmessung taugt? Eigentlich würde eher Ashes taugen, ist erstmal legacy Code und zweitens nicht von AMD ausgewählt.
Intel empfiehlt Blender sogar im i7-6950X Evaluation Guide.

Hab mir das schon alles durchgelesen und mehrere Videos geschaut unter anderem das von Oromis usw.
Aber reicht das für eine klare abschließende Aussage? Finde ich eher nicht.
Es ist so absurd, dass AMD Broadwell IPC bei gleichem Takt erreichen soll.
Da sitzt entweder der Wurm im Detail und AMD µarchitektur und FPU ist besonders für diesen Benchmark zugeschnitten und verliert eher bei integerlastigen workloads.

Irgendwie läuft deine Logik rückwärts. Du legst fest, dass das Ergebnis zu gut ist, deshalb muss das Benchmark falsch sein.
So kann man sich natürlich auch die Welt zurechtlegen. Wenn deine Theorie nicht zu den Fakten passt, ändere die Fakten.


Die Messungen eines Spiels wie Ashes of the Singularity sind mir eigentlich wesentlich sympathischer als ein von AMD ausgesuchter workload.
Gerade hier liegt ein 8C/16T Zen aber nochmal besser als im Blender auf der Straße. Bei vermuteten nur 3ghz Takt über alle Kerne gegenüber den 3,8ghz des Intelprozessors bei keiner stattfindenden Skalierung über 6 Threads, wäre das Ergebnis extrem gut. Viel zu gut leider, das wäre deutlich oberhalb der +40% mehr IPC, denn seit Piledriver hat sich bei AMD IPC mäßig bei Desktoptakraten kaum mehr etwas gerührt.
Meine Güte ich hab dir doch gezeigt, dass AotS über 6 Kerne hinaus skaliert.
http://core0.staticworld.net/images/article/2016/02/dx12_cpu_ashes_of_the_singularity_beta_2_average_cpu_frame_rate_high_quality_19x 10-100647718-orig.png
Ignorierst du das einfach, weil dann das Ergebnis realistisch wäre?
Excavator hat auch sehr wohl höhere IPC als Piledriver.


Das ist jetzt aber auch mein letzter Post dazu, die Argumentation ist einfach bescheuert. Du versuchst es so hinzudrehen, dass Zen viel schneller ist als Haswell/Broadwell und weil das nicht sein kann müssen die Benchmarks falsch sein.
Wenn man realistisch ist, bei AotS auch die Skalierung bis 8 Threads miteinrechnet, Blender als best case für SMT ansieht, dann kommt man eigentlich zu dem Schluss, das Zen etwas unter Haswell IPC haben könnte. Taktraten wahrscheinlich auch etwas niedriger, aber insgesamt ist die Leistung dann eben doch noch recht konkurrenzfähig. Für HEDT wahrscheinlich -10-20% gegenüber Skylake-X, bei Servern kann man eventuell die Kerne ausspielen, wenn die Effizienz stimmt. Hab mich noch nicht damit beschäftigt, wie Skylake-E aussehen wird, ich nehme mal an 30 Kerne für HCC, 18-20 für MCC, bestenfalls 12-15 für LCC. Mit 32/24/16 Kernen könnte AMD Zen relativ gut positionieren.


@topic neues bench:
Das steht und fällt jetzt alles mit der TDP. 1,4/2,9 GHz bei 16 Kernen und 95W sind gut, bei 145W wirds schwierig. Also das Potential ist da. Mal sehen was GF fabriziert.

[Oromis16]

@Schaffe89
Im vorletzten Kapitel ist ein Vergleich Steamroller vs Excavator zu finden: http://extreme.pcgameshardware.de/prozessoren/438341-lesertest-athlon-5370-freilaufgehege-fuer-den-alten-jaguar.html

Ist nicht der ausführlichste Test - Thema war ja ein anderes - gibt aber eine Richtung an ;)

[S940]

Kannst du den Test verlinken? Das würde mich doch jetzt ziemlich überraschen.
Nach den Tests von PCGH des Excavator Athlons hatte der im Vergleich zu Kaveri keinerlei IPC Steigerung, mutmaßlich !hoffentlich! natürlich wegen des halbierten L2.

Äh Du vergisst dabei anscheinend, dass der L1-Cache dafür verdoppelt wurde.

Das war eins der größeren Probleme des BD-Designs. Nicht nur weil die Größe so winzig war, sondern auch weil es zuviel Bank-Konflikte gab, man in manchem Trefferfall also doch keine Daten Laden konnte :freak:

Die Halbierung des L2 fällt ggü. dem Verdoppelten L1 fast nicht ins Gewicht ;)

XV ist aus IPC-Sicht der beste BD, den es jemals gab.

[robbitop]

Und dennoch wäre ein 4M Excavator mit L3 Cache noch gute 20 % taktnormiert unter Sandy Niveau. Erst Steamroller/Excavator schafften es, K10 taktnormiert knapp zu schlagen.
Interessant wäre es wohl gewesen - aber man sieht wie dringend notwendig Zen ist und welche Sackgasse BD war. (auch wenn man bis Excavator noch einiges - insbesondere Perf/W - herausholen konnte. Am Ende erinnert es ein wenig an Intels Netburst. Intel holte über mehrere Iterationen noch einiges heraus - aber am Ende wird aus einem Traktor kein Rennwagen... :D)

[S940]

(auch wenn man bis Excavator noch einiges - insbesondere Perf/W - herausholen konnte.
Ja das lässt dann eben auch auf Zen hoffen, da die Techniken gleich bleiben.

Das Schlimmste was passieren könnte wäre eigentlich nur noch dass der Herstellungsprozess sch...lecht ist.

Ansonsten sehe ich keine Risiken mehr. Die Architektur ist topp, die Stromsparmodi samt HDLibs ebenfalls, jetzt ist GF am Zug ;)

@BlackBirdSR:
Ja kann man auch so sehen. TicToc wurde auch aufgegeben, da die Herstellungsprozesse hinterherhinken, also muss man anderweitig energiesparen um noch Reserven für den Kerntakt mobilisieren zu können.
Möglich, dass es mit 10/7nm dann wieder besser wird.

Dagegen spräche allerdings, dass die L3s seit Sandy immer langsamer wurden. Aber gut, vielleicht knauserte man sich in dem Fall die nötige Energie für die 256-Bit FPU an.

[Schaffe89]

Das ist jetzt aber auch mein letzter Post dazu, die Argumentation ist einfach bescheuert. Du versuchst es so hinzudrehen, dass Zen viel schneller ist als Haswell/Broadwell und weil das nicht sein kann müssen die Benchmarks falsch sein.

Ja gottseidank, deine unfreundliche Postauseinandernehmstrategie nervt auch ziemlich.
Natürlich ist Zen für das Ziel das AMD vorgegeben hat in den Benchmarks viel zu schnell, das wären keine 40% auf Excavator, sondern eher 60%, was eigentlich jedem mit etwas Realismus dazu anhalten würde diese Kirschen nicht so ernst zu nehmen.
Klar man kann sich nen Excavator, Kaveri whatever nehmen auf 2ghz untertakten und dann von den IPC Steigerungen schwelgen die im Desktopmarkt nicht ankommen, da das Design nicht nach oben skaliert mit mehr Takt.

Letztendlich steht man wieder dort dass man eigentlich gar nichts weiß, weder noch wie AMD die Leistung in Blender wirklich mit letzter Gewissheit erreicht hat.
Die haben damals Bulldozer im GPU Limit gebencht und das den Leuten gezeigt.


Dann kommt man eigentlich zu dem Schluss, das Zen etwas unter Haswell IPC haben könnte. Taktraten wahrscheinlich auch etwas niedriger, aber insgesamt ist die Leistung dann eben doch noch recht konkurrenzfähig.

Sollten Taktraten und IPC geringer sein als Haswell dann wird das nix mit konkurrenzfähig.

Das dürfte aber etwa der allgemeinen Erwartungshaltung entsprechen und die wird wie man AMD kennt, unterboten werden.


Äh Du vergisst dabei anscheinend, dass der L1-Cache dafür verdoppelt wurde.

Hab ich vergessen ja, umso schlimmer dann das Excavator nicht schneller ist.

[robbitop]

Man wird jedenfalls konkurrenzfähiger als heute sein. Wieder ein guter zweiter zu sein, sollte eigentlich reichen.

[HOT]

XV krankt an den selben Problemen wie die restliche BD-Familie, das hat sich nicht geändert. Das einzige, was wirklich durchschlägt ist mMn der vergrößerte L1D$, dafür gibts halt nen kleineren L2. Viele andere Probleme bleiben bestehen, insbesondere der scheiss-niedrige I/O-Takt und der fehlende L3$. Von daher ist das so gar nicht repräsentativ, wenn man Carrizo mit Kaveri vergleicht, die laufen beide mit angezogener Handbremse. Und mit vom "Sparsam" merkt man bei 3GHz+ auch nix mehr ggü. Kaveri, das wirkt sich nur im Mobil-Bereich aus. Viele Reviews bemängelten, dass die 65W für den 845 zu wenig sind. Wie will man denn da einen Schluss auf die letztendliche XV-IPC ziehen? Das ist doch schwer abenteuerlich.
Bei Zen ist auch die APU ne ganz andere Liga, denn die wird 8MB L3$ haben. Zen mag 40% mehr IPC pro Kern haben. Diese Größe ist ja gut und schön und vergisst, dass I/O bei den bisherigen APUs ne völlige Katastrophe war und sich ebenfalls sehr stark auf die Geschwindigkeit auswirkt.

[y33H@]

Mal was anderes ... die ersten Southbridges bzw Controller Hubs für Sockel AM4 wurden vorgestellt: http://www.golem.de/news/bristol-ridge-amd-veroeffentlicht-erste-apus-und-chipsaetze-fuer-sockel-am4-1609-123089.html

http://scr3.golem.de/screenshots/1609/Bristol-Ridge-AM4-A320-B350/thumb620/Bristol-Ridge-AM4-A320-B350-07.png

[HOT]

Hm. Das scheint nicht Vollausbau von Promontory zu sein, für Enthusiast wird offenbar noch einer vorgestellt, dort ist auch noch kein Name bekannt (Vielleicht FX370? :D).

[y33H@]

Ja, ein X3xx-iwas kommt noch. Wobei ein Board mit B350 für die allermeisten Leute völlig ausreicht, mich eingeschlossen.

[HOT]

Richtig, solange es keine bescheuerten Einschränkungen gibt, wie bei Intels H-Serie.

[Timbaloo]

Eben. 2 * USB 3.1, 6 * USB 3.0, 6 * USB 2.0, 2 * SATA reicht mir lockerstensten.

[y33H@]

Sogar 4x Sata, wenn man kein Sata Express nutzt (was gefühlt keiner macht).

[HOT]

Ich nehme an, es wird eher auf 2 4 4 hinauslaufen, die Gesamtzahl der USB-Ports wird sicherlich die 2. Ausbaustufe schon bieten. Und man wird sicherlich 2 SATA-Express in der Maximalstufe bieten. Die 6 freien Lanes werden bleiben.

Interessantes Detail am Rande: BR schafft ist in 28nm SHP 1108 MHz Takt für die 8 CUs zur Verfügung zu stellen in einem 65W-Prozessor. Vielleicht hätte AMD Tonga und Fiji mal besser in 28nm SHP aufgelegt, die wären wegen GateFirst auch noch kleiner obendrein gewesen :D. Irgendwie scheinen die kein so richig glückliches Händchen bei den Fertigungsprozessen zu haben.

[YfOrU]

Mal was anderes ... die ersten Southbridges bzw Controller Hubs für Sockel AM4 wurden vorgestellt:
...

Womit sich dann auch endgültig bestätigt das die alten FM3 Folien zutreffen:
https://benchlife.info/wp-content/uploads/2015/06/amd-soc-and-promontory-chipset-io-coverage-1024x724.jpg

Gegenüber der vorläufigen Planung von damals gibt es bei Essentials und Mainstream jeweils einen aktiven USB 3.1 G2 Port mehr.

[S940]

Ja, ein X3xx-iwas kommt noch. Wobei ein Board mit B350 für die allermeisten Leute völlig ausreicht, mich eingeschlossen.

Die SFF-Version ist ja mal nett, bekommt nen Namen X/B/A300 aber dürfte faktisch ein Phantomchip sein, da nur die Anschlüsse der APU benutzt werden.

Oder wie sonst soll man die "--" bei den Features deuten? Hat das Teil vielleicht noch nen Keyboardkontroller oder sonstigen Kleinkrams?

Also ich würd mich über billige High-End Boards ohne Chipsatz freuen ;)
Topp VRMs, kein Gedöns, n paar USB und 2 SATA, reicht.
Falls man dochmal was brauchen sollte ,muss halt ne I/O Karte in nen PCIe x1-Slot wandern.

[mczak]

Interessantes Detail am Rande: BR schafft ist in 28nm SHP 1108 MHz Takt für die 8 CUs zur Verfügung zu stellen in einem 65W-Prozessor. Vielleicht hätte AMD Tonga und Fiji mal besser in 28nm SHP aufgelegt, die wären wegen GateFirst auch noch kleiner obendrein gewesen :D
Kommt darauf an ob da der Takt wirklich gehalten werden kann (wenn die CPU auch noch hohe Last hat). Die 15W Carrizos haben ja auch einen Maximal-GPU-Takt von 720Mhz und in der Praxis dümpeln die so bei 400Mhz herum.
Wenn der Turbo aber so funktioniert dass die 65W auch allein die GPU verbraten darf und man womöglich selbst dann den Maximaltakt nicht immer halten kann wäre das nicht so besonders (das wären dann über "8W/CU" - Fiji und Tonga liegen deutlich darunter).

[Menace]

Alles ziemlich nett, aber meine Erfahrung waren bisher, dass ich gar nicht genug SATA-Steckplätze haben kann. Von daher mal auf das 990 Äquivalent warten.

[ndrs]

Es steht doch den Herstellern frei über PCIe zusätzliche Controller anzuschließen.

[S940]

Alles ziemlich nett, aber meine Erfahrung waren bisher, dass ich gar nicht genug SATA-Steckplätze haben kann. Von daher mal auf das 990 Äquivalent warten.

Wozu? Für den Anschluss des Chipsatzes gehen 4 PCIe-Lanes drauf.
D.h. ohne Chipsatz und dem Noteinsatz der SoC-Anschlüsse bleiben diese 4 Lanese übrig die man einfach an nen x4 PCIe-Slot führen könnte. Dort könnten I/O-Hardcoreuser wie Du dann ne Karte mit >10 SATA-Steckplätzen und >20 USB reinstecken. ;)

Den 08/15 Usern, die sowieso schon USB-Verteiler haben (z.B. im Monitor) und nicht mehr als 2 Sata-Anschlüsse brauchen (USB3 ist ja auch schon relativ schnell und reicht z.B. für ne 3TB-Datengrabplatte), müssten dann weniger fürs Board bezahlen und würden über den gesasmten Nutzungszeitraum die ~5W Verbrauch des Chipsatzes einsparen.

Klar die Karte käme im Endeffekt natürlich teurer, da die "Subventionen" der Nutzer fehlen würden, die für den Chip zwar zahlen, ihn aber nie nutzen. Die Herstellungskosten wären auch größer, da man ne extra Platine braucht.
Aber der, der was braucht, bezahlt sicher gerne dafür ;)

[Botcruscher]

Es ist ja 2+1. Für den Normalo mehr als ausreichend. DVD Laufwerk, SSD, HDD.
Wer mehr Laufwerke benutzt sollte eh dringend über einen Heimserver nachdenken. Der hat von Verbrauch, Datensicherheit bis Verfügbarkeit nur Vorteile.

[tm0975]

ich verwende intern gar keine hdd mehr. ssds sind doch jetzt selbst bis zum TB erschwinglich. Für nen richtiges datengrab (Bilder, Filme) ist mMn eine externe Variante mit usb 3.0 viel praktischer.

[StefanV]

Alles ziemlich nett, aber meine Erfahrung waren bisher, dass ich gar nicht genug SATA-Steckplätze haben kann. Von daher mal auf das 990 Äquivalent warten.
Och, da gibts doch was richtig nettes (http://geizhals.de/delock-54668-a1460254.html?hloc=de), oder sowas (http://www.addonics.com/products/adsau3.php), oder was mit SAS (http://geizhals.de/highpoint-rocketraid-2680-a380035.html?hloc=de)...

Oder das hier (http://geizhals.de/delock-89384-a1256212.html?hloc=de)...

[S940]

Es ist ja 2+1. Für den Normalo mehr als ausreichend. DVD Laufwerk, SSD, HDD.
Wer mehr Laufwerke benutzt sollte eh dringend über einen Heimserver nachdenken. Der hat von Verbrauch, Datensicherheit bis Verfügbarkeit nur Vorteile.
Ach genau, den NVMe-Port gibts ja auch noch.
ich verwende intern gar keine hdd mehr. ssds sind doch jetzt selbst bis zum TB erschwinglich. Für nen richtiges datengrab (Bilder, Filme) ist mMn eine externe Variante mit usb 3.0 viel praktischer.Jo das kommt dazu.
Naja wengistens AsRock wird hoffentlich high-end Board ohne Chipsatz bringen ;)

[Sunrise]

...Klar man kann sich nen Excavator, Kaveri whatever nehmen auf 2ghz untertakten und dann von den IPC Steigerungen schwelgen die im Desktopmarkt nicht ankommen, da das Design nicht nach oben skaliert mit mehr Takt.
Du gehst also davon aus, dass Zen schlechter als Bristol Ridge wird, was die Taktbarkeit angeht (der auch noch eine GPU mit an Bord hat), und das aufgrund eines einzigen Benches im Vergleich zu einem bereits veröffentlichten Intel-Produkt, also ein Vergleich von einem Zen-ES der mit einem finalen massenmarktfähigen Produkt verglichen wird? Alles unter dem zusätzlichen Hintergrund, dass AMD betont hat, dass die Taktraten noch nicht final sind?

[Rabiata]

Du gehst also davon aus, dass Zen schlechter als Bristol Ridge wird, was die Taktbarkeit angeht (der auch noch eine GPU mit an Bord hat), und das aufgrund eines einzigen Benches im Vergleich zu einem bereits veröffentlichten Intel-Produkt, also ein Vergleich von einem Zen-ES der mit einem finalen massenmarktfähigen Produkt verglichen wird? Alles unter dem zusätzlichen Hintergrund, dass AMD betont hat, dass die Taktraten noch nicht final sind?
Schaffe89 spekuliert hier im Nebel rum, keine Frage :wink:.

Aber anders herum gibt es auch noch keine Gewißheit, daß Zen die Taktraten von Bristol Ridge schafft, immerhin ist die CPU-Architektur ein andere. Ich bin zwar optimistisch, aber würde mich da noch nicht festlegen...