Wie seht ihr die derzeit unterschiedlichen Architekturen von AMD und INTEL?
- Ersteller hoxi
- Erstellt am
Das trifft netterweise auch auf alle SiSoft benchmarks zu.
Jeder einzelne skaliert direkt linear mit kleinen abweichungen. Zumindest wenn man die 4.8Ghz vs 3.6GHz anschaut.
Das ist ja mal ganz gut zu wissen sofern das auf alle Archs übertragbar ist dann kann man im Grunde direkt umrechnen.
Jeder einzelne skaliert direkt linear mit kleinen abweichungen. Zumindest wenn man die 4.8Ghz vs 3.6GHz anschaut.
Das ist ja mal ganz gut zu wissen sofern das auf alle Archs übertragbar ist dann kann man im Grunde direkt umrechnen.
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.188
Dhrystone und Whetstone sind sogenannte Microbenchmarks. Die laufen praktisch komplett in den CPU-Caches ab. Selbst bei Matritzengrößen, die nicht mehr in den Cache* passen, sind die Speicherzugriffe so vorhersehbar, dass das Prefetching erschlägt. Insofern ist es kein Wunder, dass der Kram nahezu perfekt skaliert. Außer dem Durchsatz der Rechenwerke gibt es ja nichts, wovon der die Dinger abhängen.
Entsprechend kommt reale Software nie an diese Werte heran und reale Software skaliert auch anders. Bei realer Software greifen dann eben µOp-Caches, Sprungvorhersagen, Speicherverwaltung und die ganzen anderen Features die für einen guten Teil der Performance aktueller CPUs ausmacht.
Edit: * "Cache" stand da bis eben nicht, sondern "Ram" was aber falsch ist.
Entsprechend kommt reale Software nie an diese Werte heran und reale Software skaliert auch anders. Bei realer Software greifen dann eben µOp-Caches, Sprungvorhersagen, Speicherverwaltung und die ganzen anderen Features die für einen guten Teil der Performance aktueller CPUs ausmacht.
Edit: * "Cache" stand da bis eben nicht, sondern "Ram" was aber falsch ist.
Zuletzt bearbeitet:
IchoTolot
Banned
- Registriert
- Apr. 2017
- Beiträge
- 457
Genau das meine ich auch. Das wusste ich zwar jetzt nicht mit den Caches, aber ich hab schonmal vermutet, dass es eben synthetische Benchmarks sind die mit Anwendungen nichts zu tun haben. Zen kriegt bei x265 eben den Fuß nicht richtig auf den Boden.
@Pikto:
Danke für die Erklärung. Das hatte ich so gar nicht erwartet bei der Vielfalt an SiSoftbenches. Aber immerhin gut zu wissen das diese dann ja wirklich ziemlich gut ausschliesslich bestimmte Architektur-Features testen.
Und bei Handbrake h265 dann aber schon oder wie (siehe Benchmarks oben) ? Und das hängt nun wieso genau dann also von der CPU-Architektur ab und NICHT von der Software ?
Nochmal für alle die die Diskussion verfolgen meine Behauptung ist - das schlechte abschneiden von Ryzen in x265 hat NICHTS aber auch gar nichts mit der Architektur zu tun.
sonst müsste er im Handbrake h265 genauso schlecht sein.
Also erklär das mal Icho.
Danke für die Erklärung. Das hatte ich so gar nicht erwartet bei der Vielfalt an SiSoftbenches. Aber immerhin gut zu wissen das diese dann ja wirklich ziemlich gut ausschliesslich bestimmte Architektur-Features testen.
Und bei Handbrake h265 dann aber schon oder wie (siehe Benchmarks oben) ? Und das hängt nun wieso genau dann also von der CPU-Architektur ab und NICHT von der Software ?
Nochmal für alle die die Diskussion verfolgen meine Behauptung ist - das schlechte abschneiden von Ryzen in x265 hat NICHTS aber auch gar nichts mit der Architektur zu tun.
sonst müsste er im Handbrake h265 genauso schlecht sein.
Und der Vergleich oben ist noch mit mal Taktnormiert ! (1700X läuft hier vermutlich mit 3.4 GHz Base, der 7700K vermutlich mit 4.2GHz base takt)!
Also erklär das mal Icho.
Zuletzt bearbeitet:
Ah und CB ist unfähig zu testen oder wie ?
Nur mal angenommen Handbrake skaliert linear mit Takt - was denke ich für encoding schon gut gilt.
Aus dem CB Test:
Ryzen 1700X = 81s@ 3.6GHz (?) = 22.5s/GHz
7700K = 125s@ 4.2GHz (?) ?= 29.8s/GHz
22.5/29.8 = 75.5%
Der 7700 K ist also pro GHz nur ca 75% so schnell wie der Ryzen
Oder anders ausgedrückt ein 7700K bräuchte 5.5GHz takt um gleischnell zu sein wie der 1700X
Wo ist hier bitte der 7700 K Architekturiell stärker ?
Alternativ nehmen wir mal an ein virtueller 4C8T Ryzen mit 3.6GHz wäre genau halb so schnell wie der gemessene.
=>1700X@4C8T@3.6GHz = 162s (virtuell)
der 7700K wäre dann @4.2GHz ca 30% schneller...und das bei ca. 17% mehr Takt....
Das die KBL-Arch insgesamt etwa 8-10% mehr IPC durchbringt bei Komplexen Tasks wissen wir vom Cinebench.... + die 17% vom Takt ergibt irgendwas um 25% weniger IPC was man erwarten könnte wenn man einen 7700k 4C8T mit einem virtuellen 1700X 4C8T vergleicht.
CB hat ~30% IPC weniger @Ryzen gemessen die restlichen 5% die uns zu den oben abgeschätzten 25% Fehlen können wohl auf nicht so gute Paralleliesierung bei mehr als 8T verursacht sein. Wir wissen ja dass es mit zunehmender Threadzahl schwierig ist die Performance linear zu steigern.
also bei Handrake ist alles im Rahmen der Erwartung.
Wo also soll hier die oben vielzitierte AVX-Bremse sein oder sonst was ?
beim x265 hingegen ebenfalls bei CB gemessen:
1700X = 26.64 FPS = virtueller Ryzen @4C8T =13.32 FPS (@3.6GHz !)
7700K = 20.81 FPS (@4.2GHz)
=> 13.32/20.81 KBL ist hier plötzlich unerwartete 56% schneller in IPC als Ryzen wo wir ähnlich wie oben doch mit ~25% rechnen könnten...
=> Entweder das threading >8T funzt hier nicht
=> oder der IPC Durchsatz bei Ryzen ist irgendwie softwareseitig hier niedriger als er sein KÖNNTE für so eine Aufgabe (ich nehme hier mal an das h265 encode und x265 encode im wesentlich eine ähnliche Mathematik haben)
=> Kompiler ? Oder andere Optimierungen die h265 hat und x265 nicht.
Irgendwie sehe ich andere Benchmarks scheinbar als ihr...
Fazit: der x265 Encoder funktioniert unterdurchschnittlich schlecht@Ryzen. Was anderes kann man hier einfach nicht folgern.
Nur mal angenommen Handbrake skaliert linear mit Takt - was denke ich für encoding schon gut gilt.
Aus dem CB Test:
Ryzen 1700X = 81s@ 3.6GHz (?) = 22.5s/GHz
7700K = 125s@ 4.2GHz (?) ?= 29.8s/GHz
22.5/29.8 = 75.5%
Der 7700 K ist also pro GHz nur ca 75% so schnell wie der Ryzen
Oder anders ausgedrückt ein 7700K bräuchte 5.5GHz takt um gleischnell zu sein wie der 1700X
Wo ist hier bitte der 7700 K Architekturiell stärker ?
Alternativ nehmen wir mal an ein virtueller 4C8T Ryzen mit 3.6GHz wäre genau halb so schnell wie der gemessene.
=>1700X@4C8T@3.6GHz = 162s (virtuell)
der 7700K wäre dann @4.2GHz ca 30% schneller...und das bei ca. 17% mehr Takt....
Das die KBL-Arch insgesamt etwa 8-10% mehr IPC durchbringt bei Komplexen Tasks wissen wir vom Cinebench.... + die 17% vom Takt ergibt irgendwas um 25% weniger IPC was man erwarten könnte wenn man einen 7700k 4C8T mit einem virtuellen 1700X 4C8T vergleicht.
CB hat ~30% IPC weniger @Ryzen gemessen die restlichen 5% die uns zu den oben abgeschätzten 25% Fehlen können wohl auf nicht so gute Paralleliesierung bei mehr als 8T verursacht sein. Wir wissen ja dass es mit zunehmender Threadzahl schwierig ist die Performance linear zu steigern.
also bei Handrake ist alles im Rahmen der Erwartung.
Wo also soll hier die oben vielzitierte AVX-Bremse sein oder sonst was ?
beim x265 hingegen ebenfalls bei CB gemessen:
1700X = 26.64 FPS = virtueller Ryzen @4C8T =13.32 FPS (@3.6GHz !)
7700K = 20.81 FPS (@4.2GHz)
=> 13.32/20.81 KBL ist hier plötzlich unerwartete 56% schneller in IPC als Ryzen wo wir ähnlich wie oben doch mit ~25% rechnen könnten...
=> Entweder das threading >8T funzt hier nicht
=> oder der IPC Durchsatz bei Ryzen ist irgendwie softwareseitig hier niedriger als er sein KÖNNTE für so eine Aufgabe (ich nehme hier mal an das h265 encode und x265 encode im wesentlich eine ähnliche Mathematik haben)
=> Kompiler ? Oder andere Optimierungen die h265 hat und x265 nicht.
Irgendwie sehe ich andere Benchmarks scheinbar als ihr...
Fazit: der x265 Encoder funktioniert unterdurchschnittlich schlecht@Ryzen. Was anderes kann man hier einfach nicht folgern.
Ich hab keinen Ryzen:
Aber OC-at haben: leider ohne Handbrake versionsangabe
https://www.overclockers.at/articles/amd-ryzen-test
1700x@3.4GHz = 133s
7700K@4.2GHz = 166s
Und auch PC Perspective haben einen
https://www.pcper.com/reviews/Proce...view-Now-and-Zen/Media-Encoding-and-Rendering
Und du benutzt nicht zufällig QuickSync ?
Handbrake v1.02:
7700K "CPU" Mode: 534s@4.2GHz (?)
7700K mit QSV = 304s
1700 =392s (@3.0 GHz ? Base takt)
7700K/1700 = 534/392 = 136% KBL 36% langsamer als 1700
Virtuller Ryzen mit 4C8T =784s
7700K/1700 virtuell = 784/534 = KBL 47% schneller
Taktnormiert 36% + 10% IPC bedenken, erwarten wir KBL auf ca 46% IPC niveau des Ryzen....Also alles im Rahmen in dem Test bei PCPerspective.
Mit QSV allerdings...ist der KBL dann plötzlich 75% schneller als vorher...vielleicht mal nachschauen ob du nicht aus versehen immer mit QSV benchst wenn dein Kaby so unerhört schnell ist.
Aber QSV ist ein gesondertes features und eine extra hardwareeinheit nur zum x265 encodieren....die ähnlich wie eine GPU funktioniert. Ob dabei auch dieselbe identische Bildquali rauskommt sollte man auch erstmal prüfen !
Aber OC-at haben: leider ohne Handbrake versionsangabe
https://www.overclockers.at/articles/amd-ryzen-test
1700x@3.4GHz = 133s
7700K@4.2GHz = 166s
Und auch PC Perspective haben einen
https://www.pcper.com/reviews/Proce...view-Now-and-Zen/Media-Encoding-and-Rendering
Und du benutzt nicht zufällig QuickSync ?
Handbrake v1.02:
7700K "CPU" Mode: 534s@4.2GHz (?)
7700K mit QSV = 304s
1700 =392s (@3.0 GHz ? Base takt)
7700K/1700 = 534/392 = 136% KBL 36% langsamer als 1700
Virtuller Ryzen mit 4C8T =784s
7700K/1700 virtuell = 784/534 = KBL 47% schneller
Taktnormiert 36% + 10% IPC bedenken, erwarten wir KBL auf ca 46% IPC niveau des Ryzen....Also alles im Rahmen in dem Test bei PCPerspective.
Mit QSV allerdings...ist der KBL dann plötzlich 75% schneller als vorher...vielleicht mal nachschauen ob du nicht aus versehen immer mit QSV benchst wenn dein Kaby so unerhört schnell ist.
Aber QSV ist ein gesondertes features und eine extra hardwareeinheit nur zum x265 encodieren....die ähnlich wie eine GPU funktioniert. Ob dabei auch dieselbe identische Bildquali rauskommt sollte man auch erstmal prüfen !
Zuletzt bearbeitet:
JA richtig wir drehen uns im Kreis denn ich hab oben schon gesagt:
x265 encode im 3D-Center ist eine andere softwarepackage.
ABER ein "ähnliches" Programm (Handbrake h265) zeigt alles "normal" mit Ryzen => Performance-Erwartung mit x265 3DC sollte ähnlich sein wie Handbrake.
Im x265 encode von 3DC aber Ryzen deutlich lahmer als in Handbrake.
Fazit x265 encode "schlecht". Handbrake h265 verläßlich und erwartbare Resultate, x265 nicht.
Und das alles ganz ohne AVX etc...blablub.
x265 encode im 3D-Center ist eine andere softwarepackage.
ABER ein "ähnliches" Programm (Handbrake h265) zeigt alles "normal" mit Ryzen => Performance-Erwartung mit x265 3DC sollte ähnlich sein wie Handbrake.
Im x265 encode von 3DC aber Ryzen deutlich lahmer als in Handbrake.
Fazit x265 encode "schlecht". Handbrake h265 verläßlich und erwartbare Resultate, x265 nicht.
Und das alles ganz ohne AVX etc...blablub.
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
Handbrake nutzt auch den x265 , jedoch nicht nur AVX oder SSE - Auszug aus dem Log
x265 [info]: HEVC encoder version 2.1
x265 [info]: build info [Windows][GCC 5.3.1][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
dasselbe für x264
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
Hab mal MP4 ausprobiert
encavcodecInit: MPEG-4 ASP encoder
was soll ich sagen - statt 38 - 40 fps bei x264 sinds 75 - 80 fps 1080p30 HQ mit Surround
zur Quali kann ich noch nichts sagen , aber whow ...
x265 [info]: HEVC encoder version 2.1
x265 [info]: build info [Windows][GCC 5.3.1][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
dasselbe für x264
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
Hab mal MP4 ausprobiert
encavcodecInit: MPEG-4 ASP encoder
was soll ich sagen - statt 38 - 40 fps bei x264 sinds 75 - 80 fps 1080p30 HQ mit Surround
zur Quali kann ich noch nichts sagen , aber whow ...
Zuletzt bearbeitet:
x265 ist ja nur ein "Verfahren" zur Kompression von Filmdaten.
Wie das umgesetzt wird ist ggf. von Encoder zu encoder leicht verschieden. Aber vom grundprinzip her ist es bei allen gleich.
Interessant dass Handbrake noch mit einem uralt GCC5.3.1 kompiler erstellt ist. Welche Handbrakeversion ist das logfile ?
Wie das umgesetzt wird ist ggf. von Encoder zu encoder leicht verschieden. Aber vom grundprinzip her ist es bei allen gleich.
Interessant dass Handbrake noch mit einem uralt GCC5.3.1 kompiler erstellt ist. Welche Handbrakeversion ist das logfile ?
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
HandBrake 1.0.7 (2017040900) - 64bit
OS: Microsoft Windows NT 10.0.15063.0 - 64bit
CPU: AMD Ryzen 7 1700X Eight-Core Processor
Ram: 16320 MB,
GPU Information:
Radeon RX 580 Series - 22.19.171.1
müsste die neueste Handbrake Version sein
normalerweise müsste dieser MPEG-4 ASP Encoder ne wesentlich schlechtere Quali haben , er lastet die Kerne nur zu 30 % aus , Cpu wird grad mal 47 Grad warm und schmeisst trotzdem die doppelte FPS Anzahl raus ...
Nachtrag: wie gedacht - Quali ist schlecht , konnte eigentlich auch nicht anders sein , zwar ist die Datei nur 2,5 GB gross, bei x264 sind es 10 GB , jedoch nehm ich da lieber die doppelte encodierzeit und den 4 fachen Platz in Kauf
OS: Microsoft Windows NT 10.0.15063.0 - 64bit
CPU: AMD Ryzen 7 1700X Eight-Core Processor
Ram: 16320 MB,
GPU Information:
Radeon RX 580 Series - 22.19.171.1
müsste die neueste Handbrake Version sein
normalerweise müsste dieser MPEG-4 ASP Encoder ne wesentlich schlechtere Quali haben , er lastet die Kerne nur zu 30 % aus , Cpu wird grad mal 47 Grad warm und schmeisst trotzdem die doppelte FPS Anzahl raus ...
Nachtrag: wie gedacht - Quali ist schlecht , konnte eigentlich auch nicht anders sein , zwar ist die Datei nur 2,5 GB gross, bei x264 sind es 10 GB , jedoch nehm ich da lieber die doppelte encodierzeit und den 4 fachen Platz in Kauf
Zuletzt bearbeitet:
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.188
Iscaran schrieb:
Handbrake nutzt die freien x265 Bibliotheken und h265 ist der zugehörige Standard. Das was du da schreibst ergibt entsprechend keinen Sinn. Ryzen liefert in Handbrake unter Nutzung der x265 die Leistung ab die er liefert. Wobei die AVX2 Codepfade intensiv genutzt werden und da liefert Zen einfach genau die ~50% je Kern/Takt im vergleich zu aktuellen Intel CPUs ab die anhand der Architektur im Mittel zu erwarten sind. Das wurde dir mehrfach erklärt, und du behauptest immer noch, fest vom Gegenteil überzeugt zu sein.
Wenn dich der Unterschied zu Intel CPUs bei Verwendung der x264 / x 265 Bibliotheken stört, das ist leicht zu begründen. x265 Iteriert einfach wesentlich häufiger über Schleifen, die fleißig vektorisiert werden. Entsprechend steigt die Ausführungszeit, die die CPU mit AVX-lastigem Code zubringt. Entsprechend ist bei x265 jene CPU im Vorteil, die unter diesen Bedingungen mehr Durchsatz bietet. Bei x264 die anteilige Zeit, die mit AVX-lastigem Code zugebracht wird entsprechend kleiner. Aus veränderten Bedingungen resultieren andere Laufzeiten.
Aber ich glaube mittlerweile, du bist Fakten nicht mehr zugänglich.
###########
Anmerkung zur "uralten" Version von GCC: Solang man nicht -march=znver1 setzt sind die Optimierungen vom GCC für Zen reichlich egal. Nur setzt man bei Software die auf allen Plattformen laufen soll kein "-march" um auf eine einzige, spezifische Architektur optimiertes Binary zu enthalten. Standard ist ein -O2 zu setzen, damit generischen x86 kompatiblen Code zu erzeugen und fertig. Aggressivere optimierungen wie -O3 und eben das setzen von -march= zum erzeichen von Plattform spezifischen Binaries macht man nur, wenn man es sehr gut begründen kann (In der Regel mit Geld, 10% Performancegewinn wenn die Stunde im Rechenzentrum ab 10.000€ kostet rechtfertigt den erhöhten Aufwand beim Testen, Entwickeln und Debug).
Wenn sie wollen können die Zweifler sich da die neuste Version vom GCC holen und selber mal probieren wie groß der Unterschied zwischen
-O2
und
-O2 -march=znver1
ist. Fairerweise gehört ein Vergleich mit Kabylake / Skylake gemacht mit je -O2 und -O2 -march=skylake .
Oder auch beliebige andere Compiler, VisualStudio hat für Zen gepatchte Compiler dabei, Clang dürfte mittlerweile auch soweit sein. Nur zu und fröhliches Experimentieren.
Oder lernt halt gleich Assembler bis zum Level von AVX2.
########################
Der Vergleich der x264 / x265 Bibliotheken zu anderen Encodern wird vor allem Aufzeigen, dass die Encoder stark unterschiedlich gestaltet sind. Die Entwicklergemeinde um die x-Bibliotheken findet Qualität oft wichtiger als Geschwindigkeit und wenn Kompromisse eingegangen werden müssen schlagen die meist in die Richtung, dass man aufwendigere, qualitativ bessere Methoden wählen kann. Die zukünftigen CPUs werden ja sowieso immer leistungsfähiger, Qualitätsverluste lassen sich aber nachträglich nicht mehr kompensieren. Wohingegen kommerzielle Encoder mitunter mit einer hohen Geschwindigkeit werben, was all zu oft zu Lasten der Qualität wie auch Datenrate geht.
Wenn entsprechend ein anderer Encoder andere Verhältnisse in der Performance aufzeigt, dann zeigt das einfach nur, dass die Dinger anders agieren.
Was uns zurück zu diesen Mikrobenchmarks bringt. Die sind in ihrem Ablauf so strikt definiert, dass sie unter allen Umständen immer die selben, begrenzten Aussagen zulassen. Denn auch die simpelsten realen Anwendungen sind bei Zeiten in ihrem Laufzeitverhalten so komplex, dass es bei Zeiten unfassbar kompliziert wird.
Zuletzt bearbeitet:
@Piktogramm:
Ich habe MEHRFACH experimentell zugängliche GEMESSENE Werte genommen und dargelegt was an Performance hier rauskommt...50% je Kern/Takt kommen dabei eben nicht rum...
Gern darfst du mir versuchen vorzurechen welche Pro Kern/ Takt Leistung CB im Handbrake denn hatte und welche der KBL. Zahlen und Links sind weiter oben.
Es kommt raus dass Takt und Kern normiert Ryzen CA. das Niveau eines KBL -10% IPC hat. Wo siehst du denn hier 50% weniger Leistung als erwartet ?
Außer in dem x265 von 3DC....dort sind es ~25% weniger als erwartet.
Wenn du das gemacht hast darfst du mir gern nochmal erklären wo du hier 50% IPC vorteil PRO TAKT siehst...
Ich sehe das nicht. Die gemessenen Zahlen sagen was anderes.
Und man wird sich ja wohl noch wundern dürfen warum 2 Softwares die nahezu das gleiche machen eine 50% unterschiedliche Performance aufweisen (Handbrake H265 vs open x265) siehe ebenfalls z.B. werte von CB oben.
Die synthetischen Benches sind da wieder eine andere Geschichte.
Ich habe MEHRFACH experimentell zugängliche GEMESSENE Werte genommen und dargelegt was an Performance hier rauskommt...50% je Kern/Takt kommen dabei eben nicht rum...
Gern darfst du mir versuchen vorzurechen welche Pro Kern/ Takt Leistung CB im Handbrake denn hatte und welche der KBL. Zahlen und Links sind weiter oben.
Nur EIN beispiel...mit den Zahlen von CB funktioniert das genauso, mit denen von OCers auch...
Es kommt raus dass Takt und Kern normiert Ryzen CA. das Niveau eines KBL -10% IPC hat. Wo siehst du denn hier 50% weniger Leistung als erwartet ?
Außer in dem x265 von 3DC....dort sind es ~25% weniger als erwartet.
Wenn du das gemacht hast darfst du mir gern nochmal erklären wo du hier 50% IPC vorteil PRO TAKT siehst...
Ich sehe das nicht. Die gemessenen Zahlen sagen was anderes.
Und man wird sich ja wohl noch wundern dürfen warum 2 Softwares die nahezu das gleiche machen eine 50% unterschiedliche Performance aufweisen (Handbrake H265 vs open x265) siehe ebenfalls z.B. werte von CB oben.
Die synthetischen Benches sind da wieder eine andere Geschichte.
Zuletzt bearbeitet:
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.188
x264 und x265 sind reale Anwendungsprobleme und enthalten nicht ausschließlich AVX Code und verhalten sich entsprechend nicht auch nur annähernd linear zum durch die Architektur vorgegeben Durchsatz von AVX-Befehlen.
Wenn du einen Bench willst, der ausschließlich AVX Code enthält und damit spezifische Aussagen zulässt wie leistungsfähig die entsprechenden Rechenwerke sind, dann brauchst du besagte Mikrobenchmarks. Die zeigen so gut wie möglich die maximale, theoretische Leistung auf. Zieh dir Für Integer Rechnungen Drystone und compilier es mit den optimalen Einstellungen für Zen und einmal für Intel. Vergleich die Werte. Das Selbe machst du dann für die Gleitkommaleistung mit Whetstone und/oder Linpack.
Oder kauf dir wenigstens die sehr guten Artikel von der c't vom Heiseverlag zum Thema:
https://www.heise.de/ct/ausgabe/201...6-und-nagelneue-Windows-Compiler-3692115.html
Wenn du einen Bench willst, der ausschließlich AVX Code enthält und damit spezifische Aussagen zulässt wie leistungsfähig die entsprechenden Rechenwerke sind, dann brauchst du besagte Mikrobenchmarks. Die zeigen so gut wie möglich die maximale, theoretische Leistung auf. Zieh dir Für Integer Rechnungen Drystone und compilier es mit den optimalen Einstellungen für Zen und einmal für Intel. Vergleich die Werte. Das Selbe machst du dann für die Gleitkommaleistung mit Whetstone und/oder Linpack.
Oder kauf dir wenigstens die sehr guten Artikel von der c't vom Heiseverlag zum Thema:
https://www.heise.de/ct/ausgabe/201...6-und-nagelneue-Windows-Compiler-3692115.html
IchoTolot
Banned
- Registriert
- Apr. 2017
- Beiträge
- 457
Piktogramm schrieb:
Das merke ich leider sehr stark hier im Forum. Man wird verleumdet von manchen Leuten die Ergebnisse können nicht stimmen oder seien geschönt (ArmA3) was lächerlich ist, das hab ich nicht nötig. Ich habe mit am meisten hier dokumentiert wenn es um sowas geht, wer das nicht glauben will, dem kann man nicht mehr helfen. Gegenbeweise für die Verleumdungen, dass andere Ergebnisse stimmen würden gibt es keine. Denn niedergeschriebene Aussagen eines einzelnen Users sind kein Beweis. Melden bringt ja scheinbar auch nichts bei der Moderation, daher lösche ich meinen Account. Es gibt genug andere Foren wo sowas besser funktioniert..
Danke für den Artikel! Hab ihn mir gekauft und kleiner Auszug:
"Intel-Compiler für Ryzen
Wir waren dann noch neugierig und
wollten in Erfahrung bringen, wie sich
wohl die den AMD-Prozessoren vom Intel-Compiler
verweigerten höheren Optimierweihen
so auswirken..Ein kleiner
Patch an der richtigen Stelle wirkt Wunder
und schon laufen die AMD-Prozessoren
ohne erkennbare Probleme mit dem
hochoptimierten Intel-Code[..]
Insgesamt legt damit SPECfp
um 5 Prozent auf 65 Punkte zu. (Ryzen)..
..[..]
So schafft er
nur 57,8 SPECfp_2006_base, also 12 Prozent
weniger als Ryzen. (Broadwell). Der hochgetaktete
Kaby Lake entschwindet in dieser Diszi -
plin auf 83,1 SPECfp-Punkte."
Also man sieht, dass egal wie man es dreht, Ryzen in diesen Disziplinen langsamer ist.
Zuletzt bearbeitet:
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
hier mal nen Beispiel wie Aussagekräftig der SPECfp_2006_base ist... im Multicore Bereich
2 x 22 Kern CPU Intel Xeon E5-2699A v4 = SPECfp_base2006 = 121 2,4 Ghz Base / 3,6 Ghz Boost Takt
https://www.spec.org/cpu2006/results/res2017q2/cpu2006-20170515-47085.html
Du erreichst mit deinen 4 Core 2/3 des Wertes von einer 44 Kern Server Plattform - ist wohl Broadwell , obwohl erst 04/16 rausgekommen https://ark.intel.com/de/products/96899/Intel-Xeon-Processor-E5-2699A-v4-55M-Cache-2_40-GHz
das ist nen Skylake , 4C8T Intel Xeon E3-1260L v5 = SPECint_base2006 = 72.6
https://www.spec.org/cpu2006/results/res2017q2/cpu2006-20170511-47001.html
rausgekommen 4Q15 Base 2,9 Turbo 3,9 - da erscheinen die 83,2 eines Kabylake der normalerweise mit 4,2 Ghz taktet nicht mehr so hoch
https://ark.intel.com/de/products/88175/Intel-Xeon-Processor-E3-1260L-v5-8M-Cache-2_90-GHz
2 x 22 Kern CPU Intel Xeon E5-2699A v4 = SPECfp_base2006 = 121 2,4 Ghz Base / 3,6 Ghz Boost Takt
https://www.spec.org/cpu2006/results/res2017q2/cpu2006-20170515-47085.html
Du erreichst mit deinen 4 Core 2/3 des Wertes von einer 44 Kern Server Plattform - ist wohl Broadwell , obwohl erst 04/16 rausgekommen https://ark.intel.com/de/products/96899/Intel-Xeon-Processor-E5-2699A-v4-55M-Cache-2_40-GHz
das ist nen Skylake , 4C8T Intel Xeon E3-1260L v5 = SPECint_base2006 = 72.6
https://www.spec.org/cpu2006/results/res2017q2/cpu2006-20170511-47001.html
rausgekommen 4Q15 Base 2,9 Turbo 3,9 - da erscheinen die 83,2 eines Kabylake der normalerweise mit 4,2 Ghz taktet nicht mehr so hoch
https://ark.intel.com/de/products/88175/Intel-Xeon-Processor-E3-1260L-v5-8M-Cache-2_90-GHz
Zuletzt bearbeitet:
IchoTolot
Banned
- Registriert
- Apr. 2017
- Beiträge
- 457
Wenn du libquantum meinst - du hast auch gelesen was dazu im Artikel steht?
"Libquantum ist ohnehin ein außergewöhnlicher
Spezialfall, da die Intel-Compiler
diesen Code automatisch um riesige
Faktoren optimieren können. Das ist zwar
ein hübscher Vorzeigeeffekt, der aber an
der sonstigen Realität ziemlich vorbei
geht. "
"Libquantum ist ohnehin ein außergewöhnlicher
Spezialfall, da die Intel-Compiler
diesen Code automatisch um riesige
Faktoren optimieren können. Das ist zwar
ein hübscher Vorzeigeeffekt, der aber an
der sonstigen Realität ziemlich vorbei
geht. "
