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

[Piktogramm]

"Ryzen im Intel Kompatibilitätsmodus"


Was soll eine x86 CPU sonst machen als Intel kompatibel zu sein? Das ist so bisschen das Hauptfeature eines X86ers. Ich würde mich beschweren, wenn Ryzen irgendwann nicht mehr Intel kompatibel ist!

Bei Ryzen werden keine enormen Verbesserungen über Softwareoptimierungen kommen. Die Patches für die Betriebssysteme sind alle gemacht, für die div. Compiler hat AMD länger nichts mehr geliefert und anscheinend auch nichts weiter in der Pipeline. Solang div. Software nicht noch div. massive Knoten in der Threadverwaltung hat, gibt es da schlicht wenig wirtschaftlich umsetzbares Potential. Im Bereich von Software für Endanwender setzt sich niemand hin und klöppelt auf CPU-Architekturen optimierten Assembler. Selbst den Compiler auf spezifische CPUs optimieren zu lassen kommt in der Regel nicht vor.


Was die Intel Optimierungen angeht. Intel hat ihre Compilersuite (ICC) und hat massig Optimierungen in die verbreiteten anderen Compiler eingebracht. Wenn man Intel CPUs kauft, kauft man das Ökosystem welches den Entwicklern bereitgestellt wird eben auch mit. Da bekommt Intel mit vollen Kassen, massiv Manpower und einer Architektur die evolutionär anstatt wie bei AMD in einem massivem Rutsch weiterentwickelt wird und damit das alte Ökosystem quasi komplett entwertet. Trotzdem ist die ganze Geschichte mehr als ein Achtungserfolg für AMD.


Was nerviger ist, die Ryzen CPUs scheinen doch ein paar bedeutendere Hardwarebugs zu haben. Zuletzt: https://community.amd.com/thread/215773

 

[MK one]

oh , ich denke schon das seitens AMD was kommen wird , sie wollen ja auch in den datacentern und im Serverbereich wieder Fuss fassen .
Was die " Bugs " angeht - wieviel " Errata " hat die i7 Generation ? wieviel davon wurden in der Hardware gelöst ? Keiner , es gab immer " Workarounds " , die Programmierer mussten drum herum arbeiten ..

Der " FMA " Bug wurde mit einer neuen Agesa 1004a gelöst , die Unterstützung von VM in der 1006 verbessert .

Wie gesagt , Ryzen ist neu , nicht die 7 oder 8 wiederaufbereitung derselben Architektur .
3 Monate in der freien Wildbahn sind nicht viel , außer dem FMA Bug ist allerdings auch nicht viel anderes bekannt geworden .

 

[aldaric]

Was nerviger ist, die Ryzen CPUs scheinen doch ein paar bedeutendere Hardwarebugs zu haben. Zuletzt: https://community.amd.com/thread/215773

Ich hab das Thema die letzten Tage in den US Foren verfolgt und bei den meisten haben Workarounds geholfen. "Bedeutende Hardwarebugs" sehen anders aus für mich. Siehe Skylake SATA Probleme.

 

[Piktogramm]

Kommen wir etwas, oder besser es wird kommen müssen. Ein Prozessor der Segfaults wirft, ohne das der Anbieter dafür nachhaltige Lösungen präsentiert wird im Serverumfeld niemand anfassen wollen. Das Problem ist da auch die Kommunikation von AMD. Der Thread wurde als beantwortet markiert, es gibt aber keine verlässliche, nach außen kommunizierte Lösung. Dabei sollen die Epyc Dinger am 20 Juni (in 7 Tagen) verfügbar sein. Gleichzeitig steht zu befürchten, dass sich das Problem mit noch mehr Kernen / Threads wahrscheinlich eher noch verschärfen wird.


Ansonsten hat jede aktuelle CPU eine erschreckend lange Liste an Bugs. Ich frage mich gelegentlich, wieso der ganze IT-Kram überhaupt funktioniert. Wenn es darum geht ein Dataceter zu bestücken ist das aber halbwegs egal, solang es Lösungen dafür gibt.


@Aldaric87
Segfaults sind ohne Frage ein größeres Problem und die temporären fixes die diskutiert werden schlagen meines Wissens alle auf die Leistungsfähigkeit der CPU durch. SMT zu deaktivieren bedeutet für so einige Anwendungsfälle von Servern einen sehr deutlichen Leistungsverlust und solche Späße wie dem Compiler via -j1 nur einen Threadzu spendieren obwohl 16 oder mehr möglich wären ist auch panne. Wobei es dann wieder Berichte gibt, das Agesa 1.0.0.6 etwas bringen soll, AMD dazu aber nichts offizielles liefert und es dann auch 1-2 Leute zu geben scheint die immer noch Segfaults bekommen.

 

[MK one]

Hast du dir die Beiträge mal genauer angesehen ? Bei den einen läufts , bei den anderen nicht , bei einem hilft der Austausch des Motherboards , bei dem anderen die Erhöhung der SOC Voltage , bei anderen hilft die Deaktivierung von SMT bei anderen nicht , bei einigen hilft die Deaktivierung des opcache bei anderen nicht .


mcl00 09.06.2017 06:52 (als Antwort auf: mcl00)
...
I may have have isolated my issue to the motherboard rather than the CPU itself. I got my hands on a Ryzen 5 1600X and ASRock Taichi x370 MB (BIOS P1.60 - pre-AGESA-1.0.0.4a) so I was able to do some mixing and matching of components.

I swapped out my R7-1700 for the R5-1600X and was able to reproduce the compiler segfaults at default settings very rapidly.

I then swapped out my motherboard (MSI x370 Gaming Pro Carbon) for the ASRock x370 Taichi and installed the R5-1600X in that board. I loaded the BIOS defaults and ran my tests. The system was significantly more stable while compiling, but it did 'hard' lockup on one overnight run (after 65 loops of compiling mesa-17.0) - i.e. the entire system froze and was unresponsive to the point that I had to power it off.
Finally, I updated the BIOS on the ASRock board to P2.30 (AGESA 1.0.0.4a), installed my R7-1700 and ran my tests in that configuration. With default BIOS settings, the R7-1700 was able to compile software all night with no segfault or hard lockup.

So I'm going to try to RMA my MSI Board as it seems to be the common denominator in my case for the lockups


??? in diesem Fall ein Fehler des Ryzen ? wohl kaum ... , mir scheint es eher Motherboard / Bios / Ram zu sein - ziemlich undurchsichtig das ganze ..

 

[Iscaran]

Danke Piktogramm für die Ausführungen!
Allerdings ist es dennoch verwunderlich dass z.B. x264 Encode massiv besser auf Ryzen läuft als x265 ?!? Das Kompressionsverfahren ist im wesentlich identisch. x265 ist halt nur ca faktor 10 mehr "aufwand"...
warum sollte also Ryzen hier plötzlich statt 150% der Leistung eines Kaby nur noch 116% der Leistung erreichen ?

https://www.computerbase.de/2017-03/amd-ryzen-1800x-1700x-1700-test/3/#diagramm-handbrake

Das ist es ja was mich irritiert !
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%.

Auch der quervergleich Handbrake 265 vs x265...Handbrake läuft fast 50% besser auf Ryzen als x265...

Das kann für mich nur einen Schluss bedeuten => SOFTWARE optimization required !

Die Seg faults sind zu 99% noch Probleme mit dem RAM-Anbindung und zu hoch OCtem oder getaktetem RAM.
Viele kriegen die Problem weg wenn sie ihr RAM z.B. von 3200 auf 2400 runterdrehen...ist das dann ein CPU-Fehler ?
Glaube eher nicht.

AGESA 1.008 ist doch auch schon in der Pipeline. Da geht also auch noch was.

Was die Compiler betrifft: GCC ist erst ab v7.1 etwa gleichgut für Ryzen und Intel afaik. die 6.3.3 hängt da doch noch etwas hinterher bei dem einen oder anderen Codepfad.
Der AMD-optimized C/C++ Compiler AOCC wurd erst im May released. Da wird es bestimmt auch noch updates geben. Aber schon jetzt ist der AOCC in dem einen oder anderen Fall mal eben 25% schneller als GCC 6.3 in 7 Fällen deutlich schneller. in 4 etwas langsamer im Rest ähnlich schnell:
http://openbenchmarking.org/result/1705194-TR-AMDAOCCRY26&obr_sas=y&obr_shm=y&obr_sgm=y&obr_sor=y

Speziell in Dense Matrix factorization (was denke ich AVX gemischt mit anderen Befehlssätze nutzt) ist der AOCC fast doppelt so schnell (~5600 vs 3300MFlops)

Zur AVX-Thematik gab es auch bei Golem eine nette Diskussion die das ganze gut summiert.
https://forum.golem.de/kommentare/s...efehlssaetze/107387,4741714,4742930,read.html

Ryzen hat zwei 128Bit AVX Register
> Kaby Lake hat ein 256Bit AVX Register
>
> Ja in 256Bit ist Kaby Lake schneller, Ryzen muss dazu beide Register
> bündeln.
> Die meisten genutzten AVX Befehle sind aber 128 Bit breit und da kann Ryzen
> zwei gleichzeitig abarbeiten, während Kaby Lake leider keine zwei in sein
> 256Bit Register bekommt, sondern dies bereits mit einem 128Bit Befehl voll
> ist. Du kannst dir also selbst ausmalen wer in der Praxis schneller ist.

EDIT: Allerdings wird beim Encodieren/komprimieren sehr wahrscheinlich auf die größtmögliche Matrix zurückgegriffen => AVX-256...dennoch sollte der Ryzen pro Takt hier denselben Durchsatz wie der Intel haben

Es kommt also sehr stark darauf an was für AVX-Code hier zur Anwendung kommt und WIE er der CPU via Compiler aufbereitet wird.

@128Bit AVX ist Ryzen ca. doppelt so schnell wir Intels Kaby
@256Bit AVX etwa gleichstand (Kaby etwas schneller wegen anderer Effekte)

@ MK one und Icho tolot. Könnt ihr eure FPU, AIDA und sonstwas benchmarks mal ein wenig besser aufbereiten ?
Ihr vergleicht hier Multithreaded benchmarks mit 8T vs 16T...und macht daraus schlüsse auf die Architektur und IPC ohne die Daten erstmal Taktnormiert und Threadnormiert anzusehen.

Teilt mal eure Benchmarkwerte durch die jeweiligen CPU-Takte und anzahl Threads und seht mal was dann bei rumkommt. Sonst ist das doch müßig.
Um mal einen Autovergleich zu bemühen (mein 4 Liter Turbo mit 500PS geht 300 auf der Autobahn, mein 8Liter Turbo mit 300 PS geht auch 300 auf der Autobahn...) Welcher Motor ist aber nun wo effizienter ?

 

[Piktogramm]

@MK one
Nunja, es ist massiv undurchsichtig, das ist ja das Problem. Im Gentoo Forum gibt es ja noch weit mehr Angaben. Da scheint das deaktivieren von SMT eine kleine Verbesserung zu geben, die Deaktivierung des Op-Caches bringt eine deutliche Verbesserung. Beides bringt jedoch (zuminest in der Theorie) einen ordentlichen Einbruch der Performance. Das Deaktivieren von ASLR scheint nachhaltig zu helfen, jedoch ist das so ein Feature das man in vielen Bereichen aus Sicherheitsgründen haben will. Wobei Segfaults bei aktivem ASLR darauf hindeuten, dass das Board keinen all zu großen Einfluss haben sollte. Bei Anderen hingegen hilft der Tausch des Boards, manchmal anscheinend auch Updates vom Agesa.
https://forums.gentoo.org/viewtopic-p-8075980.html#8075980


@Iscaran
CPUs müssen nicht in allen Fällen gleich skalieren. Im Zweifelsfall hängt x265 länger in Schleifen mit genau jenen Funktionen, die Ryzen nicht so gut beherrscht. Gerade wenn die Schleifen, die der Compiler vektorisieren kann deutlich länger laufen als bei x264 ist Ryzen im Nachteil. Da kann man nicht viel optimieren, wenn man es nicht auf eine bestimmte Architektur hin optimieren will. Das wird aber niemand tun, das steigert für meist sehr wenig Performancegewinn eine enorme Steigerung des Arbeitsaufwandes in der Entwicklung.
Die Äußerungen aus der Golemcommunity sind meines Wissens nach so nicht richtig.
https://www.heise.de/newsticker/meldung/AMD-Ryzen-Performance-unter-der-Lupe-3703483.html
Ryzen bringt je Kern über den Daumen je Kern etwa 50% des Durchsatzes unter AVX(2) haben als die Intel CPUs. Eben weil sich die 256bitigen Vektoren über 2 Register verteilt sind und das Rechenwerk zwei Takte braucht anstatt wie Intel derzeit nur einen.
Zudem die Behauptung, dass die meisten AVX Befehle eh nur 128bit Breite hätten. Die Compiler optimieren immer auf maximale Breite. So deppert da nur 50% der Möglichkeiten zu nutzen sind die Compilerentwickler schon nicht.


Was die Compiler angeht, AOCC kann wie der ICC wahrscheinlich massiv herumtricksen*. Für die meisten Anwendungen für Endanwender ist das aber in der Regel äußerst unbedeutend. Zumindest solang man kein Rechenzentrum hat und sich das Optimieren deutlich in der Kosteneffizienz des Rechenzentrums niederschlägt.

*Der Intelcompiler tauscht bei einigen Benches ganze Funktionsblöcke gegen händisch optimierte Assemberlblöcke und führt auch gern mal an einigen Stellen vorberechnete Werte ein und optimierte Bibliotheken gibt es auch hin und wieder. Das gibt dicke Benchmarkbalken, aber wenig für reale Anwendungen. Ich erwarte, dass AOCC Ähnliches macht.

 

[IchoTolot]

Teilt mal eure Benchmarkwerte durch die jeweiligen CPU-Takte und anzahl Threads und seht mal was dann bei rumkommt. Sonst ist das doch müßig.

Ich hab mich schon gewundert warum du überhaupt angefangen hast was auszurechnen weil bei meinen SiSoft Sandra Werten die Threadwerte ebenfalls stehen. Musst du nochmals auf den Screenshot schauen.

 

[Iscaran]

AOCC ist eigentlich eine modifizierte Form des LLVM/CLANG mit einer anderen user oberfläche. Also quasi ähnlich wie CLANG/LLVM. EDIT:https://en.wikipedia.org/wiki/AMD_Optimizing_C/C++_Compiler

Denke nicht dass man da groß durch Assembler tauscht. Zumal wenn du bei Phoronix schaust und auch in die Subforen die Arbeit am AOCC gerade erst Angefangen hat. (Release Mitte Mai !)
Da würde ich schon noch erwarten das gut was vorwärts geht.

Aber egal...das Compiler eben immer auf Maximale Breite des AVX-optimieren ist aber nicht immer sinnvoll ! Weder bei Intel CPUs noch bei anderen...und genau das ist evtl. ein Problem speziell bei Ryzen mit seiner Möglichkeit des vollen Durchsatzes von 2x128.
Evtl. gibts da ein Problem das Performance kostet wenn der Befehl in 1x256 ankommt was Ryzen ja unterstützt und dann das auf 2x128 gesplittet wird. Dazu kenn ich mich in den Details aber zu wenig aus um das abschließend beurteilen zu können.

Die Aussage von Golem deckt sich aber mit den Aussagen von Agner Fog, der Herr ist ein absoluter "Optimierungs"Papst und eine der Referenzen weltweit - sieh dir nur mal seine extensiven dokumentation zu den Befehlssätzen und optimierungswegen für die Unterschiedlichen CPU-Archs an !

Wenn Agner schreibt dass der 256 bit-AVX durchsatz eines Ryzen eigentlich gleich groß dem eines Intels (per clock !) ist dann sollte das auch so ankommen.

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.

=> Was macht hier der AVX-Teil vom x265 encoder dann anders dass hier AMD und Intel massiv unterschiedlich performen ?
Taktnormiert sind die Ergebnisse hier z.T. 50% "daneben"....das ist seltsam.

Schau dir den AVX-Test von Heise an:
https://www.heise.de/newsticker/meldung/AMD-Ryzen-Performance-unter-der-Lupe-3703483.html

R7-1800X hat ein Baseclock von 3.6GHz
Kaby 7700K hat Base 4.2GHz
Beim AVX Code parallelisert auf alle Threads wie bei Specint werden beide nicht Turbo gehen sondern mit Base clock arbeiten

4200/3600=+17% @Intel

Specint:
7700K @44.3
R7-1800X @33.6
44.3/33.6= +31% @Intel...rechnen wir die 17% Takt linear runter bleiben +14% / Clock pro Intel.

Das ist im Rahmen wenn man das mal mit dem Taktnormiert und zeigt das der AVX-Teil von AMD hier nur unwesentlich langsamer ist als erwartet.



@Icho habe nicht gesehen dass man die Bilder auch noch "scrollen" kann .
Könntet ihr dennoch eine "Übersichts"Liste der Werte erstellen....es ist schon schwer die Sachen im Kopf zu behalten und ständige auf screenshots schauen ist auch lästig, immer erst wieder den richtigen screenshot zu suchen.

Falls MK one und du weiter Interesse an dem Problem haben und ggf. mal weitere Benchmarks machen wollt um das besser zu verstehen wäre es am besten ihr würdet euch auf eine gemeinsame erreichbare Taktrate einigen mit die Benches dann ausgeführt werden. (Bsp. 3.6GHz oder so)

Auf Wiki kann man sehen dass es evtl ein paar interessante Testprogramme für AVX geben könnte um mal zu sehen ob diese auch alle gleich rauskommen
https://en.wikipedia.org/wiki/Advanced_Vector_Extensions

z.b:
https://www.blender.org/
https://www.openssl.org/
https://einsteinathome.org/de/home

Vergleiches von Ryzen vs Kaby in den Programmen bei gleichem Takt wären also vielleicht aufschlussreich.

 

[MK one]

Praxisbezogen kann ich sagen : h265 codiert dasselbe Material nicht langsamer als h264 in Handbrake , eher einen Tick schneller ... , genutzt wird bei mir immer HQ1080p 30 fps mit surround

Deswegen finde ich es merkwürdig das du sagst AVX wäre in h264 schneller als in h265

 

[Iscaran]

@Mk One:

Sag ich doch gar nicht !

nur der x265 encode ist LANGSAMER als der x264 encode und das obwohl der Handbrake h264 und h265 auf Ryzen relativ zu Kaby JEWEILS immer gleich schnell ist (siehe oben und CB Grafiken).

Beide Encoder machen im wesentlichen das gleiche...wenn der x265 nun also plötzlich 50% langsamer ist kann das eigentlich kein Effekt der CPU sein.

 

[Piktogramm]

Denke nicht dass man da groß durch Assembler tauscht. Zumal wenn du bei Phoronix schaust und auch in die Subforen die Arbeit am AOCC gerade erst Angefangen hat. (Release Mitte Mai !)
Da würde ich schon noch erwarten das gut was vorwärts geht.

Phoronix wird von Einigen nicht ganz grundlos als Bild der Linuxwelt bezeichnet. Da sind immer mal wieder gute Sachen zu finden, aber wirklich beliebt ist die Quelle nicht .
Heise hat bereits einen Artikel hinter sich, bei dem die Compiler samt div. Optimierungen getestet wurde und da kam nicht so viel bei rum. Selbst bei Optimierungsgraden die für alltägliche Software für den Massenmarkt nicht gewinnbringend sind. Wenn da irgendwie noch ein deutlicher Sprung kommt, dann ist es einfach wahrscheinlich, dass da tief in die Trickkiste gegriffen wird. Alles Andere wäre recht untypisch (wenn auch nicht gänzlich unmöglich).

Aber egal...das Compiler eben immer auf Maximale Breite des AVX-optimieren ist aber nicht immer sinnvoll ! Weder bei Intel CPUs noch bei anderen...

Wenn man anstatt 2x 128bit anzufassen einmal 256 oder gar 512bit anfassen kann, dann sollte man in die Breite gehen. Bei Intel skaliert der Spaß mit der Breite halbwegs linear hoch und bei Ryzen sind 2x 128bit Operationen annähernd gleich schnell wie 1x 256bit. Insofern gibt es keinen Grund da eine Einschränkung vorzunehmen, da es keinen Vorteil für Ryzen böte, aber einen enormen Nachteil für alle Intel CPUs.

und genau das ist evtl. ein Problem speziell bei Ryzen mit seiner Möglichkeit des vollen Durchsatzes von 2x128.
Evtl. gibts da ein Problem das Performance kostet wenn der Befehl in 1x256 ankommt was Ryzen ja unterstützt und dann das auf 2x128 gesplittet wird. Dazu kenn ich mich in den Details aber zu wenig aus um das abschließend beurteilen zu können.

Es gibt bei Zen wenige Operationen die ein Penalty >2 Take haben wenn 256bitige Befehle umgewälzt werden. Best Practice ist da aber das nicht zu berücksichtigen. Das was sich da optimieren ließe würde Zen wenig bringen, würde aber enorme Nachteil für alle anderen Liefern. Dann lieber ein kleiner Nachteil für Zen und keine Nachteile für alle Anderen.

Wenn Agner schreibt dass der 256 bit-AVX durchsatz eines Ryzen eigentlich gleich groß dem eines Intels (per clock !) ist dann sollte das auch so ankommen.

=> Was macht hier der AVX-Teil vom x265 encoder dann anders dass hier AMD und Intel massiv unterschiedlich performen ?
Taktnormiert sind die Ergebnisse hier z.T. 50% "daneben"....das ist seltsam.

Das schreibt er so nicht. Der gute Mann geht ein Stück weiter ins Detail, wonach es 256bit Instruktionen gibt, die Zen mit dem selben Durchsatz abhandeln kann. FMA als Beispiel schafft AMD nur mit dem halben Durchsatz, Ebenso wie der write-port bei AMD 128bit breit ist und bei Intel 256bit. In vielen Fällen hat damit Intel den um grob Faktor 2 besseren Durchsatz je Kern und Takt.

Schau dir den AVX-Test von Heise an:
https://www.heise.de/newsticker/meldung/AMD-Ryzen-Performance-unter-der-Lupe-3703483.html

R7-1800X hat ein Baseclock von 3.6GHz
Kaby 7700K hat Base 4.2GHz
Beim AVX Code parallelisert auf alle Threads wie bei Specint werden beide nicht Turbo gehen sondern mit Base clock arbeiten

4200/3600=+17% @Intel

Specint:
7700K @44.3
R7-1800X @33.6
44.3/33.6= +31% @Intel...rechnen wir die 17% Takt linear runter bleiben +14% / Clock pro Intel.

Das ist im Rahmen wenn man das mal mit dem Taktnormiert und zeigt das der AVX-Teil von AMD hier nur unwesentlich langsamer ist als erwartet.

Nicht nur auf den Takt normieren sondern auch die Anzahl Kerne. Mit Auge zu kommt Zen da wieder bei ~50% Durchsatz von AVX Befehlen je Kern und Takt heraus im Vergleich zu Intel.


Finde dich damit ab, Zen ist eine sehr gute Architektur, aber kein Überflieger auf allen Ebenen und das wird auf Softwareebene auch nicht mehr ausgeglichen werden.

 

[MK one]

ist doch kappes , warum unbedingt von einer Version für alle ausgehen wenn man leichte Anpassungen vornehmen könnte , gibt's halt nen Intel h265 Encoding Codec und nen AMD h265 Encoding Codec .

Darum geht es doch , Intel FPU und AMD FPU sind nicht baugleich , warum unbedingt denselben Codec nehmen - nur weil es bequemer ist ?
Darum geht es doch bei einer Optimierung , Architekturbedingte stärken ausnutzen , die schwächen nach Möglichkeit umgehen .


Nehmen wir zb mal den Tombraider Patch https://www.golem.de/news/rise-of-the-tomb-raider-ryzen-dx12-patch-sorgt-fuer-mehr-bilder-pro-sekunde-1706-128205.html

Nixxes zufolge wurde die Geschwindigkeit in CPU-limitieren Szenarien optimiert. Die Entwickler führen weiter aus, dass die Rendering-Tasks für Ryzen nicht die richtige Größe gehabt hätten. Durch das Zerlegen in kleinere Tasks sowie das Zusammenlegen einiger anderer habe der Scheduler-Overhead verringert und so die Zahl der nutzbaren Threads erhöht werden können. Das führt laut Bericht zu mehr Leistung. Hinzu kommt eine überarbeitete Texturverwaltung beim Einsatz einer Geforce-Grafikkarte. Auch hier konnte der Overhead durch Optimierungen reduziert werden.

15 - 30 Prozent schneller sind schon ne Hausnummer , gut , das hat jetzt nichts mit AVX zu tun ... - aber es zeigt doch das man , wenn man besser auf die Architektur des Ryzen eingeht , einiges rausreissen kann

 

[IchoTolot]

ist doch kappes , warum unbedingt von einer Version für alle ausgehen wenn man leichte Anpassungen vornehmen könnte , gibt's halt nen Intel h265 Encoding Codec und nen AMD h265 Encoding Codec .

Darum geht es doch , Intel FPU und AMD FPU sind nicht baugleich , warum unbedingt denselben Codec nehmen - nur weil es bequemer ist ?

Ja die Welt ist eben nicht gerecht! Warum sollte sich jemand die Mühe machen? Für die paar Ryzensysteme die im Umlauf sind? Sicher nicht. So funktioniert eben die Welt. Sie ist nicht immer schön, aber so ist das eben. Wenn AMD eben meint, sie müssen andere Wege gehen, dann sind da auch die Konsequenzen zu tragen. Intel hat auch Schwachstellen, jammert deswegen jeder rum, dass da nun unbedingt eine Inteloptimierung bei Software xx zu machen sei? Nein.

Wie Piktogramm schon sagte, findet euch damit ab dass Ryzen eben auch Schwachstellen hat.

 

[aldaric]

Finde dich damit ab, dass die Welt sich nicht um Intel dreht. Schon immer passt sich Software an Hardware an, nicht anders herum. Gut das die Entwickler verschiedener Applikationen das auch grundlegend anders sehen als du.

 

[Iscaran]

Das schreibt er so nicht. Der gute Mann geht ein Stück weiter ins Detail, wonach es 256bit Instruktionen gibt, die Zen mit dem selben Durchsatz abhandeln kann. FMA als Beispiel schafft AMD nur mit dem halben Durchsatz, Ebenso wie der write-port bei AMD 128bit breit ist und bei Intel 256bit. In vielen Fällen hat damit Intel den um grob Faktor 2 besseren Durchsatz je Kern und Takt.

FMA hat aber wieder einen eigenen Befehlssatz - reden wir jetzt hier über den AVX durchsatz oder den FMA durchsatz ?
Oder gar das es nur dann ein Problem gibt wenn man AVX 1:1 mit FMA Code mischt ?

Ebenso wie der write-port bei AMD 128bit breit ist und bei Intel 256bit. In vielen Fällen hat damit Intel den um grob Faktor 2 besseren Durchsatz je Kern und Takt.

Zum Einfluss des Writeport auf die Gesamtperformance hab ich zuwenig infos derzeit...aber wenn das der Fall wäre das das direkt linear ein Faktor 2 Performance ausmacht meinst nicht dass Herr Fog darauf hingewiesen hätte ?
Bzw. wozu dann überhaupt diskutieren dass man mit 2x128 denselben durchsatz hat wenn man dann doch nur 1x128 ausgeben kann ?

Ist es nicht so das das Produkt der Operation eventuell eine "kleinere" Größe hat als die Eingangsdaten ?

Finde dich damit ab, Zen ist eine sehr gute Architektur, aber kein Überflieger auf allen Ebenen und das wird auf Softwareebene auch nicht mehr ausgeglichen werden.

Ist mir bewusst und das Zen ein Überflieger auf allen Ebenen ist hab ich auch nie behauptet...ich wunder mich nur über diverse inkonsistente Ergebnisse die viele "der einfachheit" halber direkt auf die Architektur schieben, wo es dafür aber keinen Anlass gibt.

Darum geht es doch , Intel FPU und AMD FPU sind nicht baugleich , warum unbedingt denselben Codec nehmen - nur weil es bequemer ist ?
Darum geht es doch bei einer Optimierung , Architekturbedingte stärken ausnutzen , die schwächen nach Möglichkeit umgehen .

Exakt. Interessant für die Optimierung sind genau die Fälle wo es zunächst auf der einen Arch einen massive Penalty gibt, aber durch Umstrukturierung dann plötzlich 25, 50% gewonnen werden können.

Genau darum gehts. Wenn auf microp-op basis der Durchsatz stimmt, aber HINTEN 50% zuwenig rauskommt sollte man sich auf die Suche machen und rausfinden wo die 50% liegen bleiben.

EDIT: von Wann ist der Golem-Artikel zu TombRaider ? Gab es da nochmal einen Patch für Ryzen ?

Die Entwickler führen weiter aus, dass die Rendering-Tasks für Ryzen nicht die richtige Größe gehabt hätten. Durch das Zerlegen in kleinere Tasks sowie das Zusammenlegen einiger anderer

Das klingt mir ganz danach was auch NikosD spekuliert hat das es einen Unterschied macht ob man an Ryzen einen 256Bit AVX hash schickt oder 2x128bits.
Oder das man genau so z.B. AVX-256 Bit Register für Intel geschrieben hatte und nun dafür sorgt das auf einem Ryzen z.B. korrekterweise ein 128Bit AVX Register + parallel anderem Code zur Ausführung angewendet wurde (was ja bei Intel grundsätzlich NICHT von den Compilern gemacht wird)

 

[MK one]

auch kappes , warum sollte man keine Schwachstellen aufdecken die die Ryzen Performance ausbremsen . AMD hat auch schon für ihre Graka s h264 und h265 De und Encoder programmiert , wer sollte sie dran hindern das auch für Ryzen zu tun ?
Früher oder später gibt es Verbesserungen / Optimierungen , mag seine Zeit dauern , aber es wird sie geben , falls / wenn sie was bringen ...
Es geht ja nicht darum das Rad neu zu erfinden , sondern nur darum die Datenpakete " mundgerechter " zuzuteilen .

Ergänzung (13. Juni 2017)

Der Patch dürfte vom 31.05 sein http://www.gamestar.de/artikel/ryzen-patch-fuer-rise-of-the-tomb-raider-teils-ueber-30-prozent-mehr-leistung-unter-directx-12,3314847.html

AMD hatte bereits zum Release von den ersten Ryzen-Prozessoren Anfang März betont, dass aktuelle Spiele-Engines noch nicht immer optimal mit der neuen Zen-Architektur umgehen und dass Patches hier in Zukunft für spürbare Verbesserungen sorgen könnten.

 

[Piktogramm]

Auf Ryzen zu optimieren macht man nicht, genauso wie man bei 0815 Software auf jeden einzelne Intel Architektur optimiert. Der Aufwand den Mist zu warten und zu testen ist VIEL höher als die Vorteile die man da rausbekommt. Deswegen sehen die Codpfade einen Check auf AVX(2) vor und wenn vorhanden wird der Kram den CPU zum Fraß vorgeworfen.
Das in einigen Anwendungsgebieten es sein kann, dass man Knoten angeht indem man die Threadverwaltung anpasst. Es ist aber ein wesentlicher Unterschied, ob man Performanceprobleme fixt, oder ob man Optimiert wo kein Bedarf ist (Stichwort: Premature Optimization).


Vektorisierte Rechnungen können und nutzen häufig FMA bzw. andere SIMD-Instruktionen. Alles andere wäre auch deppert. Da fasst man Rechnungen als Vektoren erheblicher Breite zusammen und anstatt Multiplikation und Addition wie seit Jahren zusammenzufassen rechnet man den Mist nochmal einzeln.

Und die Architektur von Zen ist einfach so, dass für die aller meisten AVX2 Workloads 50% der Leistung je Kern und Takt haben als die Intel CPUs. Was sich oftmals verschmerzen lässt.

 

[IchoTolot]

@Icho habe nicht gesehen dass man die Bilder auch noch "scrollen" kann .
Könntet ihr dennoch eine "Übersichts"Liste der Werte erstellen....es ist schon schwer die Sachen im Kopf zu behalten und ständige auf screenshots schauen ist auch lästig, immer erst wieder den richtigen screenshot zu suchen.

Falls MK one und du weiter Interesse an dem Problem haben und ggf. mal weitere Benchmarks machen wollt um das besser zu verstehen wäre es am besten ihr würdet euch auf eine gemeinsame erreichbare Taktrate einigen mit die Benches dann ausgeführt werden. (Bsp. 3.6GHz oder so)

z.b:
https://www.blender.org/

Wegen mir. Welche Taktrate? Was schafft der Ryzen?

• Also mal die Ergebnisse vom Benchmark aus SiSoft Sandra mit 4.8 Ghz und NB auf 4.4 Ghz.

Prozessorgesamtleistung: 155.45 GOPS
Dhrystone Integer AVX2: 205.41 GIPS
Dhrystone Lange-Integer AVX2: 220.73 GIPS
Whetstone Fließkomma FP32 AVX: 129.29 GFLOPS
Whetstone Fließkomma FP64 AVX: 107 GFLOPS
Dhrystone Gesamtleistung-int: 213 GFLOPS
Whetstone Fließkomma FP32/64: 117.64 GFLOPS

Leistung pro Thread:

Prozessorgesamtleistung: 19.43 GOPS
Dhrystone Integer: 25.68 GIPS
Dhrystone Lange-Integer: 27.59 GIPS
Whetstone Fließkomma FP32 AVX: 16.16 GFLOPS
Whetstone Fließkomma FP64 AVX: 13.38 GFLOPS

• Hier die Ergebnisse vom Benchmark aus SiSoft Sandra mit 3.6 Ghz und NB auf 4.4 Ghz.

Prozessorgesamtleistung: 115.52 GOPS
Dhrystone Integer AVX2: 150.8 GIPS
Dhrystone Lange-Integer AVX2: 165.76 GIPS
Whetstone Fließkomma FP32 AVX: 98 GFLOPS
Whetstone Fließkomma FP64 AVX: 80 GFLOPS
Dhrystone Gesamtleistung-int: 158.1 GFLOPS
Whetstone Fließkomma FP32/64: 88.5 GFLOPS

Leistung pro Thread:

Prozessorgesamtleistung: 14.44 GOPS
Dhrystone Integer: 18.85 GIPS
Dhrystone Lange-Integer: 20.72 GIPS
Whetstone Fließkomma FP32 AVX: 12.24 GFLOPS
Whetstone Fließkomma FP64 AVX: 10 GFLOPS

• Blender hatte ich schon mal gepostet.

Da sind es mit AMD Logo:

CPU 4.8 Ghz
32.56 Sekunden

​CPU 4.4 Ghz
35.97 ​Sekunden

CPU 3.6 Ghz
44.28 Sekunden

 

[Alefthau]

Was nerviger ist, die Ryzen CPUs scheinen doch ein paar bedeutendere Hardwarebugs zu haben. Zuletzt: https://community.amd.com/thread/215773

Wenn ich mich recht entsinne wird eher vermutet, dass es via Microcode-Update behoben werden könnte, aber auch ein Software-Problem war in der "Hitliste"!

Der VM-Bug wurde auch erst aufgenbauscht, ist aber letztlich durch Microcode-Update behoben worden und auch Intel hat diverse Updates hinter sich bei neuer Hardware.

KEINE neue Hardware/Software ist bugfrei, es dauert oft nur ein wenig diese zu finde...

Gruß

Alef