Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Wie seht ihr die derzeit unterschiedlichen Architekturen von AMD und INTEL?
kenne den Artikel nicht , du hast den SPECfp_2006_base ins Spiel gebracht , ich nur die dazugehörige Datenbank
Zitat : 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."
oh beim 4 Kerner hatte ich wohl den specint erwischt daher hier Intel Xeon E3-1245 v6 =SPECfp_base2006 = 102 , bemerkenswert oder ? bei 3,7 Base und 4,1 Boost .. , Q1/17 soll nen Kabylake sein
Bevor ihr blind Werte vergleicht. Heise testet häufig mit Settings, die für die Listung auf spec.org invalid sind. Gerade die ganzen Optimierungen die da getestet werden versauen das Bild im Vergleich zu den offiziellen Listungen bei spec.org komplett. Der Artikel konzentriert sich in seiner Aussage ja schon eher, was man derzeit herausholen kann.
Piktogramm und Icho haben mir nun erklärt dass also KBL in AVX doppelt so viel micro-ops/Takt durch den Kern schafft als Ryzen und das deshalb in encode-arbeiten der ryzen entsprechend 50% abgehängt ist.
Ich hab dann dazu angebracht dass es doch seltsam ist dass diese Veränderung bei x264 encodierung nicht greift obwohl diese GENAUSO AVX einsetzt wie x265...
Ebenso verwunderlich ist dass wir bei einem anderen sehr ähnlichen Encodierprogramm (Handbrake mit h264 vs h265) solche Effekte ebenfalls nicht sehen.
So...hier ein abschließendes Bild um meine Verwunderung über die x264/x265 Performance zum Ausdruck zu bringen. Ich habe die Benchmarkdatenbank die oben verlinkt wurde etwas gekürzt und nicht relevante spalten versteckt. Die Daten wurden dann erstmal nach der SingleThread FPS im x265 sortiert und anschließend wurde in den Orangefarbenen Spalten die FPS/GHz berechnet und die relativen FPS/GHz in % des Kaby Lake der die höchste Singlethread FPS Performance erreicht hatte normiert.
Die Rote Spalte zeigt die RELATIVE x264 zu x265 performance für jede CPU an.
Die Rote Spalte ist was mich verwundert. Alle Intels seit SandyBridge haben 256Bit-AVX...
Erst seit Haswell hat Intel AVX-2 im Programm. Ryzen kann AVX-2 aber offensichtlich nutzt der x265 auf Ryzen nur AVX-1 und nicht AVX-2. Denn das würde erklären warum Ryzen äquivalen zu IvyBridge performed aber NICHT äquivalen zu Haswell.
Wenn es also an der langsamkeit der Verarbeitung der 256Bit-AVX Befehle, bei Ryzen läge, wie Piktogramm mir nahelegte, wäre:
1.) der Einbruch ziemlich genau 50% und
2.) Ivy und Sandy nicht betroffen da diese ebenfalls schon 256bit breite AVX-Register hatten AFAIK.
Aber bitte ihr dürft euch nun mit Erklärungsversuchen austoben.
*seufz* Mach ruhig weiter so. Du suchst Gründe und bist wirklich kreativ der einfachsten Lösung aus dem Wege zu gehen. Ryzen ist einfach langsamer. Das wurde doch nun wirklich durchgekaut. Jetzt kommst du mit der Theorie, dass wohl gar kein AVX2 benutzt würde. Fantastisch.
@Iscaran
Hier hast du zum Beispiel einen Benchmark, wo überraschenderweise ja der 7700K bei x265 vor Ryzen liegt, was du ja nie glauben willst. Ist sicher eine Verschwörung, ich hab mich mit der Webseite abgesprochen.
Bevor ihr blind Werte vergleicht. Heise testet häufig mit Settings, die für die Listung auf spec.org invalid sind. Gerade die ganzen Optimierungen die da getestet werden versauen das Bild im Vergleich zu den offiziellen Listungen bei spec.org komplett. Der Artikel konzentriert sich in seiner Aussage ja schon eher, was man derzeit herausholen kann.
Wenn der SPECfp_2006_base so leicht zu manipulieren ist , besitzt er eigentlich keine Aussagekraft weil man nie sagen kann ob Optimierungen / Manipulierungen vorgenommen wurden oder nicht
Der Offizielle wert des Intel Xeon E3-1245 v6 , ein Kabylake , ist mit 102 jedenfalls wesentlich höher als die zitierten 83,1 aus dem Artikel , obwohl der 7700 einen höheren Takt hat
von daher hat man wohl beim offiziellen wert " mehr herausgeholt " mehr " Optimiert " als beim Artikel
Boar, ich hab dir schon alles erklärt. Frag spezifisch nach, wenn dir da eine Erklärung unschlüssig erscheint.
Nochmals, Handbrake ist nicht irgendwie ähnlich zu x264 / x265, Handbrake nutzt für das Encodieren die x26X Bibliothken und h26X sind die entsprechenden Standards dazu. Dein gesamter zweite Absatz ergibt keinen Sinn.
AVX2 brachte überhaupt erst Support für Integer, AVX der ersten Generation beschränkt sich mehr oder weniger nur auf Float. Im großen und ganzen sind die Codecs jedoch massiv Integerlastig (eigentlich ausschließlich). Entsprechend ist AVX für die Codecs reichlich unbedeutend. Entsprechend sieht man in deiner Tabelle auch eine 1a Sprung im x265 zu x264 Performanceverhältnis bei den Intel CPUs ab Haswell. Da gab es auf einen Schlag AVX2 mit 256bit breiten Vektoren die in je einem Takt durchgenudelt waren.
Ansonsten, bevor du mit weiteren aus der Luft gegriffenen Vermutungen um die Ecke kommst, schau in den verdammten Quellcode und die Makefiles!
Ansonsten auch nochmal, die Videocodecs verbringen NICHT ihre gesamte Laufzeit mit AVX2-lastigem Code. Jedoch verbringt x265 wesentlich mehr Zeit mit AVX2-Code als x264. Entsprechend wirst du im realen Anwendungsfall des Videoencodings auch NIE sehen, dass die Encoder perfekt mit der theoretischen Leistungsfähigkeit einzelner Subsets der CPUs bieten. Deswegen mein letzter Hinweis auf Microbenchmarks, die soetwas aufzeigen können und komplexe Anwender wie Codecs eben nicht!
Anyway, solang es hier um das Verständnisunwillen Iscaran geht bin ich raus.
Ergänzung ()
MK one schrieb:
Wenn der SPECfp_2006_base so leicht zu manipulieren ist , besitzt er eigentlich keine Aussagekraft weil man nie sagen kann ob Optimierungen / Manipulierungen vorgenommen wurden oder nicht
Wieso sprichst du von Manipulation? Für die offiziellen Werte gibt es Vorgaben und Kontrolle dieser.
Das man ansonsten Software je nach Einsatz optimierter Bibliotheken, den paar hundert Compileroptionen die es gibt in ihrem Laufzeitverhalten massiv beeinflussen kann, ist für die Leute an sie sich Spec richtet überhaupt kein Geheimnis. Die Meisten verdienen sogar sehr gutes Geld damit Software best möglich zu optimieren und interessieren sich aufgrund dieser Möglichkeit mit dieser definierten Umgebung Erfahrungen zu auf neuen Plattformen zu sammeln. Genauso wie ARM, Intel AMD und wer noch so alles Prozessoren baut mit dieser Benchmarksuite zeigen wie gut ihr Ökosystem für die Entwickler ist und wieviel Optimierung da überhaupt möglich ist. Zu dem Thema spielt die c't und ix von Heise in sachen medialer Aufbereitung international sehr weit vorn mit.
Aber Spec ist eben kein Cinebench wo ein einzelner Wert herausfällt und das wars. Spec ohne Angabe unter welchen Einstellungen der Spaß kompiliert und ausgeführt wurde ist recht wertlos. Dummerweise ist eine gescheite Auswertung von Spec-Werten mit all den Einfluss nehmenden Parametern keine leichte Kost. Ich verstehe da auch nur recht kleine Teile von. Für die Aussage, das die Werte aus verschiedenen Quellen kaum vergleichbar sind reicht es .
Zu euren Benchmarkvergleichen: Solang ihr die Parameter nicht präzise kennt, braucht ihr echt nicht diskutieren. Version der x26X Bibliotheken, Compilersettings mit denen diese compiliert wurden, Ausgangsvideo, Parameter fürs Encoding etc. pp. lassen derart viel Streuung zu, dass eine Diskussion der Werte ähnlich sinnlos ist wie bei Spec.
Die Werte werden mit der Menge an möglichen Parametern halt ungenau, also nochmal. Wollt ihr euch über die Geschwindigkeit spezifischer Rechenwerke streiten, dann macht das mit etablierten Mikrobenchmarks unter Bekanntgabe aller Compilersettings.
Ergänzung ()
Aldaric87 schrieb:
Er belegt es doch mit Fakten, was willst du daran nun aussetzen?
Bisher hatten wir:
Verweise auf kurze Fachartikel, die er anscheinend nicht verstanden hat.
Benchmarkwerte, die er nicht gescheit interpretiert
Behauptungen zu Programmabläufen, die sich aus deren (frei verfügbaren!) Quelltext nicht ergeben.
Das hat mit Fakten nichts zu tun und davon sollte man ausgehen, wenn Heise, anandtech, arstechnica und alle die sonst noch umfangreiche Architekturanalysen sowie Betrachtungen zum Laufzeitverhalten von Benches / Programmen veröffentlichen in etwa das selbe Lied singen, dann wird keine Messwerttabelle dagegen anstinken. Vor allem nicht von jemanden, der h264, x264 und Handbrake durcheinander würfelt ohne die Zusammenhänge und Bedeutungen der Begriffe im Detail erfasst zu haben.
Nen Progammierer kann sicher mehr damit anfangen als ich , es werden auch tipps gegeben zb
2.11.3 FP performance on x87 code
1. Use fxch instead of push/pop if possible as it is much faster at swapping register values.
2. Avoid instructions between FCOM and FSTSW in floating point compares
oder
Code recommendations
1. Use the SIMD nature of the SSE or AVX instruction sets to achieve significantly higher
throughput. The AMD Family 17h processor supports SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2,
SSE4a, F16C, FMA, AVX, and AVX2. The datapath is 128 bits across all operations, so optimal
code will operate on 128b (XMM registers) or 256b (YMM registers) with every operation using
the SIMD instructions.
..
XMM register-to-register moves have no latency; These instructions may be used without penalty.
Intels Architektur von Skylake-X mit Mesh statt Ringbussen zeigt sich doch erst so langsam und scheibchenweise. Bevor man da was bewertet, sollte man also erst mal die Ergebnisse der Tests in den Reviews abwerten.
MK one, optimieren könnte man sicher viel, die Frage ist ob es sich lohnt und da ist es gerade bei kommerzieller SW oft so, dass eben niemand die Kosten dafür tragen möchte, während man bei Open Source vielleicht noch jemand findet der es für sein System haben möchte und daher macht. Daher ist es eben für die Masse der Anwender immer noch wichtiger eine CPU zu verwenden die mit bestehender SW schnell ist als eine die mit spezieller / speziell optimierter SW schnell sein könnte.
Beim OpenSource Kram kann man sich die Compilerflags ja beliebig selbst setzen. Wer Anpassungen will, kann sie haben ohne den Maintainern auf den Sack zu gehen
Es wäre untypisch, wenn bei OpenSource Projekten die Maintainer Architektur spezifischen Code aufnehmen. Viel Arbeit beim Schreiben, viel Arbeit beim Testen und viel Arbeit beim Verwalten und Warten. Das wären mal fix je 10 Architekturen ür Intel, 10 für AMD und eine Bazillion für die div. ARM Custom Cores. Freiwillig verwaltet so einen Mist niemand und gegen finanzielle Aufmerksamkeiten wird es absurd teuer.
Man stelle sich nur vor es wird ein Bug gefunden und man muss dann alle 30-40 Architekturen händisch korrigieren.
Wie gesagt, auf eine spezifische Architektur wird von Hand nur optimiert, wenn es sich finanziell massiv auswirkt.
Es geht darum dass der von Icho viel zitierte 3dCenter x265 encode irgendeinen seltsamen BIAS drauf hat auf den Werten.
Dieser Bias hat nichts aber auch gar nichts mit der AVX-Performance zu tun...es betrifft ja auch nicht NUR Ryzen.
Andere ähnliche Encoder Programme (z.B. Handbrake im CB-Test) zeigen 1:1 dieselbe skalierung für JEDE CPU an ob nun h264 oder h265 verwendet wird.
1.Fall: 3D-Center x264-x265 encode. Man untersuche die RELATIVE Skalierung der Performance für JEDE CPU einzeln zwischen x264 und x265
EDIT: Bild getauscht zur Verdeutlichung mit Markierung
Ich hab euch den relevanten teil markiert...Ryzen hat hier in x265 seltsamerweise 15% weniger Leistung.
2.Fall: Computerbase-Test, Handbrake h264-h265:
Hier sind ALLE CPUs mehr oder weniger gleich ~h265 ist ca 75% so schnell wie h264.
In Fall1 hingegen sind Intels neue Archs ca 60% so schnell, ältere Intel Archs und Ryzen hingegen sind nur 45% so schnell...
Ist das nun auffällig oder nicht ? Hat das irgendwas mit AVX zu tun ? Ich denke eher nicht.
Bitte warum soll das nun im x265 also irgendwas mit AVX zu tun haben - handbrake nutzt AVX genauso...scheinbar nur "besser" für Ryzen ?
EDIT: Komisches attachment verhalten vom Forum...seis drum beide grafiken sind nun online.
Und bei den alten Sandy und Ivy Bridge sind nur 42%, beim FX8350 und A10-7800 dagegen mit 45% bzw. 46% auch so viel wie bei RYZEN. Also hat AMD dort den Teil bei RYZEN gegenüber Vishera und Kaveri nicht entsprechend so weiterentwickelt das bestehenden SW damit auch schneller wird, während Intel dies beim Sprung von Ivy Bridge auf Haswell getan hat.
Das ist doch kein Beinbruch, dafür ist RYZEN in vielen anderen Bereichen ja besser, nur eben nicht in allen, auch wenn dies einige hier nicht einfach nicht akzeptieren können. Jede CPU hat eben Stärken und Schwächen, so auch RYZEN. Die Performance bei Nutzung bestimmter AVX Befehle in bestehender SW ist eben nicht unbedingt seine Stärke.
Und bei den alten Sandy und Ivy Bridge sind nur 42%, beim FX8350 und A10-7800 dagegen mit 45% bzw. 46% auch so viel wie bei RYZEN. Also hat AMD dort den Teil bei RYZEN gegenüber Vishera und Kaveri nicht entsprechend so weiterentwickelt das bestehenden SW damit auch schneller wird, während Intel dies beim Sprung von Ivy Bridge auf Haswell getan hat.
Der 3DC Bench ist schrott. Im Handbrake skalieren alle CPUs seltsamerweise gleich...
im 3DC x265 encode gibt es hier seltsame konstellationen...Vishera und Kaveri Supporten überhaupt kein AVX-2..
Wenn der bench also wirklich AVX2 nutzt dann sicherlich nicht für alle CPUs und damit sind die Werte Äpfel und Birnen wenn man Aussagen über die Architektureunterschiede daraus ziehen will.
Sand und Ivy haben btw. auch kein AVX2.
Wenn die in dem Test wirklich AVX1 gegen AVX2 gebenched haben dann macht das vielleicht noch halbwegs sinn. Aber auch da müsste sich dann ein Ryzen von einem Sandy absetzen weil Sandy noch nicht mal AVX2 kann und selbst das langsame AVX-2 des Ryzen hier besser performen muss als was sandy liefert.
=> Fazit der 3DC bench ist irgendwie für die Tonne.
Die Performance bei Nutzung bestimmter AVX Befehle in bestehender SW ist eben nicht unbedingt seine Stärke.
Das kann man aber aus dem von Icho angebrachten Bench leider eben nicht schlussfolgern.
Warum erklärst du nicht auch wieso dann im Handbrake Programm ALLE CPUS GLEICH skalieren ? Müssten die Architekturunterschiede hier nicht auch greifen ?!
Ich schreib gegen ne Wand
Bei deinem ersten Bild. Dazu nochmal. x264 wie auch x265 nutzen massiv Integerberechnungen. AVX wirkt sich jedoch nur auf Floatingpointoperationen aus, erst ab AVX2 gibt es die Erweiterung auf Integer. Haswell ist die erste Intel CPU die AVX2 nutzt und zwar mit einem Durchsatz von 256bit je Takt (im optimalen Fall). Das dem so ist zeigt sich PERFEKT in deiner bunten Tabelle, indem alle Intel CPUs ab Haswell.
Ryzen hat den Durchatz mit AVX2 nicht und skaliert entsprechend nicht mit dem AVX2 lastigen Code. Mit Bias hat das null zu tun.
Das die Zahlen von CB abweichen hat mit besagter Streuung zu tun. Je nach Settings verhält sich der Spaß eben massiv unterschiedlich. Entsprechend kann man sich das Vergleichen von solchen Werten aus verschiedenen Quellen schenken, wenn man keine weitere Dokumentation dazu hat.
Warum erklärst du nicht auch wieso dann im Handbrake Programm ALLE CPUS GLEICH skalieren ? Müssten die Architekturunterschiede hier nicht auch greifen ?!
Los. Ein Programm das dasselbe macht aber KEINE derartigen Diskrepanzen aufweist.
Ergänzung ()
Ryzen ist in AVX aber dennoch besser als Sandy oder Ivy...skaliert aber in dem 3DC-Test genau gleich...auch das passt nicht.
Ich warte auf eine logische Erklärung. Abgesehen davon dass du Recht hast dass mit unterschiedlichen Settings etc. unterschiedliche Ergebnisse rauskommen....Äpfel und Birnen Vergleich. Womit ich wieder bei der Aussage bin dass der 3DC-Test Äpfel und Birnen enthält und daher wenig/keine Aussagekraft.
Handbrake nutzt x264 / x265 insofern sind deine Vergleiche zwischen Handbrake und x265 / x 264 von 3D-Center Mumpitz. Es ist und ein und die selbe Bibliothek die da werkelt. Evtl. in unterschiedlichen Versionen und auf jeden Fall mit anderen Einstellung und wohl auch mit einem anderem, zu encodierenden Video.
WIeso soll ich dir irgendwas raussuchen? Dir wurde dargelegt, dass das Laufzeitverhalten mit anderen Parametern enorm abweichen kann und wird.
Du behauptest also dass 30% unterschiedliche Architekturskalierung zwischen Handbrake und 3dc x265 einfach durch unterschiedliche parameterwahl bzw. ein anderes encoding sample resultieren..
Wenn das so ist dann taugt das ja wohl erst recht nicht als "benchmark" für irgendwas.
Der Benchmark taugt dann etwas, wenn z.B. CB mit gleichem Quellmaterial und gleichen Einstellungen unterschiedliche CPU's vergleicht. Man kann aber den CB Benchmark nicht mit einem Benchmark von anderen Seiten vergleichen, weil Quelle und Parameter anders sein können.
