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

[IchoTolot]

Auf Tests irgendwelcher Magazine gebe ich inzwischen recht wenig. Ich teste lieber selber mit anderen Usern. Tatsache ist, dass ich mit dem User Schlammsau aus 3dcenter wie gesagt auch schon per PN andere Benchmarks hab laufen lassen. Handbrake haben wir beide die gleiche Videodatei genommen mit identischen Einstellungen und ich war dennoch schneller. Das ändert nichts.

 

[aldaric]

Ah, ok, Magazine haben keine Ahnung. Bei denen funktioniert es aber komischerweise.

Iscaran, warum machst du dir da überhaupt noch die Mühe ?

 

[Iscaran]

@Aldaric:

weil der Befund nunmal da ist und viele Leute dann rumlaufen und so einen Nonsens rumerzählen. Dabei ist hier gar nichts "klar".

Wie kann es sein dass ein x264 encode auf Ryzen schneller ist als ein x265...wobei beide fundamental dasselbe machen ?

Die eine x264 software hat den effekt nicht, die andere schon...da müssen die Leute doch hellhörig werden und anfange zu fragen warum hat die Software das Problem. Und nicht "ich habe es schon immer gewusst AMD Prozessoren sind schlecht (oder Intel Prozessoren sind die besten).

Das ist das gleiche wit mit dem ominösen CPU-Limit....das wenn man nur etwas hinschaut am Ende gar kein CPU-Limit ist (wenn eine 16-Kern CPU @10% Gesamtlast läuft z.B. und KEIN thread zu 100% ausgelastet ist und auch KEINE GPU Last von 100% anliegt) sondern schlicht und ergreifend fundamentale Mängel der Software offenlegt.

Das kann man einfach nicht oft genug wiederholen. Wir sind mittlerweile in der Softwareentwicklung so weit HINTER der Hardwareentwicklung dass man locker einen Faktor 5-10 (Singlethreading vs Multithreading) rausholen kann wenn man da ein bisschen Manpower reinsteckt.

Die Physik des Shrinkens ist quasi am Ende...ein bisschen Architekturoptimierung geht sicherlich noch (bzw. geht hand in hand mit Software) aber die Softwareprogrammierung muss endlich einen Riesenschritt nach vorne machen. Es kommt nicht mehr darauf an IRGENDwelchen Content irgendwie quick und dirty hinzurotzen.
Es muss sauber entwickelt werden mit einer nahezu idealen Ausnutzung dessen was die Hardware anbietet. Daran mangelt es einfach.Und das bedeutet eben das User und vor allem Reviewer bei solchen Auffälligkeiten hellhörig werden müssen und anfangen müssen fragen zu stellen.
Sonst ändert sich da nie etwas. Warum sollte Firma XY auf AMD CPUs hin optimieren solange sich keiner beschwert...

Aber siehe Beispiel oben - wie schnell hat man reagiert als zufällig mal die Intel CPUs als Lahme Enten da standen und die User sauer waren weil ihre Sandys und Ivys plötzlich und unerwartet von Bulldozer überrollt worden waren !
=> Softwarefail @its best.

Fazit: Es ist unzutreffend und zu einfach gestrickt hier zu sagen Ryzen hat eine massive AVX-Schwäche.
Ja Ryzen kann nur 128Bit AVX ops...und bei 256bit ops ist dann der Ryzen 50% langsamer...bei doppelter Core Zahl ist er aber dennoch nicht langsamer sondern gleich schnell. Die Beispiele wo ein Ryzen dann bei doppelter Core Zahl und gleichem Takt langsamer ist @AVX sind einfach unlogisch und nicht nachvollziehbar auf micro-op ebene.

Vor allem können Zen und Co (schon BD und PD) AVX-Code parallel mit anderem Code abarbeiten...=> Ich vermute das das ggf. die "Bremse" beim x265 ist - der Compiler geht von der Intel situation aus das man AVX code nicht mit NON-AVX code parallelisieren darf. Diese Einschränkung gilt für Zen nicht !.
Ich glaube nicht das das x265 encodieren fast nur aus AVX-Matrizen besteht...wenn diese 50% des Gesamtcodes einnehmen wäre das schon viel...=> die anderen 50% könnte Zen nebenher mit erledigen während er sich durch den AVX-Part müht. Die Intel CPU muss ERST den AVX-Part durchblitzen und kann sich DANN erst um den Rest kümmern (bzw. muss hin und her"schalten"). Wenn das mal keine Performanceschub@Ryzen bringen sollte bei Mixed code weiss ich auch nicht ?

http://www.agner.org/optimize/microarchitecture.pdf

While Intel processors have a large penalty for mixing 256-bit AVX instructions with non-AVX XMM instructions due to a mode switch (see page 132), there is no such penalty and apparently no mode switch on these AMD processors.

@Icho: Welche Handbrakeversionen mit welchen Einstellungen habt ihr verwendet, welche CPUs mit welchem Takt...bei solchen Vergleichen wäre es enorm Hilfreich entweder alles mit anzugeben und idealerweise auch mal bei GLEICHEM Takt zu benchen.

Das ein 3.0GHz R7-1700 trotz 16T von einem 5GHz i7-7700K mit 8T überholt werden kann sieht man doch schon beim Blick auf die 80% Taktvorteil.....bei gleichem Durchsatz an Micro-ops / Hz ist der i7 dann wegen der 5GHz dennoch genauso schnell wie ein 3GHz Ryzen....
Also bitte keine Äpfel/Birnen Vergleiche...ohne nähere Angaben ist so ein Benchmark zum Architekturverständnis sonst leider wertlos.

 

[aldaric]

@Iscaran:

Ich stimme dir doch komplett zu. Das war darauf bezogen das deine kompletten Mühen von Ichotolot einfach ignoriert werden mit dem Satz "ich bin trotzdem schneller". Der ist da gar nicht wirklich interessiert ob und wie überhaupt da was zustande kommt. Ihm geht es darum, dass er schneller ist und er was gefunden hat wo er über Ryzen sagen kann: "Ist halt nur ein Mustang und kein BMW".

Du könntest ihm die Beweise auf dem Silbertablett präsentieren von den höchst angesehen Magazinen, Wirkung hätten sie keine, weil er glaubt ja mittlerweile Reviews nicht mehr.

Und ja, ich stimme dir vollends zu, dass die AVX Schwäche keine Hardware-Schwäche ist, sondern in dem Fall eine Softwareschwäche. Andere Software belegt das ja.

 

[Iscaran]

@Aldaric:
Ich verstehe dein Argument :-). Dennoch hab ich denk ich von dem ganzen am meisten profitiert/gelernt.

Man lernt eben selbst am meisten wenn man sich kritisch mit solchen Dingen auseinandersetzt .

Mir war z.B. bislang nicht klar das Ryzen AVX-Code parallel zu normalem Code ausführen kann und Intel CPUs nicht !

Hoffentlich wissen das die Entwickler auch wenn sie AVX einsetzen und vertrauen nicht darauf das der Intel Compiler (oder ein Derivat des Intel Compilers wie LLVM) das auch so umsetzen. Viel wahrscheinlicher ist es doch dass so ein Compiler versucht AVX und NON-AVX code streng zu trennen, da es ja sonst auf den Intels massiv "bremst". Wohingegen Ryzen CPUs vom vermischen solcher Codes sogar relativ gesehen profitieren würden (bzw. ihre AVX-Nachteile aufholen könnten).

Abstrahiertes Beispiel:

Kompilierter Codepfad@KabyLake:

Non-AVX Code 10ms
Non-AVX Code 10ms
AVX-Code 20ms
AVX-Code 20ms
Non-AVX Code 10ms
Non-AVX Code 10ms

Gesamtdauer = 80ms

vs @Ryzen:

1xNon-AVX Code 10ms
1xNon-AVX Code + 1x AVX-Code 30ms
1xNon-AVX Code + 1xAVX-Code 30ms
1xNon-AVX Code 10ms

Gesamtdauer = 80ms

Beachte der Ryzen ist nominell 50% langsamer im AVX-Teil und dennoch insgesamt genausoschnell wegen des Code Mixings.

 

[Phneom]

Aber zum encodieren würd ich eigentlich eh immer auf GPU encoding setzen - da biste einfach nochmal ein Faktor 100 oder so schneller als mit CPU.

Aber hast dafür leider teils Qualitativ weniger gute Ergebnisse

 

[Iscaran]

@Phneom:

Kann man das nicht einfach durch xx-krassere Settings "kompensieren" ? Dann ist man zwar nicht mehr 100x schneller sondern nur noch 10x mal aber hat trotzdem dasselbe ?

Btw. hat jemand Ahnung wieviel von dem x265 Codepfad nun tatsächlich in AVX-geschrieben ist ? Und wieviel in anderen Befehlssätzen ?

 

[IchoTolot]

@Icho: Welche Handbrakeversionen mit welchen Einstellungen habt ihr verwendet, welche CPUs mit welchem Takt...bei solchen Vergleichen wäre es enorm Hilfreich entweder alles mit anzugeben und idealerweise auch mal bei GLEICHEM Takt zu benchen.

Kann ich dir sagen. Wir haben beide die neuste Nightlybuild genommen und das gleiche Video und uns dann auf eine Einstellung festgelegt. Glaube 1080p fast oder so. Letztlich war mein Ergebnis schneller. Daraufhin hat er dann angefangen seinen x264/x265 Benchscript anzupassen und es wurden verschiedene Batches getestet. Ist ja schon der dritte Thread im Forum dazu von ihm.

Ich hab damals natürlich mit Standardtakt also 4.4 Ghz laufen lassen und er mit weiß nicht welchem Takt. Glaube er lässt seinen Ryzen auf Standard laufen.

Kann ja verstehen, dass du es verstehen willst, aber wenn doch laut SiSoft Sandra zum Einen ein i7 auf 4.8 Ghz an die AVX2 Performance eines Ryzen auf 3.65 Ghz kommt und es unabhängig von der Software immer wieder zum gleichen Ergebnis kommt, sollte man sich doch auch irgendwann mal die Frage stellen ob das nicht architekturspezifisch ist. Die Problemzonen von Ryzen sind doch hinlänglich bekannt mit den CCX und das hat sicher auch Auswirkungen beim verarbeiten von solchen Befehlssätzen.

Schreib doch AMD Support an und frag da mal an ob die dir dazu was sagen können?

Ergänzung (12. Juni 2017)

Aber hast dafür leider teils Qualitativ weniger gute Ergebnisse

Ja hab ich auch gemerkt. Lief zwar mit 100 fps das Encodieren, aber am Ende kamen dann von der BluRay nur noch 2 Mbit an oder so.

Ergänzung (12. Juni 2017)

Wegen mir können wir auch nochmal einen Benchmark mit Handbrake oder anderem Tool machen.

 

[aldaric]

Edit: Nein, ich spars mir.

 

[MK one]

Wenn ich encodiere will ich möglichst hohe Qualität und relativ geringe Größe haben , das geht zur Zeit nur mit der CPU , weil man über die CPU viele Funktionen nutzen kann , die man mit einer Graka nicht nutzen kann .
Ne Graka ist schneller , ist qualitativ jedoch schlechter - da nutze ich lieber die CPU .

h265 ist ca doppelt - 3x so effektiv = wo ich in h 264 6 - 7 GB benötige , lande ich bei h265 bei ca 2 - 3 GB bei vergleichbarer Qualität ( FullHD 1080p )
Leider habe ich noch keine Fernseher oder Blu Ray Player die h265 unterstützen , auch der FireTV Stick unterstützt es noch nicht - deswegen codiere ich in h264 , aber h265 ist besser weil platzsparender

 

[IchoTolot]

Ja leider. Das wäre ein Grund wo ich nicht genug Kerne haben wollte. ^^ Aber ich mache es zu selten, als dass sich das lohnen würde. Mal sehen in ein paar Jahren vielleicht, wenn mehr Kerne von Intel günstiger sind.

Habe auch grade einmal die AIDA Benchmarks durchlaufen lassen. Bei allen FPU-Benchmarks bis auf SinJulia ist der 7700K schneller laut Vergleichsliste, inklusive RayTracing.

Gab es heute eine neue AIDA64 Build, die direkt mal installiert.

Spoiler

SiSoft Sandra Multimediabenchmark:

Spoiler

Ergänzung (12. Juni 2017)

Btw.. Wenn man die SiSoft Sandra Benchmarks laufen lässt und gleichzeitig Core Temp die neue 1.8.1 an hat, dreht das völlig durch. Das hat mir da dann auch schon 5xxx Watt angezeigt beim Stromverbrauch.

Ergänzung (12. Juni 2017)

@Aldaric:
Dennoch hab ich denk ich von dem ganzen am meisten profitiert/gelernt.

Oh, ich hab auch wieder viel gelernt. Aldaric ist auf meiner Ignorelist, weil er auf mich nur aggressiv, provozierend und respektlos wirkt. Das spare ich mir.

 

[aldaric]

Aldaric ist auf meiner Ignorelist, weil er auf mich nur aggressiv, provozierend und respektlos wirkt. Das spare ich mir.

Danke gleichfalls.

 

[MK one]

vergiss aber die CPU Tests nicht ...
Cpu Hash = mein Ryzen hat ne 4 x höhere Leistung als der 7700k@4200


oder Cpu AES 3x Höher


FPU Sin Julia 2,20 x höher


CPUzlib 1,7 x höher


Photoworx 1,2 x höher


Cpu Queen 1,6 x höher



bei den Rest der FPU test ist der 7700 gleichauf oder etwas schneller


mit deinen 4,8 ghz kommste vielleicht noch an Photoworx ran , aber in den restlichen bleibt der Ryzen schneller , gleiches bei FP Sin Julia

Bei Hash und AES ist der Ryzen stärker als Intel betrachtet man die 550 mhz mehr ( + Turbo ) des 4200 sogar wesentlich stärker , selbst wenn man die Ergebnisse von Aes und Hash halbiert wegen der 8 Kerne kommt der 7700 nicht ran trotz 4,2 Ghz zu 3,65 des Ryzen

 

[IchoTolot]

Ja Photoworxx war ich auch schneller, wenn ich nach der Liste gehe. Bei den CPU Tests ist der Ryzen in den meisten Fällen deutlich schneller, stimmt.

Mir ging es um FPU, weil darunter auch AVX(2) fällt.

 

[MK one]

und sin Julia ? da ist die Ryzen CPU mehr als doppelt so schnell .. , man müsste quasi Funktion für Funktion durchgehen ..

Frage mich sowieso warum die Sinus Funktion von Julia so schnell ist , während Julia selbst so vergleichsweise langsam .

Allerdings kann man grade im Bereich der FPU durch Optimierungen viel rausreißen , ich denke nicht das in irgendeiner Form da was passiert ist beim Ryzen - im Gegensatz zum Kabylake der schon merklich länger am Markt ist .

 

[IchoTolot]

Ja SinJulia ist Ryzen schneller. Ich hab ohnehin nicht den Plan was diese ganzen FPU Benchmarks bedeuten, geschweige denn eben den Unterschied zwischen Julia und SinJulia, wie du schon sagst. Man kann eben nur eine grobe Richtung erkennen, dass Kaby Lake bei der FPU sehr stark ist und die fehlenden Threads mit Takt und Optimierung der CPU in dem Bereich mehr als ausgleichen kann. Für mich sind das eben Indizien die zeigen, dass beim Encoden in x265 hier deutliche Vorteile bei KL liegen.

In der Gesamtrechenleistung liegt KL aber natürlich zurück.

Ergänzung (12. Juni 2017)

Hier noch die Photoworxx Werte.



4.4 Ghz = 27.181 (+18%)
4.8 GHz = 27.330 (interessant, dass nur so geringer Unterschied)

Du hast aber auch die gleiche Version genommen bei AIDA, oder? Kam heute ein Update. Aktuell ist 5.90.4251 Beta, weil sonst kann man eh nicht vergleichen. Sagt er ja bei jedem Benchmark.

Ergänzung (12. Juni 2017)

Ah ok, hier wirds erklärt:

https://www.aida64.com/products/features/benchmarking

SinJulia ist wohl mit eines der, die nicht die AVX Leistung messen. Die anderen schon, daher die Ergebnisse. Also da wo AVX genutzt wird, ist der Intel dann auch schneller.

 

[MK one]

steht ober links im screenshot - allerdings ist lt. changelog bei der neuen nur die Erkennung der neuen i9 CPU s hinzugekommen und bei 1 - 2 Motherboards Bugfixes beim auslesen der Sensoren .

 

[IchoTolot]

Ah ok, Changelog hab ich nicht geschaut, bzw. nicht danach gesucht. In AIDA sind aber ohnehin immer sehr alte Werte drin, also bei Speicherlatenzmessung. Kann ja nicht sein, dass es da nicht niedrigere gibt als die von einem alten Athlon oder so. O_o Da hab ich 48 ns.

 

[Piktogramm]

@Phneom:
[...]
Btw. hat jemand Ahnung wieviel von dem x265 Codepfad nun tatsächlich in AVX-geschrieben ist ? Und wieviel in anderen Befehlssätzen ?

Handbrake steht unter der GPL und ist als solches komplett Quelloffen, du kannst selber nachschauen. Ich habe die Stellen die ich als relevant identifiziert habe überflogen und kein einziges Stück Assembler gefunden und auch keine Anweisungen für den Compiler. Wenn ich nichts übersehen habe, dann spuckt die AVX-Optimierungen der Compiler "einfach" während des Kompilierens aus. Wobei es mir so scheint als würde für Windows MinGW bzw. der GCC genutzt werden.
Wobei es zum Release von Ryzen so war, dass AMD für Zen entsprechende Profile in den GCC gepatcht hatte. Jedoch Code der seitens des GCCs für Intel Haswell anstatt Zen optimiert wurde schneller läuft als jener Code der mit den Profilen für Zen erstellt wurde. Kurzum, für optimale Performance sollte AMD noch ein paar Patches in die Entwicklung vom GCC werfen.

Anderseits ist Stand der Dokumentation von Handbrake, dass das Programm mit 4 Threads nahezu perfekt skaliert, bis 6Threads noch recht gut und darüber hinnaus dann deutlich abfällt. Entsprechend ist es an der Stelle ein Nachteil für Ryzen mit bis zu 16Threads auf das Problem loszugehen. Wohingegen so ein Intel Quadcore mit 8Threads besser skaliert und dank der breiteren Vektoreinheiten mit den besser skalierenden Threads wahrscheinlich wirklich einen deutlichen Vorteil hat.


Im Übrigen ist "wenn die Software nur mal richtig optimiert werden würde, wäre viel mehr drin" schlicht falsch. Gerade bei solch recht gut optimierten Sachen wie Videocodecs sind die kritischen Codepfade sehr gut optimiert und die Compilersettings mit Bedacht gewählt. Auch lassen sich nicht alle Probleme beliebig auf viele Threads verteilen. Gerade wenn es Abhänigkeiten zwischen den Threads gibt und diese aufeinander warten müssen kommt es eben mal dazu, dass ein Kern zu 80% ausgelastet ist und alle restlichen Threads auf den anderen Kernen warten müssen und im Mittel so bei 1-2% Auslastung herumkrebsen. Wenn du Lösungen für die entsprechenden Probleme hast nur zu. Darauf sind nicht selten Preisgelder erheblicher Höhe ausgesetzt. Selbst mit einer Teillösung ist dir eine sehr gut bezahlte Stelle in jeder IT-Klitsche sicher.



Anonsten sind eure AVX(2) Spekulationen echt ganz interessant, aber solang ihr euch nicht etwas mit dem zugehörigem Assemblerfoo beschäftigt bleiben es wohl Spekulationen. Wenn es einer von euch schafft sich durchzuackern, ich bin lass mir das dann gern erklären (<- Ich verstehe genug von Assembler, um keine Arbeit hineinzustecken es zu erlernen -.-)

 

[MK one]

Da es für die CPU direkt keinen Treiber gibt wie bei einer Graka , den man anpassen kann muss halt die Software gepatcht werden wenn s nicht rund läuft . Stimmt es nicht das bisher viel mehr Zeit in die Optimierung für Intel CPU s geflossen ist , sei es bei Spielen oder bei Software , als es bei AMD der Fall war ? Der Bulldozer war zu Anfang so langsam weil er CMT statt SMT hatte , das nicht unterstützt wurde - mittlerweile ist ein 8350 gar nicht mehr soooo langsam in Games .

Solange nicht speziell auf Ryzen optimiert wurde ( was mitunter viel bringen kann ) , läuft der Ryzen im Intel Kompatibilitätsmodus , mal besser , mal schlechter , denn er ist nicht baugleich .

Dabei geht es nicht um eine Optimierung der Software an sich , sondern eher um eine Anpassung der Zuweisung der Aufgaben. Der Ryzen hat 2 CCX Blocks a 4 Kernen , innerhalb des CCX können Aufgaben sehr schnell abgearbeitet werden , muss erst auf ein ergebniss aus dem anderen CCX gewartet werden kommt er zu Verzögerungen weil der Zugriff langsamer ist .

So etwas gibt es in einer Intel CPU nicht ... , nicht das es nicht laufen täte , aber es ist langsamer als es sein könnte , deswegen sollte die ccx zu ccx Kommunikation so gering wie möglich sein , eine Aufgabe möglichst innerhalb eines ccx abgearbeitet werden