pybecrasher - Shader Compile Benchmark und Stresstest

[aufkrawall]

Ein Vibe-Projekt von mir:
https://github.com/aufkrawall/pybecrasher

Mit Steady Load dem Benchmark-Modus lässt sich (annäherungsweise) die Shader Compile-Performance in Spielen vergleichen.
5700X schafft 18,9/s:
https://s1.directupload.eu/images/251122/v7xk6i7l.jpg (https://www.directupload.eu)


13700K ist ca. bei 36-37.

Edit: Neuste Version:
https://github.com/aufkrawall/pybecrasher/tags

[Darkman.X]

Malware erfolgreich installiert. Benötigst du noch etwas.....mein Passswort vom PW-Manager? ;)


Ich gehe mal davon aus, dass es nichts schlimmes ist. Wahrscheinlich weil es als EXE kompiliert ist.

https://www.virustotal.com/gui/file/984002de5004ef9ab2d2048ad60f76a7b10f5e911067a8cb98c08bf4530ddd2f

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=94673&stc=1&d=1763837954

================================================

EDIT: Der Durchgang war noch mit v2.0.

i9-14900K - normales Performance-Profil

CPU laut HWInfo dauerhaft im 253 W-Limit (und im 100 ℃-Limit mit Noctua NH-D15S-Luftkühler).

Threads: 32 | Mode: steady | Priority: ABOVE_NORMAL
Pre-generating 200 shaders ... Done.
Time: 0:02:03 | Rate: 47.1/s | 60s Avg: 46.9/s | Act: 32 | Err: 0 | STEADY MAX [IO: OFF] [INT: OK]


https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=94674&stc=1&d=1763838033


Frisst ganz schön viel RAM :eek:

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=94675&stc=1&d=1763838058

[aufkrawall]

Oha, jemand hat sich in den Thread verirrt. :eek:
Ja, gegen die False Positives mit den Packages von pyinstaller kann ich nichts machen. Außer weiter nur als Script anzubieten, aber das schreckt halt auch wieder viele ab.

Hatte übrigens einige Updates vorgenommen, mittlerweile ist 5 aktuell:
https://github.com/aufkrawall/pybecrasher/tags

Die generierten Shader sind damit etwas anders und kompilieren schneller. Damit macht der 5700X 25,7/s im neuen Benchmark-Modus:
https://s1.directupload.eu/images/251122/temp/22cwvdho.jpg (https://www.directupload.eu/file/d/9111/22cwvdho_jpg.htm)

13700k 5,3GHz ist bei 54/s.

Versionsnummer im Programm wär sicherlich gut gewesen, aber wahrscheinlich war das jetzt eh die finale Version.
Der reine Benchmark-Modus der aktuellen Version frisst btw. keinen RAM. Für die anderen Modi ist das Absicht, siehe KI-Geschwafel:
RAM Anvil: Allocates ~70% of total physical RAM and periodically writes to random pages. This tests the Memory Controller (IMC) under load and checks for thermal instability in DIMMs.

[Darkman.X]

Und nochmal mit v5.0 im Benchmark-Modus:

i9-14900K - normales Performance-Profil

CPU laut HWInfo dauerhaft im 253 W-Limit.

=== UE5 Stress: FINAL EDITION (Universal V9) ===
Threads: 32 (Compilers) + 0 (Noise) | Mode: benchmark | Priority: BELOW_NORMAL
Pre-generating 200 shaders ... Done.
Time: 0:03:03 | Rate: 65.3/s | Best 60s: 65.4/s | Act: 32 | Err: 0 | STEADY MAX

RAM-Verbrauch im Benchmark-Modus auch ok.

[aufkrawall]

Danke!
Da machen sich die E-Cores schon bezahlt. Da können in manchem UE5-Spiel aus 25s Warten/Geruckel 10s werden bei Vergleich meine vs. deine CPU.

[Daredevil]

M3 Ultra 28c (20P-8E) via Crossover in einer Win10 Bottle
https://s1.directupload.eu/images/251122/zcqyrfm3.png

[aufkrawall]

Da wird die Performance ziemlich arg leiden, da es schon unter x86 Wine extrem ausgebremst ist. Ist nicht verwunderlich, da der Compiler unentwegt Prozesse spawnt, was performancekritisch am Kernel hängt und über Wine ziemlichen Overhead haben dürfte.

Musste konzeptionell noch einige grundlegende Dinge ändern: Durch das zufallsgenerierte Set an Shadern konnte die Performance im Benchmark-Modus zwischen Runs abweichen. Jetzt wird dafür für bessere Vergleichbarkeit immer ein identisches Set generiert. Für die anderen Modi werden dafür nun in Echtzeit unentwegt Shader zufällig generiert, um garantierte Variabilität in jedem Run zu haben. Da das allerdings ohne Weiteres nicht ohne Disk-Storage geht, sind die generierten Shader-Dateien für weniger intensive Schreibzugriffe nun wesentlich kleiner, was den Durchsatz an kompilierten Shadern erhöht. Daher sind mit der aktuellsten Version die Werte nun wesentlich höher.
5700X: 111/s
https://s1.directupload.eu/images/251123/temp/2yye2qf3.jpg (https://www.directupload.eu/file/d/9112/2yye2qf3_jpg.htm)

https://github.com/aufkrawall/pybecrasher/releases/tag/13.0

[BeetleatWar1977]

5900X mit 200W PBO

Select Mode [1]: 3
=== PyBeCrasher v13.0 ===
Mode: benchmark | Load: 24 (Compilers) + 0 (Noise) | Priority: BELOW_NORMAL
Pre-generating 200 static benchmark shaders... Done.
Time: 0:01:12 | Rate: 123.2/s | Best 60s: 123.2/s | Act: 24 (24C+0N) | Err: 0 | STEADY MAX

[aufkrawall]

Da scheint etwas zu klemmen? AV oder Indexer? 13700K macht mit der aktuellen Version 205/s. Also sollten mit dem 5900X eigentlich auch locker 40% gegenüber dem 5700X rumkommen. Der zieht 112W 4,55GHz.

[BeetleatWar1977]

Da scheint etwas zu klemmen? AV oder Indexer? 13700K macht mit der aktuellen Version 205/s. Also sollten mit dem 5900X eigentlich auch locker 40% gegenüber dem 5700X rumkommen. Der zieht 112W 4,55GHz.
Bin bei ähnlicher Taktrate, und er knallt die 200W wirklich durch......

[misterh]

285K + 8800CL40 (48GB)
https://s1.directupload.eu/images/user/251123/pfx74fpr.png

[RoNsOn Xs]

265K @stock
=== PyBeCrasher v13.0 ===
Mode: benchmark | Load: 20 (Compilers) + 0 (Noise) | Priority: BELOW_NORMAL
Pre-generating 200 static benchmark shaders... Done.
Time: 0:03:31 | Rate: 152.2/s | Best 60s: 155.7/s | Act: 20 (20C+0N) | Err: 0 | STEADY MAX

Beim 2ten Versuch hat er ewig durch gerudert, habs dann geschlossen.
War die meiste Zeit zwischen 75-80% Auslastung, in Spitze auch mal 90%. Nie mehr als 160w.

[Tesseract]

9800X3D

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=94688&d=1763924736

[aufkrawall]

War die meiste Zeit zwischen 75-80% Auslastung, in Spitze auch mal 90%. Nie mehr als 160w.
Die vom Taskmanager angezeigte Gesamtauslastung ist leider nur noch Quatsch:
https://s1.directupload.eu/images/251123/temp/vjqmq3nf.jpg (https://www.directupload.eu/file/d/9112/vjqmq3nf_jpg.htm)

Immerhin ist ein 9800X3D trotz gleicher Kernanzahl schon wirklich merkbar schneller als der olle Zen 3.
Auch interessant, wie misterhs 285K abgeht.

[misterh]

M3 MAX mit Win11 Pro (ARM64) @ 16C + 40GB

Parallels Desktop
https://s1.directupload.eu/images/user/251123/y82chmw7.png

VMware Fusion Pro 25H2
https://s1.directupload.eu/images/user/251123/f3j737cu.png

Qualcomm Snapdragon X Elite ( X1E78100 ) @ 12C + 32GB
https://s1.directupload.eu/images/user/251124/cgoma2z6.png

[RoNsOn Xs]

Die vom Taskmanager angezeigte Gesamtauslastung ist leider nur noch Quatsch:
https://s1.directupload.eu/images/251123/temp/vjqmq3nf.jpg (https://www.directupload.eu/file/d/9112/vjqmq3nf_jpg.htm)

Genau das meine ich ja. Ich nutze ArgusMonitor. Der Taskmanager zeigt komplett 100%. Warum? Weil Firewall, oder Antimalware Service Executable von Windows selbst sehr viel CPU währrend dieses Benches fressen. Vllt nicht auf Windows10 optimiert? Egal, klappt hier halt nicht wirklich gut.

[Raff]

Auch interessant, wie misterhs 285K abgeht.

Nachvollziehbar, wenn alle Kerne verwendet werden. Das passiert zum Beispiel bei der Unreal Engine 5 auch (daher fliegen da auch diverse Raptoren ab). Ich sehe gerade, genau das willst du auch simulieren – Erfolg! :up:

Daher sind mit der aktuellsten Version die Werte nun wesentlich höher.

Bestätige. PyBeCrasher v13 mit 5950X mit 16C/16T (kein SMT):

139,1/s @ 90 Watt UV-Eco-Mode
71,0/s @ forcierten 1,72 GHz

MfG
Raff

[aufkrawall]

Genau das meine ich ja. Ich nutze ArgusMonitor. Der Taskmanager zeigt komplett 100%. Warum? Weil Firewall, oder Antimalware Service Executable von Windows selbst sehr viel CPU währrend dieses Benches fressen. Vllt nicht auf Windows10 optimiert? Egal, klappt hier halt nicht wirklich gut.
Habe durch Wechsel auf dxcompiler.dll innerhalb von Python.exe doch noch geschafft, die I/O-Abhängigkeit komplett zu eliminieren und die live zufallsgenerierten Shader direkt und ausschließlich im RAM zu erzeugen (bzw. hatte der Benchmark-Modus trotz der nur initial generierten Shader dieselbe I/O-Abhängigkeit in Form unentwegten Einlesens der Shader). Damit sollte das Problem weg sein. Könnte auch Wine helfen, da keine Compiler-Prozesse mehr spawnen (falls das nicht auch mit an I/O lag). Läuft jetzt auch ohne Adminrechte mit hoch/über normal-Prozesspriorität.
Ich werd es allerdings erst noch auf einem Raptor Lake-System testen. Ohne den I/O-Overhead schien erst aufzufallen, wie der Compiler mit den Synthie-Shadern durch Abkürzungen zu schnell war. Da musste Gemini einige Male probieren, um den zu zügeln und durch normal lange Compile-Zeiten keine Auslastungs-Bubbles mehr entstehen zu lassen. :freak:
Die Vergleichbarkeit zu den alten Versionen ist damit natürlich hinfällig...

Edit: Jo, Wine ist jetzt schneller als Windows. wtf...

[Darkman.X]

Version 13.0:

== PyBeCrasher v13.0 ===
Mode: benchmark | Load: 32 (Compilers) + 0 (Noise) | Priority: BELOW_NORMAL
Pre-generating 200 static benchmark shaders ... Done.
Time: 0:02:04 | Rate: 272.4/s | Best 60s: 272.6/s | Act: 32 (32C+ON) | Err: 0 | STEADY MAX

===========================================

Dein PY-Script scheint nicht mehr Leerzeichen in Verzeichnisnamen klar zu kommen, da wurden wohl ein paar "-Zeichen vergessen.

Wegen 2-3 Github-Projekten habe ich Python 3.13.9 bei mir installiert (bin kein PY-Entwickler, nur Consumer). Wenn ich die PY-Datei mit einem Doppelklick oder mit "py ue5_shader_stress.py" innerhalb von CMD ausführe, dann sehe ich das Menü. Aber sobald ich 1, 2 oder 3 drücke, kommt folgende Fehlermeldung:
Der Befehl "C:\Program" ist entweder falsch geschrieben oder konnte nicht gefunden werden.

Das gleiche Problem, wenn ich die ZIP-Datei in ein Verzeichnis mit Leerzeichen extrahiere und dann die EXE-Datei ausführe. Wenn der Pfad beispielsweise "E:\Downloads\pybecrasher v13.0" lautet, dann kommt bei der EXE-Datei nach drücken einer Ziffer die Fehlermeldung:
Der Befehl "E:\Downloads\pybecrasher" ist entweder falsch geschrieben oder konnte nicht gefunden werden.

[misterh]

Update

285K + 8400CL38
https://s1.directupload.eu/images/user/251125/2o48gzhf.png

[aufkrawall]

Hab's jetzt als C++ Einzel-Prozess ohne Python am Laufen, inkls. Wine. 13700K ist jetzt etwas mehr als doppelt so schnell wie mein 5700X, offenbar nicht mehr durch I/O ausgebremst. Hab auch noch die.. Anregungen aus dem KI-Thread so weit berücksichtigt, wie das in meiner Dummi-Macht steht.
Vor dem Release passe ich aber erst noch den variablen Workload-Stresstest etwas an.

[Sonyfreak]

i9-7980XE@200W; 4x8GB DDR4-2400 :tongue:

=== PyBeCrasher v13.0 ===
Mode: benchmark | Load: 36 (Compilers) + 0 (Noise) | Priority: BELOW_NORMAL
Pre-generating 200 static benchmark shaders... Done.
Time: 0:04:39 | Rate: 131.3/s | Best 60s: 133.2/s | Act: 36 (36C+0N) | Err: 0 | STEADY MAX

mfg.

Sonyfreak

[aufkrawall]

Bandbreitenlimit? Mit mehr als doppelt so vielen Kernen nur 20% vor dem 5700X ist ja doch etwas mager. :freak:

Idiotische Wine-Probleme haben mich leider etwas ausgebremst. Dafür sollte die nächste Version aber auch wenigstens nach so etwas wie einem Programm aussehen:
https://s1.directupload.eu/images/251126/ei8u7lxs.png (https://www.directupload.eu)


Auch mal interessant:
can we influence windows 11 scheduler not to favor e-cores over p-cores, without increasing process/thread priority?

Yes, we can. To prevent the Windows 11 scheduler from parking E-cores or deprioritizing the process without changing the process/thread priority class (which affects all scheduling decisions, not just core selection), we can use Processor Power Management (PPM) Quality of Service (QoS) hints.

Specifically, we can set the PROCESS_POWER_THROTTLING_STATE to ignore power management, or more effectively for your "stress test" goal, we can use the EcoQoS API (Efficiency Mode) in reverse—effectively telling the scheduler "this is high-performance work" even at normal priority.

However, the most direct way to force utilization across all cores (P and E) equally is to ensuring the threads are marked as "Important" or by setting the Thread Power Throttling state to PROCESS_POWER_THROTTLING_IGNORE_TIMER_RESOLUTION.

Better yet, for a stress test application on hybrid architectures (Alder Lake/Raptor Lake), we should explicitly set the SetThreadInformation with ThreadPowerThrottling to disable throttling. This tells the OS: "Do not treat this thread as background work; schedule it aggressively."

The Fix: Disable Power Throttling
I will add a helper function DisablePowerThrottling() and call it at the start of every worker thread (CompilerThread, DecompressThread, etc.). This signals the Windows 11 scheduler to treat these threads as performance-critical, preventing them from being dumped exclusively onto E-cores or parked when the window is in the background.


Cool, dass das mit "echten" Programmen immer noch mal klemmen kann. Ähnlich wie manchmal auch noch vernünftige DPI-Skalierung...

[RoNsOn Xs]

Wo ist die neue Version? Bin ready :D

[aufkrawall]

Will erst noch ein anderes System testen. Sollte morgen mit hoher Wahrscheinlichkeit klappen.

[aufkrawall]

dxcompiler.dll crashte immer zufällig in Wine, und ich konnte Gemini nach Auswertung des Crash-Dumps nicht von seiner felsenfesten Überzeugung abbringen, dass das kein Bug im Microsoft-Code ist. :freak:
Ist jetzt rausgeflogen und durch eine komplett simulierte Kompilier-Last direkt im Code ersetzt. Heizt auch besser, inkls. AVX2/512-Optimierungen und ohne Performance-Verlust in Wine. Test mit weiterer CPU steht noch aus. Arm64 Build sollte auch machbar sein.

[RoNsOn Xs]

Spanisch. Ja wann denn? ^^

[Sonyfreak]

i9-7980XE@200W; 4x8GB DDR4-2400 19/19/19/43 :tongue:

=== PyBeCrasher v13.0 ===
Mode: benchmark | Load: 36 (Compilers) + 0 (Noise) | Priority: BELOW_NORMAL
Pre-generating 200 static benchmark shaders... Done.
Time: 0:04:39 | Rate: 131.3/s | Best 60s: 133.2/s | Act: 36 (36C+0N) | Err: 0 | STEADY MAX
Bandbreitenlimit? Mit mehr als doppelt so vielen Kernen nur 20% vor dem 5700X ist ja doch etwas mager. :freak:
Es dürfte auch am Speicher liegen:

i9-7980XE@200W; 4x8GB DDR4-2800 17/17/17/35

=== PyBeCrasher v13.0 ===
Mode: benchmark | Load: 36 (Compilers) + 0 (Noise) | Priority: BELOW_NORMAL
Pre-generating 200 static benchmark shaders... Done.
Time: 0:04:53 | Rate: 140.2/s | Best 60s: 141.9/s | Act: 36 (36C+0N) | Err: 0 | STEADY MAX

Mehr macht der Speicher leider nicht mit.

mfg.

Sonyfreak

[Raff]

Mit welchem Takt laufen die Trümmerkerne denn?

@krawallo: Dein Tool wird bald in einem Artikel zu sehen sein! Geil oder geil? =)

MfG
Raff

[ChaosTM]

Mit welchem Takt laufen die Trümmerkerne denn?

@krawallo: Dein Tool wird bald in einem Artikel zu sehen sein! Geil oder geil? =)

MfG
Raff


krawallo.. jeez

der Man lebt auf dem Gottuser Olymp - nenne ihn bei seinem richtigen Namen! ;)

[aufkrawall]

@krawallo: Dein Tool wird bald in einem Artikel zu sehen sein! Geil oder geil? =)

Das freut mich zu hören. Ich gehe auch auch weiterhin davon aus, dass die Aussagekraft gegeben ist. Allerdings ist es schon defacto deprecated, Nachfolger ist komplett neu geschrieben und sollte alle Limitierungen lösen. Release ich dann, wenn auf anderer CPU noch gegengetestet und mit entsprechender Skalierung funktioniert.

[Raff]

Wir betatesten hier gerne weiter. Das GUI, so einfach das auch aussehen wird, macht sich dann auf nem Shot besser als die Kommandozeile. :)

MfG
Raff

[Yuko]

Die grafische Oberfläche sieht spannend aus. Wann kommt denn das Update dazu? Dann mache ich mit meiner Möhre auch mal mit =)

[misterh]

sry aufkrawall für OT.

@ Raff

Auch mein Benchmark hat in PCGH Zeitschrift geschafft, dafür auch nochmal danke ( @ PCGH ).

Dennoch hab ich noch keine Meinung von dir dazu gelesen irgendwo. Evtl. übersehen?

[-=Popeye=-]

13900k @ PL1 125W/PL2 253W // 2x16GB DDR4-4200 16/16/16/32

https://i.ibb.co/Xfzp0GyG/pybecrasher-PL1-125-PL2-253.png

13900k @ PL1 253W/PL2 253W // 2x16GB DDR4-4200 16/16/16/32

https://i.ibb.co/cSBLDTwH/pybecrasher-PL1-253-PL2-253.png

[aufkrawall]

Cool, DDR4 regelt.

Ich hab mit dem neuen Ansatz jetzt schlechtere Skalierung auf Raptor Lake vs. Zen 3 festgestellt, mit entsprechend niedrigerem Stromverbrauch. Gut, dass ich es erst getestet hab. Da sind noch einige zusätzliche Optimierungen fällig. Aber kein ETA, neuer Fortnite-Chapter steht vor der Tür. :D

[aufkrawall]

Hier geht's weiter:
https://www.forum-3dcenter.org/vbulletin/showthread.php?t=622976

13700K skaliert jetzt optimal. Zen 4 und 5 könnten durch AVX-512 sogar noch etwas mehr bevorteilt sein.