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

[Hägar Horrible]

@ Alefthau: Ja, das Spiel habe ich auch in Erinnerung, war ein Ego-Shooter. Lief auf den Octacore-FX wie geschnitten Brot und deklassierte dort sogar den sonst so überlegenen i7. Einen "patch" später musste sich der FX auf einmal hinter den i5 einreihen.

Ich erinnere mich auch an einen Test mit einem Intel-Compiler und einer Cyrix-CPU. Änderte man die Bezeichnung, unter der er sich meldete in Genuine Intel lief er nahezu doppelt so schnell. Wohlgemerkt, die gleiche CPU.

 

[Iscaran]

@Icho:

keine Ahnung aus dem Stegreif was AVX sonst noch nutzt.

Eigentlich ist es eine Krücke damit CPUs mit GPUs in bestimmten Aufgaben besser mithalten können. wie Z.B. Rendering.

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.
https://forums.anandtech.com/thread...-avx2-throughput.2501158/page-3#post-38786799

Hier aus anderer Quelle:
https://forums.anandtech.com/thread...-avx2-throughput.2501158/page-2#post-38786448

The throughput is double only with 256 bit FP-FMAC. AMD can do 4x128 bit FP ops and 4x128 bit IVEC ops. INTEL can do 2x256 FP ops (including FMACs) and 2+1 256 IVEC ops (2 calculus and 1 shuffle/misc).

So Zen can do 1x256 Fmul + 1x256 Fadd or 1x256 FMAC versus 2x256 Fmul OR 2x256 Fadd OR 2x256 Fmac (provided that the ports are not occupied and with 2 threads this can happen. On Zen no.)
For IVEC (I assume h264/5 don't use FP, but blender yes):
Zen can do 2x256 or 4x128 IVEC (all: add, sub, mul, div, ecc), INTEL can do 2x256 calculus + 1x256 shuffle/misc (provided that the ports are not occupied and with 2 threads this can happen. On Zen no.)

Entweder nutzt das x265 encodieren irgendwie ungewöhnlich viele (ausschliesslich) FP-FMAC micro ops oder es ist was anderes nicht in Ordnung wenn die Performance Differenz Kaby vs Ryzen >>10% ist !
Eigentlich ist die micro-op performance von Zen und intel für h265 ziemlich "gleich"

 

[IchoTolot]

@Iscaran

Ich bin ja gerne bereit zu lernen und mein Wissen zu erweitern und im Gegensatz zu anderen Usern bleibst du sachlich.

Soweit ich gesehen habe, nutzt Blender ja auch AVX2 und wurde von AMD auch gerne verwendet um ihr Logo rendern zu lassen. Ich hab das auch mal gemacht und mit 4.4 und 4.8 Ghz bei mir gemessen und das mit AMD verglichen. Wenn ich den Rendertest mache, bin ich nur 36% langsamer gegen einen Ryzen mit 3.9 GHz. Wenn man sich an Cinebench orientiert, müssten es da aber über 60% sein. Es liegt also nicht alleine an dem x265 Codec und seinem Compiler. Ryzen scheint hier definitiv nicht so effizient zu sein.

Ryzen 3.9 Ghz:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11315836&postcount=148

Ich:


Wenn man den 6900K nimmt mit 4 Ghz, der auch nur 8 Kerne hat, ist der sogar noch eine ganze Ecke schneller.

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11329431&postcount=152

Ergänzung (11. Juni 2017)

Der User hat AVX sogar mal ausgeschaltet und ist dann 36% langsamer beim x265 Encoding.

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11398656&postcount=132

 

[Iscaran]

36% Langsamer als Ryzen und wie groß ist der Taktraten unterschied ?

Ich rede hier von IPC...die kann man sinnvoller weise nur bei gleichem Takt vergleichen oder man muss die Werte zumindest auf gleichen Takt skalieren !

Also wenn du 36% langsamer bist mit 4.4GHz vs Ryzen mit 3.9GHz dann kannst schon mal weitere 12% auf dein Ergebnis aufschlagen wenn du ebenfalls mit 3.9GHz unterwegs bist.

Dann bist du ziemlich genau "halb" so schnell wie Ryzen....

Was ja klar ist 8T vs 16T...die Welt ist ganz "normal".

Ergänzung (11. Juni 2017)

Cinebench nutzt einen mix aus 3-4 Arten von Instruktionen mit ca 40% Anteil an SSE4 AFAIK.

Ist also eher ein Maß für gemischte Workloads.

 

[IchoTolot]

Nein, denn wenn du einrechnest, dass SMT ja auch etwas effizienter ist als HT, müsste der Unterschied gute 43% zugunsten Ryzen sein wie bei Cinebench. Das ist der Unterschied, wenn man 7700K 4.8 Ghz und Ryzen 4 Ghz vergleicht. Hier sind es aber nur 36%, das passt nicht. Intel schneidet also auch bei Blender übermäßig stark ab.

 

[Iscaran]

Ich weiss jetzt nicht wie du auf die 43% beim Cinebench kommst.

Aber laut meiner bislang erhobenen Daten kommt bei 3000er RAM-Takts) eine Kaby Lake Architekur auf ca 44,0 Punkte/GHz single core mit einem Multitkern-scaling effizienz von ca 29%. Bzw. auf ein MultiScore/GHz/Thread von ca 27.4 Punkte/GHz/Thread

Ryzen hat Single: 40.3 Punkte/GHz mit 3200er RAM
und multithread: 27.1 Punkte/GHz und Thread

Also ist IPC technisch Kaby in SC ca 9% schneller und im Multithread dann nur noch ca 1%.

Das heisst mit SMT/HT zieht Ryzen damit auf "IPC" umgeschlagen mit Kaby fast gleich (bei gleichem Takt - deswegen rechne ich die Cinebench daten ja taktnormiert !)

 

[IchoTolot]

Ich hab eben mal den SiSoft Sandra Benchmark laufen lassen bei mir. Vielleicht macht das jemand mit Ryzen auch mal.

Ergänzung (11. Juni 2017)

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.

Er wird aber komplett ausgelastet:

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11398937#post11398937

 

[slumpie]

Er wird aber komplett ausgelastet:

Wie will er das ermittelt haben?
Sag jetzt bitte nicht über den Taskmanager...

 

[Iscaran]

https://www.computerbase.de/forum/attachments/amd-ryzen-cpu-aa-png.627649/
http://www.sisoftware.eu/2017/04/05/amd-ryzen-review-and-benchmarks-cpu/
6700K@4.2GHz (Stock) mit HT/SMT:
WhetStoneDouble: 60 GFlops
WhetStoneSingle: 109 GFlops
DhryStoneLong: 185 GIPS
DhryStoneInt: 185 GIPS

R7-1700X@3.9GHz (Stock) mit HT/SMT:
WhetStoneDouble: 155 GFlops = 258% von 6700K
WhetStoneSingle: 185 GFlops = 170%
DhryStoneLong: 292 GIPS = 158%
DhryStoneInt: 290 GIPS = 157%

Das ist was Theoretisch geht wenn man NUR entsprechenden AVX-Code laufen lässt...die frage ist warum davon "nix" bei x265 ankommt.

EDIT: Wie man aber auch sieht ist ohne SMT und damit "Single Core" der 6700K durchaus leicht schneller...(z.B. 109GFlops/4Kerne = 27.25 GFlops/Kern; Ryzen 185/8 = 23.125/Kern) => +18% SingleCore pro Intel 6700K - ABER 4.2GHz/3.9GHz = 8% Taktvorteil müssen wir wieder abziehen bzw. bedenken. Effektiv ist der 6700 dann also "IPC" mäßig bestenfalls 10% schneller. (aber eben 50% weniger kerne...)

Wenn eben die 8Kerne bzw. 16 Threads auch genutzt werden dann bläst der Ryzen den 6700er eben doch von den Füßen.

Also entweder läuft der x265 encoder nur auf 8T ? => 50% Handbremse beim Ryzen...dann ist klar das ein kaby mit 4.5GHz hier deutlich schneller ist weil 8T vs 8T bei 20% Taktvorteil + bisschen IPC....
Aber das dürfte eigentlich auch nicht sein wenn der x265-Code korrekt funktioniert muss er eigentlich in der Lage sein 16T zu bedienen.

Ergänzung (12. Juni 2017)

Ich bezog mich bei den Angaben zur Kernauslastung von Ryzen auf die Angaben von Sagittaire aus dem Doom9 forum - der schrieb auch was davon dass Ryzen mit 100% Last schneller ist. Aber das in dem anderen Bench Ryzen wohl nur mit 50% Last lief.

Wie gesagt...ich bezweifle nicht dass in dem Bench der Intel schneller ist. Die Frage ist nur WARUM...denn es gibt dafür keinen logischen Grund. Außer Handling-Fehler beim Benchmark, Software läuft nicht ideal "gleich" auf beiden Architekturen oder sonst irgendwelche "Bugs".

 

[MK one]

Ich hab eben mal den SiSoft Sandra Benchmark laufen lassen bei mir. Vielleicht macht das jemand mit Ryzen auch mal.

Anhang anzeigen 627710

Ergänzung (11. Juni 2017)

Er wird aber komplett ausgelastet:

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11398937#post11398937

Bitte schön , aber beachten - Mein Ryzen läuft auf seinen Effizienz Spot 3,65 Ghz @ 1,168v


Deine AVX 32 mit 130,61 stehen meine mit 194,58 gegenüber , bei AVX64 106,88 zu 162,68

 

[IchoTolot]

Hab auch nochmal laufen lassen und weil man die Ergebnisse da nur so schlecht exportieren kann, die Ergebnisse zusammengefügt.



Bei AVX2 bin ich quasi gleichauf mit deinem Ryzen:

Ich: Du:
205 217
220 223

Das erklärt auch vielleicht, wieso MT x264 deutlich bei Ryzen mehr leistet, aber dann bei x265 nicht mehr. Oder willst du jetzt SiSoft Sandra die Schuld geben? ^^

 

[Iscaran]

Viel Interessanter sind doch in dem Kontext die Dhrystones:

7700K@4.8GHz:
IntAVX: 192 GIPS
LongIntAVX: 221 GIPS

vs 1700X@3.65GHz:
IntAVX: 217 GIPS
LongIntAVX: 224 GIPS

Brechen wir das mal auf /GHz und Kern bzw. Threads runter (sofern man dies so einfach tun kann - habe keine Ahnung wie linear das ganze mit Takt skaliert):

7700K@4.8GHz (/GHz):
IntAVX: 40 GIPS/GHz und damit => 5 GIPS/GHz und Thread
LongIntAVX: 46 GIPS/GHz => 5.75

vs 1700X@3.65GHz (/GHz):
IntAVX: 59GIPS/GHz => 3.69
LongIntAVX: 61 GIPS/GHz => 3.81

Interessant...auch hier ist der Kaby IPC mäßig für diesen Befehlssatz ~35% in IntAVX bzw 50% bei den LongIntAVX schneller. Aber wegen der doppelten Threadzahl trotzdem in Summe langsamer bzw. gleichauf.
Parallel-Power at its best .
Wenn wir das als Maß für den x265 nehmen müsste man dort also das gleiche sehen..Ryzen 8C16T und Kaby 4C8T in etwa gleich auf (LongIntAVX).

Ergänzung (12. Juni 2017)

Das erklärt auch vielleicht, wieso MT x264 deutlich bei Ryzen mehr leistet, aber dann bei x265 nicht mehr.

Nein leider nicht ganz...denn ob ich jetzt x264 encodiere oder x265 ist im Grunde derselbe Typ operationen. x265 erfordert nur größere Datenmengen.

Wenn also keine weiteren Effekte vorliegen oder anderweitig spezialisierte Sub-Hardware am werk ist müsse das eigentlich ziemlich "gleich" skalieren.

 

[IchoTolot]

Theoretisch. Das sind aber ja nur synthetische Benchmarks. Wie das eben dann in verschiedenen Anwendungen auch umgesetzt werden kann, ist die andere Frage. Zeigt sich ja zum Beispiel bei dem x265 Encoder. Daher denke ich nach wie vor, dass Ryzen das irgendwie im ganzen Zusammenspiel nicht perfekt schafft. Da spielen dann bei jeder Anwendung ja auch wieder Cache, Latenz, etc. mit rein denke ich.

 

[MK one]

Der 7700 k wurde auf h265 decode und auch encode hin optimiert

http://www.anandtech.com/show/10959/intel-launches-7th-generation-kaby-lake-i7-7700k-i5-7600k-i3-7350k/6

The new circuitry for hardware accelerating HEVC Main10 and VP9 are part of the MFX block. The MFX block can now handle 8b/10b HEVC and VP9 decode and 10b HEVC / 8b VP9 encode. The QuickSync block also gets a few updates to improve quality further, and AVC encode performance also receives a boost.

 

[IchoTolot]

Die interne GPU ist bei mir deaktiviert. Ich denke hier spielt einfach wieder die ccx Anbindung rein. Ich hab einen Speichercontroller der mit 4.2 Standard taktet, den hab ich auf 4.4 GHz gehoben. Ryzen taktet da mit Ram-Takt, also meistens höchstens 1500 MHz. Grade will wie du schon sagst größere Datenmengen bei AVX2 anfallen.

 

[Iscaran]

Hmmmm....

ich denke es ist eher so dass der x265 encode den ihr benutzt noch keine korrekte AVX-2 encode enthält.
https://forum.doom9.org/showpost.php?p=1799647&postcount=22

http://www.hardware.fr/articles/956-14/encodage-video-x264-x265.html
Bitte beachtet die Version für x265 ist hier 2.1.1812

Bei 3D-Center wird welche Version genau benutzt ?
https://www.forum-3dcenter.org/vbulletin/showthread.php?t=581419
1.0.1 bezieht sich ja auf den 264 vs 265 Benchmark und nicht auf die Subversionen der verwendeten Encoder.

Generell denk ich sollte man mit Schlüssen bei x265 noch vorsichtig sein. Hier gibt es noch täglich neue Performance builds...mit weiteren Optimierungen in Bezug auf AVX/AVX2 usw. ggf. wird für Ryzen eben auch nochmal die Feinjustage ausgepackt.
Hier ein Benchmark vom April mit einer x265 version Stand April - 3.7GHz Ryzen 1600 gleichauf mit 4.8GHz 7700K:
https://www.kitguru.net/components/cpu/luke-hill/amd-ryzen-5-1600x-6c12t-cpu-review/4/

 

[MK one]

Soweit ich weiss ist quick sync standardmässig aktiviert , zb in Handbrake , du must es also deaktivieren , kannst ja mal vergleichen mit und ohne


ausserdem selbst wenn du die Igpu im Bios deaktiviert hast sind die Funktionen trotzdem im Codec aktiv

@ holt
und Intel Fanboys werden nie akzeptieren das einzelne Stärken nicht die doppelte Kern Anzahl ausgleichen , dann kommt wieder hoher Takt bla bla , single Core Bla Bla . Stärker sind die Intels nur solange nicht mehr als 8 Threads genutzt werden .
Mittlerweile starten sogar einige Games nicht mehr wenn weniger als 3 oder 4 Threads genutzt werden können ...

 

[Iscaran]

@holt:

encodieren ist einer der Tasks die man nahezu perfekt parallelisieren kann...

Wenn Ryzen hier also TROTZ doppelter Kernzahl 50% langsamer erscheint als ein Kaby - dann ist da irgendwo der Wurm drin.

Vor allem weil x264 das ein ganz ÄHNLICHER prozess ist im wesentlich stimmt.

KBL hat durchaus Vorteile von seiner AVX-Implementierung....deswegen ist er im 1:1 ja auch knapp vorne dran bei x264...aber dieser deutliche Sprung zu x265 ist einfach sonderbar.
Das hat doch nichts mit Fanboytum zu tun...seltsame Ergebnisse bedürfen doch wohl einer Diskussion und Klärung oder ?
Und nicht einfach der Religösen Erklärung, weil war klar das Intel schneller ist...denn klar ist das in dem Fall überhaupt nicht.

Lies doch einfach auf doom9 ein wenig mit dann siehst du schon dass selbst die Entwickler von x265 noch davon sprechen dass es jede Menge Optimierungsbedarf bei ihrem Zeug gibt. Erst seit ca. MAI gibt es x265 mit AVX-Support übrigens !
x264 dagegen wird zwar noch weiterentwickelt ist aber schon gut optimiert und zwar auf ALLE Architekturen (Stand Dezember 2016).

Deswegen ist ja wohl meine Frage nach der x265 Version oben durchaus berechtigt oder ?

Ergänzung (12. Juni 2017)

Nachtrag:

http://32ipi028l5q82yhj72224m8j.wpe.../2017/03/GDC2017-Optimizing-For-AMD-Ryzen.pdf
http://www.agner.org/optimize/optimizing_assembly.pdf
@Holt: Dann erklär mit mal warum Ryzen mit 6 µops Fetch pro Cycle, wovon insgesamt 4x128 parallel AVX sein können + der Fähigkeit parallel FMA und AVX zu beherrschen im encodieren von x264 bzw x265 unter Nutzung des AVX-Codes in Kombination mit anschließendem FMA...NICHT ca. gleichschnell pro Cycle wie Intels KBL sein soll ?

 

[IchoTolot]

Soweit ich weiss ist quick sync standardmässig aktiviert , zb in Handbrake , du must es also deaktivieren , kannst ja mal vergleichen mit und ohne
Anhang anzeigen 627756

ausserdem selbst wenn du die Igpu im Bios deaktiviert hast sind die Funktionen trotzdem im Codec aktiv.

Nein quick sync ist deaktiviert. Konnte das auch nicht nutzen bei handbrake und hab gewundert warum. Bis ich dann Mal die GPU aktiviert hab. Hatte dann 100 FPS im encoding.

@iscaran

Wir haben da verschiedene Compiler benutzt, also LVMM oder wie das heißt und Clang, also nicht nur den GSC COMPILER. Macht aber keinen Unterschied..

Wieso ist ein Ryzen bei 3 GHz langsamer als ein i7? Ist eben so. Ryzen hat Schwächen wie Intel auch.

 

[Iscaran]

@Icho:

Das Ryzen etwas langsamer als KBL steht hier außer Diskussion. Es wundert mich nur dass x264 soviel Unterschied zu x265 zeigt obwohl der Workload nahezu dieselben Micro-ops sind....

Wenn Ryzen in x264 bei gleichem Takt ~50% schneller als KBL ist (wegen 8T vs 16T).
Beide encodierprozess sind nahezu optimal multi-threading fähig...was sich ja im x264 zeigt...warum hängt der Ryzen dann im x265 hinterher ?

Selbst ein Professor für IT und Programmierung wie Georg Hager wundert sich darüber:
https://blogs.fau.de/hager/archives/7810

(Update: The two AGUs would be OK for one AVX LOAD and one half AVX STORE per cycle, just as on Sandy and Ivy Bridge; this would also lead to a maximum triad performance of 8 flops in 3 cycles. However, I can’t see it although the code is definitely AVX).

Ergänzung (12. Juni 2017)

In der Mittagspause mal kurz was gesucht und siehe da:
Schon im Releasetest auf CB:
https://www.computerbase.de/artikel...0x-1700-test.58350/seite-3#diagramm-handbrake

Handbrake 264 vs Handbrake 265

Ryzen ~150% Leistung von Kaby Lake in beiden Varianten (154% bei 264 und 145% bei 265 1700X vs 7700K).

x265 aber: 1700X / 7700K 128%.

In beiden Fällen ist es derselbe Ziel Codec etc...beide nutzen AVX AFAIK

Erklärung bitte ?

Mein Vorschlag:
=> Die Performancedifferenz in x265HD encode ist schlicht und ergreifend die Software...Handbrake ist hier eben schon deutlich besser angepasst.