Artikel AMD Ryzen Threadripper 1950X - Part Two

@MusicIsMyLife
Das es an meiner GPU Config liegen könnte hatte ich mir fast schon gedacht denn mit der Nano lief er auf dem Ryzen System ja ähnlich schlecht.
Es wäre mal interessant zu wissen ob es an deren Stromsparverhalten liegen könnte.

Hat nicht mal wer ne Fury oder FuryX zur Hand auf der er es mal laufen lassen könnte?

Vielleicht hat Onkel_Dithmeyer noch seine R9 Nano...



Ich werde jetzt noch ein paar HandBrake-Durchläufe machen, um für Casi030 ein paar Ergebnisse zur Hand zu haben. :)

Gesagt, getan.

Hier die Übersicht der Ergebnisse:

attachment.php


Das sind die Daten jeweils eines Durchlaufes. Was sehen wir darauf:

- die Konfigurationen ohne SMT skalieren bis zur vollen Kernanzahl
- die Konfigurationen mit SMT skalieren bis zur vollen Threadanzahl
- SMT on und SMT off skalieren unterschiedlich gut, sodass 16/16 letztendlich schneller ist als 16/32
- SMT bringt bei Ryzen Threadripper bis 12/24 einen Performance-Vorteil

HandBrake kommt an der Stelle ab einem gewissen Punkt mit der Thread-Anzahl "durcheinander". Wenn ich bei 16/32 zwei Mal das gleiche Video bearbeiten lassen, so komme ich bei einer Instanz auf 34,3 FPS und bei der zweiten auf 39,6 FPS. Zusammen kann HandBrake in zwei Instanzen also gleichzeitig 73,9 FPS bearbeiten, wobei die Leistungsaufnahme auf durchschnittliche 231,7 Watt steigt. Das sind rund 18 Prozent mehr Verbrauch bei etwa 36 Prozent höherer Leistung.
 

Anhänge

  • HandBrake_Nachtests.png
    HandBrake_Nachtests.png
    21,8 KB · Aufrufe: 273
Hat nicht mal wer ne Fury oder FuryX zur Hand auf der er es mal laufen lassen könnte?

Reicht da die frei verfügbare Lite Version zu? Und ist es egal in welcher Plattform die Fury X steckt?

Wo bei "Works on Domain" auch noch ein Hindernis für mich wäre.
 
Mehr habe ich auch nicht genutzt. :)
Da es nur um das Verhalten bei dem GPU Test geht gehe ich davon aus das die Plattform egal ist.

--- Update ---

@ MusicIsMyLife
Interessante Ergebnisse die du da zusammengetragen hast.
Bei 12 Kernen skaliert er noch ein wenig mit SMT aber bei 16 Kernen dreht es sich sogar ins negative.
Mit 24 Threads kommt es also noch halbwegs zurecht aber bei 32 Threads stehen sie sich schon gegenseitig im Weg.
 
Dann probiere ich es wenn wieder @home mit der Fury X aus - zur Not muss ich den Rechner mal aus der Domäne nehmen. Steckt in einem X79/I7 4930k System.
 
@ MusicIsMyLife
Interessante Ergebnisse die du da zusammengetragen hast.
Bei 12 Kernen skaliert er noch ein wenig mit SMT aber bei 16 Kernen dreht es sich sogar ins negative.
Mit 24 Threads kommt es also noch halbwegs zurecht aber bei 32 Threads stehen sie sich schon gegenseitig im Weg.

Das stimmt.

Wenn man die Konfigurationen mit und ohne SMT separat betrachtet, so fällt auf, dass die Skalierung immer schlechter wird.

Von 4/8 zu 8/16 haben wir eine Verdoppelung der Threadanzahl, aber nur ~81 Prozent mehr Leistung. Von 8/16 zu 12/24 steigen die Ressourcen um 50 Prozent, die Leistung aber nur um ~26 Prozent. Von 12/24 zu 16/32 gibt es noch einmal ein Drittel Leistung dazu, die Performance steigt aber nur um magere 7 Prozent. Vermutlich würden 20 Kerne mit SMT dann eine schlechtere Leistung bieten als 16/32.

Auch ohne SMT steigt die Leistung nicht in dem Maße, wie es die Ressourcen tun. Bei 4/4 zu 8/8 passt es - da wird die Leistung verdoppelt. Aber von 8/8 zu 12/12 kommen von den 50 Prozent Mehrleistung nur noch rund 35 Prozent an. Und von 12/12 zu 16/16 sind es nur noch rund 23 Prozent, die vom Drittel Mehrleistung übrig bleiben. Vermutlich würde ein Threadripper ohne SMT bis 20/20 oder gar 24/24 skalieren. Erst darüber hinaus wird es wohl auch eine negative Entwicklung geben.

Das Beispiel zeigt aber: Eigentlich testet man nicht mehr die Leistungsfähigkeit der CPU sondern in diesem speziellen Fall eher die Leistungsfähigkeit der Software. In den Artikeln wurde ja bereits vermutet, dass HandBrake quasi am Ende seiner Skalierungsmöglichkeiten ist. Möglicherweise müssen die Qualitätseinstellungen erhöht werden, oder aber mehrere Projekte gleichzeitig gerechnet werden. Denn sonst verpufft je nach Software etwas (oder auch viel) Leistung.
 
@ MusicIsMyLife
Ich vermute mal das irgendwo im Bereich von 28-30 Kernen/Threads Feierabend ist und das Programm entweder nicht mehr ansprechen kann oder der Verwaltungsaufwand die Zusatzleistung frißt. Wie sah den der Verlauf der CPU/Kern Auslastung in der 16/32 Config aus?
 
Wie sah den der Verlauf der CPU/Kern Auslastung in der 16/32 Config aus?

Das habe ich mir nicht angeschaut.

Aus logischen Gesichtspunkten heraus muss es aber ein munteres "umherschubsen" der Threads gegeben haben. Wenn dem nämlich nicht so wäre, könnte ich bei zwei parallelen Aufgaben nicht auf 36 Prozent Mehrleistung gegenüber der ansonsten schnellsten Einstellung 16/16 kommen.

Ich kann heute Abend ja nochmal einen Durchlauf mit 16/32 machen und die Auslastung mit HWINFO mitloggen...
 
GPU Test lief durch auf der Fury X, BS ist aber noch Windows 8.1 und der letzte off. Crimson dafür:



MfG
 
hmmm...interessant.
Vielleicht sollte ich es bei der Nano mal mit einem hochgeschraubten Power Limit versuchen. *kopfkratz
 
Das habe ich mir nicht angeschaut.

Aus logischen Gesichtspunkten heraus muss es aber ein munteres "umherschubsen" der Threads gegeben haben. Wenn dem nämlich nicht so wäre, könnte ich bei zwei parallelen Aufgaben nicht auf 36 Prozent Mehrleistung gegenüber der ansonsten schnellsten Einstellung 16/16 kommen.

Ich kann heute Abend ja nochmal einen Durchlauf mit 16/32 machen und die Auslastung mit HWINFO mitloggen...
Wenn ihr Handbreak nutzt, welche Version hat die h264.exe?
Als gegentest könnte man z.B. den neusten VLC Player nehmen und das selbe Video dort "umwandeln" :)

hmmm...interessant.
Vielleicht sollte ich es bei der Nano mal mit einem hochgeschraubten Power Limit versuchen. *kopfkratz
Oder Untervolten...
 
Wenn ihr Handbreak nutzt, welche Version hat die h264.exe?

Es ist HandBrake 1.07 x64. Wie finde ich heraus, welche Version die x264.exe hat?!


BTW: Ich habe mir nochmal die Auslastung bei einem Job und bei zwei Jobs mit HWINFO angeschaut.

1 Job HandBrake Fast 1080p30: ~68 Prozent durchschnittlich (ca. 10 Minuten)
2 Jobs HandBrake Fast 1080p30: ~96 Prozend durchschnittlich (ca. 15 Minuten)
 
Es ist HandBrake 1.07 x64. Wie finde ich heraus, welche Version die x264.exe hat?!


BTW: Ich habe mir nochmal die Auslastung bei einem Job und bei zwei Jobs mit HWINFO angeschaut.

1 Job HandBrake Fast 1080p30: ~68 Prozent durchschnittlich (ca. 10 Minuten)
2 Jobs HandBrake Fast 1080p30: ~96 Prozend durchschnittlich (ca. 15 Minuten)
Die Frage gab es schon mal, gut möglich dass sie in die Handbreak.exe compiliert wurde.
Also man ist auf den Entwickler angewiesen, da nur er weiß welche Bibliothek Version er genutzt hat.
Der VLC nutzt die open Source Version x264.exe bis Full HD 1080p zu empfehlen.
Alles darüber gleich x265.exe.

Mit dem Mauszeiger über der .exe Datei bleiben, im Tool-Tip erscheint die Version. ;)
 
@MusicIsMyLife
Das entspricht bei einer Instanz ja relativ genau 24 Threads, interessant.

Mit dem aktuellen 17.10.1er Treiber lief der jetzt auch mit der Nano durch, bei der System Bewertung ist die Kiste aber wieder ausgegangen. Ich teste das nochmal mit voll aufgedrehten Graka Lüfter.
 
Die Frage gab es schon mal, gut möglich dass sie in die Handbreak.exe compiliert wurde.
Also man ist auf den Entwickler angewiesen, da nur er weiß welche Bibliothek Version er genutzt hat.
Der VLC nutzt die open Source Version x264.exe bis Full HD 1080p zu empfehlen.
Alles darüber gleich x265.exe.

Mit dem Mauszeiger über der .exe Datei bleiben, im Tool-Tip erscheint die Version. ;)
Würde die Log Datei nicht helfen?
Anhang anzeigen activity_log4816.txt
 
Zurück
Oben Unten