Wie seht ihr die derzeit unterschiedlichen Architekturen von AMD und INTEL?

[Holt]

4,8 Mrd. Transistoren sind schon heftig.

Wobei den Zählweisen von Transistoren unterschiedlich sind.

klar können die 16 Kerne den Takt mitgehen, bei fast der doppelten TDP.

Die TDP sagt nichts über die Leistungsaufnahme aus, schau Dir die Reviews der RYZEN7 oder des i7 7700T.

Ob AMD die Zen-Architektur wirklich kontunuierlich mit double-digit Sprüngen in Sachen IPC versorgen kann, wird die Zukunft zeigen.

Meines Wissens spricht AMD selbst nur von double-digit Leitungssteigerungen, also IPC + Takt.

Du wirst nicht EIN Beispiel finden wo der Intel 4 Kerner an einem AMD 8 Kerner (Ryzen) vorbeizieht wo er nicht auch an Intel 8 Kernern vorbeizieht => CCX-Latenz ist für dieses Phänomen unerheblich.

Doch:
Hier ist Intels 8 Kerner vor dem schnellsten Intel 4 Kerner der ebenso wie der ältere i7 6700 noch wiederrum aber vor dem schnellsten RYZEN liegt.

Hier hängt der R7 1800X den i7 6700 ab, aber nicht den i7 7700K.

Fest steht eines , AMD kann die 2 x 8 Kern Die s des Threadripper günstiger produzieren als Intel den 18 Kern Die

Das ist klar, daher macht AMD ja auch ein MCM mit 2 Dies.

allerdings sind es ja nur umgelabelte Xenon , vielleicht wird ja auch die 22 Kern Maske genommen und der Ausschuss ( teildeaktivierte ) Cpu s landen dann auf dem X299 Board .

Wieso allerdings? Die Xeons sind mit Sicherheit besser validiert als jede Consumer CPU. Dann sind CPUs die nicht alle Kerne haben die ihre Masken hergeben auch Ausschuss, sonst wären ja auch alle RYZEN 5 nur Ausschuss. Es lohnt sich nur eben nicht für jedes SKU eingene Masken entwicklen zu lassen, die kosten nämlich sehr, sehr viel Geld und man braucht hohe Stückzahlen um die Kosten dafür wieder einspielen zu können. Damit man aber nicht nur ein oder zwei Modelle anbieten kann, werden eben auch Kerne deaktiviert um die Modellvielfalt zu erhöhen und ob diese deaktivierten Kerne nun funktionsfähig sind oder nicht, spielt letztlich keine Rolle. Die resultierenden CPUs haben eben eine bestimmte Anzahl an funktionsfähigen Kernen und werden genau als CPUs mit so vielen Kernen verkauft. Das hier auch eine Resteverwertung stattfindet ist ja für die Kunden kein Nachteil, die deaktivierten Kerne können sowieso heutzutage nicht mehr freigeschaltet werden und durch die Resteverwertung sinken die Kosten.

ne 18 Kern Server cpu kostet 4500 Dollar da ist ne 2000 Dollar Desktop CPU ja noch nen Schnäppchen

Ein 18 Kern Intel Xeon E5-2695 v4 wird derzeit bei Geizhals ab 2266€ gelistet, aber die Wahrheit ist Leuten wie Dir ja nicht wichtig denen es nur um die Propaganda geht.

Ich vermute ja dass der AVX-Takt da geringer ist bei Ryzen. Einen 1700 mit 3.6 Ghz Allcore schlage ich mit 4.8 Ghz auf dem 7700K. Das ist schon außergewöhnlich.

Das RYZEN bei AVX eine Schwäche hat, sieht man ja schon an der Leistungsaufnahme unter Last, die war bei dem 1800X im Review hier bei CB gerade mal um 9W höher, während sie beim 6900K um 56W höher lag. Da von nichts nichts kommt und auch AMD keine Wunder vollbringen kann, dürfte dies ein Hinweis auf weniger Leistung bei Nutzung von AVX sein. Wenn man die Nutzung von AVX Befehlen auch deaktivieren kann, sollte man dies mal machen und dann die Ergebnisse vergleichen.

wieso ? wenn bekannt ist wie hoch der IPC Vorteil von Intel ist ( 10 % ) kann man das schon machen wenn man die Multicorerechenleistung abschätzen will .

Nein, auch dann kann man es nicht machen, da erstens Anwendungen nie linear über mehr Kerne skalieren und zweitens diese Nichtlinearität auch noch von CPU zu CPU und Anwendung zu Anwendung deutlich schwankt.

konkrete Resultate bekommt man natürlich nur beim direkten vergleich und mit dem Intel 16 Kerner wird das dieses Jahr nichts mehr

Das ist nicht sicher, andere Gerüchte sprechen davon diese könnten auch schon im August kommen.

Bei x264 ist alles "normal".

Obwohl dies schon länger in HW von Intels iGPUs unterstützt wird, nur muss die SW diese HW Unterstützung eben auch nutzen. Auf der 5. Seite des Thread bei 3dcenter findet sich ein i5-6440HQ der x265 Singlethread 2.29 fps schafft (x264: 3.54 fps+3.91 fps) und ein i7-7700K der auf 2.48 fps (x264: 4.09 fps + 4.22 fps) kommt. Das Verhältnis stimmt also, da wird bei keinem der beidem eine besondere HW Unterstützung für x265 genutzt.

 

[Iscaran]

Ja. das x265 "Problem" ist eher ein Problem mit der Umsetzung von AVX:

http://www.agner.org/optimize/blog/read.php?i=838

256-bit vector instructions (AVX instructions) are split into two micro-ops handling 128 bits each. Such instructions take only one entry in the micro-operation cache. A few other instructions also generate two micro-ops. The maximum throughput of the micro-op queue after the decoders is six micro-ops per clock. The stream of micro-ops from this queue are distributed between ten pipelines: four pipes for integer operations on general purpose registers, four pipes for floating point and vector operations, and two for address calculation. This means that a throughput of six micro-ops per clock cycle can be obtained if there is a mixture of integer and vector instructions.

Let us compare the execution units of AMD's Ryzen with current Intel processors. AMD has four 128-bit units for floating point and vector operations. Two of these can do addition and two can do multiplication. Intel has two 256-bit units, both of which can do addition as well as multiplication. This means that floating point code with scalars or vectors of up to 128 bits will execute on the AMD processor at a maximum rate of four instructions per clock (two additions and two multiplications), while the Intel processor can do only two. With 256-bit vectors, AMD and Intel can both do two instructions per clock. Intel beats AMD on 256-bit fused multiply-and-add instructions, where AMD can do one while Intel can do two per clock. Intel is also better than AMD on 256-bit memory writes, where Intel has one 256-bit write port while the AMD processor has one 128-bit write port. We will soon see Intel processors with 512-bit vector support, while it might take a few more years before AMD supports 512-bit vectors. However, most of the software on the market lags several years behind the hardware. As long as the software uses only 128-bit vectors, we will see the performance of the Ryzen processor as quite competitive.

The AMD can execute six micro-ops per clock while Intel can do only four. But there is a problem with doing so many operations per clock cycle. It is not possible to do two instructions simultaneously if the second instruction depends on the result of the first instruction, of course. The high throughput of the processor puts an increased burden on the programmer and the compiler to avoid long dependency chains. The maximum throughput can only be obtained if there are many independent instructions that can be executed simultaneously.

This is where simultaneous multithreading comes in. You can run two threads in the same CPU core (this is what Intel calls hyperthreading). Each thread will then get half of the resources. If the CPU core has a higher capacity than a single thread can utilize then it makes sense to run two threads in the same core. The gain in total performance that you get from running two threads per core is much higher in the Ryzen than in Intel processors because of the higher throughput of the AMD core (except for 256-bit vector code).

Ich vermute der x265 nutzt AVX-512bit. Der Intel Kann das ca. doppelt so schnell rechnen wie der Zen.

Jetzt nimm noch mal die SingleCore x265 Werte.

Ryzen 1700@3.9GHz ~ 1.9FPS
i7-7700K@4.4GHz ~ 2.9 FPS

2.9/1.9 = 1.52
Taktvorteil i7 = 4.4/3.9 =13% => die IPC ist überproportional hoch beim i7.
Das hat noch nichts mit CCX-Latenz zu tun da diese bei der Nutzung von nur 1 Kern nicht auftritt. (Der Ryzen cache ist gesplittet in 2x8 MB Segmente, jeweils 8MB Pro CCX).

Entweder das Programm bzw. die AVX umsetzung nutzt nun irgendwie bei SingleCore statt 8MB Cache nun dennoch 16MB (fluten des Caches) was relativ einfach vermieden werden kann oder es liegt an der langsameren Abarbeitung der AVX-Befehlsketten im Ryzen. Welche wenn ich Agners Ausführung korrekt verstehe ziemlich genau nur halb so schnell ist wie Intels AVX-512

Weiterhin ist auffälig das "MultiThread-AVX" nur mit einem Faktor von ~8,... skaliert und einem Faktor von 4,... bei Intel...=> bei beiden wird oder kann nicht SMT/HT effektiv genutzt werden. Was eigentlich im klaren Widerspruch zu Agner Fogs befunden steht.
Ich vermute mal man wird den x265 encoder hier irgendwo nicht richtig umgesetzt haben - was eine massive Performancebremse ist. Sowohl bei Intel (könnte ja einen MT-scaling von ca. 6 haben) als auch bei AMD (hier wären eigentlich ca Faktor 12 denkbar mit 16 Kernen).

Andere Video-Encoder haben ja scheinbar das Problem nicht.


@Holt:

Photoshop ist AFAIK eine fast reine "single"-Thread Gurke....
Auch habe ich keine Ahnung ob hier überhaupt dieselben "optimalen" Befehlssätze genutzt werden. + Fehlende nähere Angaben zu Takt und Kernauslastung machen es also schwierig in dem Beispiel zu sagen das ist ein "CPU"-Limit oder das ist eher ein Software problem...

Aus meiner Erfarhung mit Photoshop würde ich eher auf letzteres Tippen. Photoshop ist total Intel und 2 Thread optimiert....das ist das Problem und nicht die CCX-Latenz

Ergänzung (10. Juni 2017)

Hier mal Leute die das ganze mit Nutzung der Unterschiedlichen Befehlssätze mal analysierten:
https://forum.doom9.org/showthread.php?t=174383&page=6

Results x265:
Haswell-2C/2T@3.0GHz -> 5.54 fps
Sandy-2C/2T@3.0GHz -> 3.24 fps


Results FlopsCPU:
Haswell (Single core)-1C/1T@3.0GHz
x86 48 MFLOPS
x87 3.18 GFLOPS
SSE2 7.49 GFLOPS
AVX 14.3 GFLOPS
AVX2 24.1 GFLOPS

Sandy (Single core)-1C/1T@3.0GHz
x86 40.7 MFLOPS
x87 3.09 GFLOPS
SSE2 7.03 GFLOPS
AVX 13.7 GFLOPS

AVX2 optimizations gain for x265 on Intel hardware is ~71% using the same clock, which is absolutely amazing (!)

Jetzt brauchen wir nur mal so eine Liste für eine Ryzen CPU:

Oder einfach diese nette Grafik:
http://i.imgsafe.org/41ba1e2822.png

Ryzen @AVX ~3Flops/Hz mit AVX-2 ~4.86Flops/Hz
Kaby @AVX ~5.6Flops/Hz mit AVX-2 ~9.5Flops/Hz
Und wir sehen die AVX2-IPC von KabyLake ist ca Faktor 2 wie die von Ryzen. MicroArch bedingt. Das hat nichts mit der CCX-Anbindung zu tun sondern einzig und allein mit der Art wie Bit für Bit die CPU die Befehle abarbeiten kann (siehe Agner Fog).

In der Tat hat Ryzen also eine gewisse AVX Schwäche. Welche sich beim Encoding in gewisser weise zeigt. Dennoch sind die Ryzens immer noch schneller als die 4Kerner von Intel - einfach wegen der Vielen Kerne.

EDIT: Eine mögliche Erklärung für die ca 50% IPC Bremse:
Eine kleine fehlende Compiler optimierung...die AVX-Befehle @Ryzen müssen gesplittet werden in 2x128 bit...ansonsten läuft die CPU nur mit 50% Last...was man auch findet.
https://forum.doom9.org/showpost.php?p=1800634&postcount=22

I might have an explanation of that almost 1/2 performance of Ryzen compared to Intel for AVX1 (FP32/FP64) which can be seen as only 25% gain over SSE2 code for Ryzen.

The Intel compiler probably expects only 2 execution units for AVX, because Intel's HW has only 2.

So, it gives 1x256bit FADD AVX instruction to 1x128bit FADD AVX instead of 2x128bit FADD AVX that Ryzen has, because it thinks there is only 1 FADD inside.

So instead of splitting the 256bit instruction to 2x128bit registers in order to work simultaneously, now the 128bit register has to process two times the same 256bit instruction.

The same of course goes for FMUL, but I think the compiler can give two FMULs at the same time due to Intel's HW capability, so that's why we don't have exactly half performance but a little lesser.

That would explain the performance loss and I think is feasible for Intel to change/patch that behavior of its compiler or for AMD to do that automatically maybe with a microcode update (?).

 

[IchoTolot]

Danke für deine Mühe! =-O :-) Zeigt aber auch wieder deutlich dass bei Intel eben NICHT alles immer gleich ist bei den neuen CPUs nur weil es so aussieht. Es wird bei jeder CPU optimiert und das Intel hier so übermäßig stark ist bei AVX zeigt dass sie den Blick auf die Zukunft haben. Von AVX512 werden sie gewiss noch krasser profitieren, sehr gut. Für mich zeigt sich hier, dass Intels CPUs viel diffizielerdesignt designt und durchdacht sind als es immer den Anschein hat.

Mit drängt sich da der Vergleich auf von Ryzen als plumpem 8 Zylinder mit viel Hubraum als Ford Mustang und Intel als hochkomplexem Turbomotor quasi als Porsche Turbo, der viel mehr Performance auf die Straße bringen kann bei auf den ersten Blick weniger Leistung.

 

[aldaric]

Mit drängt sich da der Vergleich auf von Ryzen als plumpem 8 Zylinder mit viel Hubraum als Ford Mustang und Intel als hochkomplexem Turbomotor quasi als Porsche Turbo, der viel mehr Performance auf die Straße bringen kann bei auf den ersten Blick weniger Leistung.

Was für ein Schwachsinn.

 

[Iscaran]

@icho
Nein die Kernaussagen ist dass der (Intel) Compiler eben ein klein wenig Tuning braucht um die Design Differenzen zwischen Core und Zen Architektur korrekt zu nutzen. Zen wird hier quasi künstlich bzw. unnötig gebremst weil die avx Befehle nichtkorrekt gesplittet werden

 

[IchoTolot]

Das verstehe ich nicht, muss ich gestehen. Was hat der Codec mit Intel zu tun? Wenn überhaupt müsste bei den Codecentwicklern vielleicht was gepatched werden, aber das bleibt eben abzuwarten.

 

[Holt]

Ich vermute der x265 nutzt AVX-512bit. Der Intel Kann das ca. doppelt so schnell rechnen wie der Zen.

Da die aktuellen Intel CPUs außer dem Knights Landing Xeon Phi (von denen keiner dabei war) dies noch nicht unterstützen, es kommt erst mit dem Skylake-X, kann diese Vermutung als widerlegt angesehen werden.

Entweder das Programm bzw. die AVX umsetzung nutzt nun irgendwie bei SingleCore statt 8MB Cache nun dennoch 16MB (fluten des Caches) was relativ einfach vermieden werden kann

Da wären wir dann wieder bei der langsamen Intel CCX Kommunikation, die eben von der zusätzlichen Latenz gebremst wird die auftritt, wenn die Kerne oder der L3 Cache nicht auf dem kleinen CCX sind. Nur wie lässt das bitte einfach vermeiden? Dies wäre einfach zu vermeiden, würde AMD beide CCX z.B. als eigene NUMA Nodes deklarieren, auch wenn sie natürlich keine wirklichen NUMA Nodes sind, sich aber eben in der Hinsicht so verhalten. Dann könnten die Programme anfragen welche Kerne zu einem CCX gehören, aber wie geht das nun beim RYZEN heute? Ich keine da keine API die diese Information liefert. Ansonsten wäre es an AMD zu verhindern das ein Kern auch den Cache eines anderen CCX nutzen kann.

oder es liegt an der langsameren Abarbeitung der AVX-Befehlsketten im Ryzen. Welche wenn ich Agners Ausführung korrekt verstehe ziemlich genau nur halb so schnell ist wie Intels AVX-512

Da AVX-512 wie gesagt bei den in Frage kommenden Intel CPUs noch gar nicht vorhanden ist, kann es also daran nicht liegen.

Weiterhin ist auffälig das "MultiThread-AVX" nur mit einem Faktor von ~8,... skaliert und einem Faktor von 4,... bei Intel...=> bei beiden wird oder kann nicht SMT/HT effektiv genutzt werden. Was eigentlich im klaren Widerspruch zu Agner Fogs befunden steht.

Hier könnte auch ganz banal das RAM Interface limitieren.

Photoshop ist AFAIK eine fast reine "single"-Thread Gurke....

Und weswegen gewinnt dann der i7-6900K mit mehr Kernen gegenüber dem i7-7700K mit mehr Takt? Wäre es so sehr von der Singleperformance abhängig, wäre dies wohl kaum der Fall.

Eine mögliche Erklärung für die ca 50% IPC Bremse:
Eine kleine fehlende Compiler optimierung...die AVX-Befehle @Ryzen müssen gesplittet werden in 2x128 bit...ansonsten läuft die CPU nur mit 50% Last...was man auch findet.

Dann verliert man aber den Vorteil von 256 Bit AVX Befehlen und hätte sich deren Einführung sparen können, nur weil AMD die AVX Einheit zu knapp ausgelegt hat.

@icho
Nein die Kernaussagen ist dass der (Intel) Compiler eben ein klein wenig Tuning braucht um die Design Differenzen zwischen Core und Zen Architektur korrekt zu nutzen. Zen wird hier quasi künstlich bzw. unnötig gebremst weil die avx Befehle nichtkorrekt gesplittet werden

Wenn RYZEN so einen Rückschritt der Programmierung für mehr Leistung braucht, wäre es an AMD einen entsprechend optimierten Compiler zu bauen. Von Intel sollte man nun wirklich nicht verlangen den eigenen Compiler auch noch auf Einschränkungen der Architektur des Wettbewerbers optimieren zu müssen. Wenn die CPU angibt 256 Bit AVX zu unterstützen, dann kann und sollte ein Compiler diese auch nutzen, da sie ja geschaffen wurden um schneller als die 128 Bit AVX Befehle zu sein und dies bei Intel ja auch sind.

Da Du die Latenzen der Kommunikation zwischen den CCX als Problem ja bestreitest obwohl die ja z.B. Deiner eigenen Aussage nach beim NVidia Treiber eine Rolle spielt, überlege mal warum Games die ja besondern darunter leiden hohen RAM Taktraten und damit einem hohen Takt der Fabric, also einer geringeren zusätzlichen Latenz, dann besonders stark profitieren. Einen Test mit Photoshop bei unterschiedlichen RAM Frequenzen aber sonst gleichen CPU Einstellungen habe ich leider bisher nicht gefunden, aber der wäre auch mal sehr aufschlussreich.

 

[IchoTolot]

@icho
Nein die Kernaussagen ist dass der (Intel) Compiler eben ein klein wenig Tuning braucht um die Design Differenzen zwischen Core und Zen Architektur korrekt zu nutzen. Zen wird hier quasi künstlich bzw. unnötig gebremst weil die avx Befehle nichtkorrekt gesplittet werden

Intel ist hier einfach besser das zu nutzen und AMD hat offenbar eine Limitierung bei diesen Befehlssätzen. Hier wird Ryzen nicht künstlich gebremst, er bremst sich selber.

Ergänzung (10. Juni 2017)

Ich hab endlich den Test gefunden den ich schon mal gesehen hab. Bei Planet3dnow haben die das mal sehr ausführlich getestet.



http://www.planet3dnow.de/cms/30520-ryzen-7-1800x-teil-2/subpage-tiefenanalyse-der-architektur/

Und hier sieht man auch, dass der Durchsatz bei Kaby Lake um Welten größer ist als bei Ryzen. Die Latenz zur Ausführung ist zwar sogar etwas geringer als bei KL aber der Durchsatz ist einfach viel zu gering. Das ist leider eine Limitierung die Ryzen hat. Bei anderen Befehlssätzen ist er ja gut dabei.

Ergänzung (10. Juni 2017)

EDIT: Eine mögliche Erklärung für die ca 50% IPC Bremse:
Eine kleine fehlende Compiler optimierung...die AVX-Befehle @Ryzen müssen gesplittet werden in 2x128 bit...ansonsten läuft die CPU nur mit 50% Last...was man auch findet.
https://forum.doom9.org/showpost.php?p=1800634&postcount=22

Das passiert sogar, ändert aber nichts.

"Dennoch schafft es Ryzen – trotz interner Ausführung von 256-bit-Befehlen als zwei 128-bit Micro-Ops – dabei eine geringere Durchschnittslatenz vorzuweisen."

http://www.planet3dnow.de/cms/30520-ryzen-7-1800x-teil-2/subpage-tiefenanalyse-der-architektur/

Ergänzung (10. Juni 2017)

Planet3dNow hat hier meiner Ansicht nach auch das beste Review von Ryzen abgeliefert. Keiner ist so tiefgehend, davon können sich andere eine Scheibe abschneiden.

 

[aldaric]

Du solltest wirklich erstmal verstehen was Iscaran gesagt hat, bevor du wieder solche Aussagen wie "Intel ist hier einfach besser das zu nutzen und AMD hat offenbar eine Limitierung bei diesen Befehlssätzen. Hier wird Ryzen nicht künstlich gebremst, er bremst sich selber." triffst.

Intel ist der Entwickler dieses Compilers, natürlich wird der Compiler nicht auf die Konkurrenz angepasst. Deine Aussage das er sich selber bremst ist also einfach falsch.

Und Planet3dNow als das beste Review zu bezeichnen ist schon sehr übertrieben.

 

[Holt]

Es gibt ja nicht nur den Intel Compiler, sondern auch zahlreiche andere und AMD arbeitet z.B. in der Hinsicht eng mit Microsoft zusammen und bei dem Open64 Compiler. Es Intels Compiler macht gar nichts falsch und muss auch nicht auf RYZEN optimiert werden indem 256 Bit AVX Befehle in zwei 128 Bit aufgeteilt werden, da die CPU dies schon selbst macht. Wie man sieht kommt RYZEN bei den 128 Bit Befehlen auch nicht auf den doppelten Durchsatz wie mit 256 Bit Befehlen, eine solche Aufteilung im Compiler wäre als eine Verschlechterung und keine Verbesserung.

 

[Iscaran]

1.) Es gibt einen compiler:
http://developer.amd.com/tools-and-sdks/cpu-development/amd-optimizing-cc-compiler/
2.) Laut Agner Fog kann AMDs Ryzen 4 AVX micro-ops simultan - laut dem Intel Compiler werden die Befehle aber so verpackt dass nur 2 Parallele AVX abgeschickt werden.
3.) Deswegen weil bei Ryzen nur 2 AX Micro-ops abgeschickt werden obwohl die CPU 4 könnte liegen ca. 50% der CPU-AVX-Teile brach...
4.) => 50% Performance niedriger, Man sieht dass die "CPU"-Last bei x265 encodierung @ryzen bei ca. 50% liegt. Wohingegen die Intel CPUs auf ca 100% kommen.
(siehe Doom9 forum Ausführung von NikosD und Sagittaire)
https://forum.doom9.org/showpost.php?p=1800624&postcount=21

There is an issue here.
It seems that optimized Intel FP SIMD SSE2/AVX/AVX2-FMA3 code has a weird behavior running on AMD RyZen.
From SSE2 to AVX, Intel gains ~100% performance, RyZen gains 25%

Dies ist eigentlich nicht möglich wenn AMD, und das sagt Agner Fog ja in seinen Tests tatsächlich 4x128 AVX parallel abarbeiten kann.
Das entspricht genau 2x256 und ist ca. das gleiche wie intels möglichkeit 2x256 AVX parallel zu bearbeiten +- ein bisschen weil der Aufwand für 4 microops etc. vielleicht ein bisschen größer ist.

Verstehst du jetzt ....es gibt technische eigentlich KEINEN Grund warum AMDs Ryzen ~50% weniger AVX durchsatz haben sollte. Es sei denn die Software nutzt die CPU nicht richtig.
Der Grund dafür ist dass der x265 encoder mit dem Intel GCC Compiler erstellt wird, welcher nunmal AVX -256 code Pfade nur auf maximale 2x256 parallele Arbeit verteilt. AMD bräuchte hier aber 4x128 parallel um "korrekt" zu funktionieren.

 

[IchoTolot]

Warum baut AMD dann seine CPU so, dass man nur auf 128-bit breite FPU-Einheiten setzt? Warum nicht wie bei Intel direkt 256 Bit? Stattdessen wird jetzt diskutiert was andere wieder ändern müssen, damit Ryzen performt. ^^ Man hat es bei Ryzen wohl aus Platzgründen gemacht, soweit ich das googlen kann. Dann muss man mit dieser Limitierung begründet in der Mikroarchitektur leider leben. Man muss immer irgendwo Abstriche machen.

 

[Iscaran]

Warum baut AMD dann seine CPU so, dass man nur auf 128-bit breite FPU-Einheiten setzt? Warum nicht wie bei Intel direkt 256 Bit? Stattdessen wird jetzt diskutiert was andere wieder ändern müssen, damit Ryzen performt.

Warum ist jede Designentscheidung von AMD bei dir immer schlecht ?
Wenn es keine Entwicklung gibt - benutzen wir in 20 Jahren immer noch die gleiche ineffiziente Software (und Hardware).
Wenn AMD einfach Kabylake kopieren hätte wollen - hätten sie einfach bei Intel eine Lizenz für die Architektur kaufen können...
Wenn die Entwickler halt nicht auf "andere" Designentscheidungen die eigentlich effizienter sind eingehen - kann AMD nichts dafür oder ?
(Es gäbe ja einen AMD Compiler...müsste man halt sein x265 Programm mal damit kompilieren....)

AMD verfolgt mit Ryzen das Ziel die IPC diesmal
1. ähnlich wie die von Intel zu stricken (um die Software problem zu minieren)
2. dennoch alles in maximale parallelität zu setzen.

=> Das ermöglichte eben Kerne die IPC-technisch nicht mehr 50-60% hinten sind (sonder nur mehr ~6-7% bei gleichem Takt) aber dafür quasi die Kernzahl der "direkten" Konkurrenten gegenüber Intel jeweils ca. zu verdoppeln !
(4Kerne vs 8).

Auch wenn jeder einzelne von den 8 Kernen nun nur 95% der Leistungsfähigkeite der Intel 4Kerner hat - ist die Gesamtleistung des Systems dennoch fast doppelt so groß ! bzw. Wenn man noch den aktuellen Taktvorteil von Intel berücksichtigt und rausnimmt dennoch mindestens um 50% höher.

Weiter:
Die AVX2-Lösung von AMD funktioniert GUT und mindestens (fast) gleichwertig wie die von Intel:

Siehe AIDA Dhrystone mit AVX2:
"From integer workloads in Dhyrstone to floating-point workloads in Whestone Ryzen rules the roost blowing both SKL and HSW-E away being between 23-33% faster, with or without SMT. SMT does yield bigger gain than on Intel’s designs also."

Ryzen hat ~ 290 GIPS mit SMT , i7-6700K hat ~185 GIPS mit HT
=> 18.125 GIPS/Thread vs 23.125 GIPS/Thread.
=> 27% langsamer als i7-6700K allerdings Taktraten unterschiedlich !
1700X 3.4 - 3.9 GHz
6700K 4.0 - 4.2 GHz

In dem Test wird sicherlich nicht mit dem Single Core boost gefahren...=> 4 vs 3.4GHz = ~18% Taktvorteil Intel.

=> 27% Leistung pro Thread - 18% Leistung durch Takt abgezogen bleibt ein "IPC"-Vorteil von mageren 9% über...

Dafür haut der AMD doppelt so viele Threads hin - was nur durch das clevere Design von AMD geht hier voll auf MT zu setzen.

Insgesamt sieht man aber das ein Ryzen Kern mit AVX-2 eigentlich locker fast doppelt so gut laufen muss wie ein Intel.
NUR im x265 encode tut er das nicht => Warum ?

Es gibt keinen Grund nach den grundlegenden Befehlssatz Benchmarks von SiSoft warum der x265 encoder hier bei AMD ca 50% schlechter performen sollte !

Die Erklärung von NikosD passt dazu einfach "perfekt":

Weil der Compiler die AMD CPU eben nicht 100% nutzt sondern nur 50%...weil er statt 4 Befehl zu erzeugen nur 2 Erzeugt (weil Intel CPUs ) nur mit doppelt Parallelem AVX code umgehen können ! => siehe Agner Fog sowie NikosD.

Edit: http://www.hardware.fr/getgraphimg.php?id=438&n=1

Hier beim Taktvergleich mit alle CPUs bei 3GHz
x265 Broadwell-E (6900K 8C16T) ~250 vs Ryzen 1800X (8C16T) @230 (Core-Parking Off, da damals der Win-Scheduler bzw. energieprofil Patch noch nicht draußen war)

250/230 = ~9% langsamer pro Takt...und das wars dann. Wenn man plötzlich 50% Differenz findet stimmt was nicht !

=> die ~50% Langsamer bei x265 in dem 3dCenter benches sind ein "Artefakt" oder Fehler aus irgendetwas anderem.
Falls jemand ein aktuelleren Test hat wo man mal Ryzen vs Intel CPUs bei gleichem Takt vergleicht wäre mal interessant.

 

[IchoTolot]

Wieso bestehst du darauf, dass überall wo Ryzen schwächer ist, ein "Fehler" bei anderen vorliegen muss? Glaubst du wirklich Ryzen kann ALLES besser nur weil er 8 Kerne hat? Da sind doch ganz offensichtlich Dinge wo er schwächer abschneidet, das ist eben so. Ich versuche auch nicht durch wilde Theorien Kaby Lakes schwächere Ergebnisse als Fehler in der Anwendung oder bei anderen zu suchen. Jede CPU hat eben Ihre Vor- und Nachteile und schneidet eben je nach Benchmark völlig anders ab.

Tests bei gleichem Takt gibt es doch genug, das ändert aber nichts an den Ergebnissen.

Ich verstehe immer noch nicht, was ein Intel Compiler mit der Performance einer Ryzen CPU zu tun hat. Der x265 Encoder ist nicht von Intel.

 

[Iscaran]

Wieso bestehst du darauf, dass überall wo Ryzen schwächer ist, ein "Fehler" bei anderen vorliegen muss?

Das stimmt doch gar nicht...ich habe damit nur deine Aussage versucht zu erklären

Ich denke nicht, dass es an CCX liegt, aber grade bei x265 Videocodierung ist ein Ryzen richtig schwach im Verhältnis zu seinen Threads. Wird im 3dc in einer Tabelle geführt.

3dCenter

https://docs.google.com/spreadsheets...o7g/edit#gid=0

Woran das liegt? Das weiß keiner so genau. Ich vermute ja dass der AVX-Takt da geringer ist bei Ryzen.

Es gibt 0,0 Grund warum der "AVX-Takt" bei Ryzen langsamer sein sollte. Alle anderen Quellen und "Basis"-Benchmarks zur AVX-Funktionalität zeigen dass Ryzen hier ~9% Langsamer ist als Intels KabyLake...

Nur dein x265 Beispiel oben ist Ryzen 40-50% langsamer, also "überproportional" schwächer als alle theoretischen (und z.t. praktischen messungen an idealen Samples nahelegen)...

WARUM ? (siehe Erklärungen auf der letzen Seite). Es gibt dafür keinen einzigen logischen, architekturiellen oder sontwie grund. Einzig das der x265 encoder eben "noch nicht optimal" für Ryzen funktioniert...weil Ryzen eben "im Detail" dann doch kein KabyLake Prozessor ist und der GCC-Compiler das niemals wird unterscheiden. Der Compiliert nur für Intel Architekturen. Ob und wie andere Architekturen damit umgehen können ist denen egal.
Der Kompiler ist die Software die den Roh-Programmcode erst in Maschinensprache ("fertige exe") übersetzt. Jedes Programm das auf irgendeiner CPU ausgeführt wird wird erst durch irgendeinen Kompiler gejagt der den Code in die simplen sogenannten micro-operationen zerlegt.

Das ist NICHT NUR ein Problem für Ryzen - aber wenn dir das nicht einleuchtet kann ich dir auch nicht mehr weiterhelfen.

 

[aldaric]

Du kriegst es von Iscaran erklärt, und verstehst es trotzdem nicht.

PS:
Wir brauchen dringend eine "Daumen hoch" Funktion im Forum.

 

[IchoTolot]

@Iscaran

Holt hat es oben doch schon mal erklärt. Es macht keinen Sinn, dass hier irgendwas an Ryzen angepasst wird weil das den Sinn und Zweck von AVX2 torpedieren würde. Ryzen hat eben nunmal nur eine 128 Bit breite FPU-Einheit. Wenn Programme dann eben die Vorzüge moderner Befehlssätze nutzen, muss man dann mit Einschränkungen bei AMD eben leben.

 

[Alefthau]

Warum baut AMD dann seine CPU so, dass man nur auf 128-bit breite FPU-Einheiten setzt? Warum nicht wie bei Intel direkt 256 Bit? Stattdessen wird jetzt diskutiert was andere wieder ändern müssen, damit Ryzen performt. ^^ Man hat es bei Ryzen wohl aus Platzgründen gemacht, soweit ich das googlen kann. Dann muss man mit dieser Limitierung begründet in der Mikroarchitektur leider leben. Man muss immer irgendwo Abstriche machen.

Kleine Anekdote:

Es gab einmal ein Spiel, der Name ist mir entfallen und ich müsste ihn suchen, das lief anfänglich extrem gut auf FX-CPUs, diese ließen ihre Intel-Konkurrenten hinter sich bei den FPS.

Rate einmal was passiert ist in den Foren?!

RICHTIG, die Intel-User beschwerten sich lauthals, dass das Spiel Be***issen optimiert sei und nicht etwa, dass Intel eine "Designfehlentscheidung" getroffen hätte....

Es gab einen Patch und sowohl der Blutdruck, als auch die Welt, der Intel-User war wieder in Ordnung!

Selbiges ist eben auch bei Software der Fall und natürlich läuft eine auf/von Intel optimierte Software auf deren CPUs optimal.....

Gruß

Alef

 

[Iscaran]

Ryzen hat eben nunmal nur eine 128 Bit breite FPU-Einheit.

Nein du verstehst es nicht. Ryzen hat eine 128Bit breite AVX-Einheit die aber 4x-fach parallel arbeiten kann.

Ein Kaby/Broadwell von Intel hat eine 256Bit breite AVX-Einheit die aber nur 2x-fach parallel arbeiten kann.

Sieht man nun ~50% Leistungsdifferenz in einer Anwendung wie z.b. dem x265 encodieren ist eine mögliche Erklärung:

Der Kompiler schreibt nur doppelt parallele AVX-micro ops aus.
Also 2x256 bei Intel (was ja genau richtig ist für die Arch)
Aber eben nur 2x128 bei AMD obwohl bei AMD eben 4x128 auch gingen was dann eben (fast) genauso schnell wäre wie die 2x256 bei Intel.

Denn die AVX-Matrizen lassen sich eben mit wenig aufwand skalar zerlegen.
1x512 = 2x256 = 4x128...(+ "ein wenig" Verwaltungsoberhead pro Schritt)

Die grundlegenden AVX-Funktionsbenchmarks zeigen ja auch dass Ryzen ~9% langsamer ist...ABER eben nicht 50% langsamer ist was eindeutig einfach ein "bug" ist wenn du so willst.

256-bit vector instructions (AVX instructions) are split into two micro-ops handling 128 bits each. ....

Let us compare the execution units of AMD's Ryzen with current Intel processors. AMD has four 128-bit units for floating point and vector operations. Two of these can do addition and two can do multiplication. Intel has two 256-bit units, both of which can do addition as well as multiplication. This means that floating point code with scalars or vectors of up to 128 bits will execute on the AMD processor at a maximum rate of four instructions per clock (two additions and two multiplications), while the Intel processor can do only two. With 256-bit vectors, AMD and Intel can both do two instructions per clock.

 

[IchoTolot]

Was für Anwendungen nutzen denn noch AVX? Gibts noch andere Benchmarks? Da sollte Ryzen dann ja viel stärker sein. Könnte man ja dann überprüfen.