Wer kann auf einer aktuellen 400+x € CPU einen Benchmark durchführen? (Benchmark einer Stundenplan-Software)

[Volker_Dirr]

<Vorwort>
Liebe Moderatoren, falls diese Mail als Werbung aufgefasst werden sollte, dann bitte entwerder den Link oder die ganze Nachricht löschen. (Für Werbung ist dieses Forum aber unpassend und die falsche Zielgruppe. Lehrerforen wären dafür "hilfreich", dort finde ich aber nicht das, was ich wissen möchte.)
</Vorwort>

Hallo,

ich bin co-Autor einer Open Source Stundenplanungssoftware.

Diese Software wird i.d.R. auf PC der unteren Mittelklasse durchgeführt (typische Bürorechner), weil im Büro i.d.R. nicht so leistungsfähige Rechner benötigt werden. Aber ~2 mal pro Jahr wird für ~1 Woche benötigen Schulen extrem viel Leistung für die Stundenplanung.

Ich habe unsere Software so abgeändert, dass ein Benchmark leicht durchgeführt werden kann. (Es ist also kein "syntetischer" Benchmark, sondern eine professionelle Anwendung). Ich habe schon Benchmarkergebnisse von typischen (untere) Mittelklasse-CPUs. Mich interessieren jetzt noch insbesondere Ergebisse der teuren aktuellen Desktopklasse und Server CPU Klasse, die in Bürorechnern üblicherweise nicht sind. Also aktuelle CPUs der Preisklasse 400+x €. Archikektur ist egal. Muss nicht x86 und Windows sein, kann im Grunde auch jede andere Architektur sein. (ARM, .. Linux, MacOS, ...).

Ich schätze den gesamten Zeitaufwand (Download, Benchmark durchführung, Ergebisse mitteilen, ...) auf etwa 15 Minuten.

Ich würde mich freuen, wenn ich zumindest 4 Teilnehmer finden würden (Je einer für aktuelle High End Desktop und Server CPU von Intel und AMD). Bitte nach Möglichkeit keine OC CPU, nur Standartwerte. Grafikkarte ist für den Test unerheblich. RAM kann ruhig OC sein.

Wer hat Interesse mir zu helfen?

Den Benchmark (und bisherige Ergebnisse) gibt es hier (Englisch - aber ich helfe gerne weiter, wenn das ein Problem sein sollte):
https://lalescu.ro/liviu/fet/forum/index.php?topic=5729.0
(Falls die Moderatoren den Link entfernt haben sollten, dann schreibt mir doch eine PN)

Schönes Wochenende
Volker

 

[PrussianHeathen]

Hi,
Ich habe zwar keine aktuellste/server CPU, aber trotzdem viel besser als der 5600G. Beide System nutzten das precompiled Linux Appimage.
Es scheint linear mit den Anzahl der Kerne zu skalieren. SMT bringt nur wenig.

i5 9500 (6C6T) / Debian12
single: 0.39
all thread: 2.02
all core: 2.02

R9 5900X (12C/24T) / mx-linux (Debian12 based)
single: 0.55
all thread: 6.60
all core: 5.70 (went up from 5.58 to 5.64 to 5.70)

 

[Volker_Dirr]

Danke! Ich habe deine Werte in die Tabellen aufgenommen. (Im FET Forum)

Ja, es skaliert nicht perfekt linear, aber aus meiner Sicht bisher recht gut.
Der 5600G reicht mir persönlich. Vorallem weil ich eh keine 3D fähige Grafikkarte benötige.
Warum SMT nicht so gut funktioniert kann ich nicht sagen. Ich wüsste nicht was ich da als Programmierer besser machen könnte.
Am meisten hat mich bisher der Apple M2 Chip überrascht. Keine Ahnung warum das auf dem so gut läuft. Wenn ich übernächte Woche einen Rasperry Pi 5 bekommen sollte, dann probiere ich es damit auch mal aus. Mal gucken ob er es schafft den alten Pentium 4560G zu schlagen.

Wer hat den noch eine Server CPU mit 24+ Kernen? Skaliert es da auch noch zu gut?

 

[PrussianHeathen]

SMT funktioniert schon, aber halt kein Ersatz für einen vollständigigen Kern. 15-20% uplift ist durchschnittlich.

Interressant wäre ein 13900K. Die P-Cores und E-cores würden eine sehr unterschiedliche Zeit benötigen um eine Tabelle zu berechnen.

 

[Volker_Dirr]

Ja, das mit SMT stimmt schon. Ein möglichst geringer Wert bei SMT ist ja im Grunde auch ein Lob an den Programmierer des Threads, da er möglichst Cachefreundlich programmiert hat.

Das bei dem 13900K würde mich auch interessieren und hätte ich vor 2 Wochen auch so vermutet. Mittlerweile aber nicht mehr. Ich tippe, dass alle Threads etwa gleich lange laufen, obwohl das erstmal total unlogisch ist.

Begründung:

Ich habe es auf verschiedenen Systemen und Prozessoren getestet.

Single Thread habe ich folgende Beobachtung gemacht:

Raspberry Pi 4 ARM CPU mit 4 Kernen mit Raspbian -> Das Programm läuft immer auf nur genau einem Kern und bleibt auch dauerhaft auf diesen einen Kern.

AMD Athlon II mit Kubuntu -> Das Programm wechselt die Kerne ab zu sehr gemächlich. Immer unterschiedlih. Mal nach 10 Sekunden. Mal nach 30 Sekunden. Ist vermutlich ein Schutz vor Überhitzung, insofern sinnvoll, andererseits unsinning, weil der Cache neu gefüllt werden muss.

Intel 4460 mit Windows 10 -> Das Programm wechslt die 4 Kerne so schnell durch, dass es aussieht als ob sie nur zu je 25% belegt sind. Es wundert mich, dass das Windows so schnell ändert, weil der Vorteil des Cache so doch nicht voll ausgereizt wird.

Alle CPUs mit SMT oder HT auf Linux und Windows: Wenn man alle Threads nutzt, dann werden die Threas auch fast alle gleichzeitig fertig. Vom Sinn her hätte ich vorher wermutet, das bei beime AMD 5600G 6 Pläne "normal" schnell fertig werden und 6 Pläne (die auf den virtuellen Kernen) etwa 50% mehr zeit benötigen. Dort könnte sich das evtl auch so ergeben, wenn jeder Softwarethread auf seinem Kern bleibt.

ABER:

Apple mit Intel CPU und MacOS 12 auf Intel CPU (2c/4t) -> Das OS verteilt die Last nur auf 2 der Threads. Die beiden anderen Kerne bleiben ungenutzt.

Apple mit M2 ARM CPU (4P und 4E Kerne) -> Die E-Kerne werden dafür nicht genutzt.

Apple mit M2 ARM CPU mit 8 Threas Multicore: -> Es werden alle Kerne genutzt und die Pläne werden witzigerweise fast zeitgleich fertig. Da werden scheinbar die Programmthreads auch auf den Kernen getauscht.

Daher vermute ich, dass es beim Intel mit P und E Kernen ähnlich sein wird. (Also alle Softwarethreads werden etwa gleichzeitig fertig.)

Wer kann das mal prüfen?

 

[PrussianHeathen]

You should try posting your request to level1tech
https://forum.level1techs.com

That community is more towards server and technical challenges oriented. Computerbase is mainly about gaming & consumer tech.

 

[Volker_Dirr]

Thank you for suggesting. Looks like a nice forum, but i can't write hyperlinks in that forum. Maybe because I am new in that forum. And I also can't see how other guys can write me a private message in the forum. So this will deter guys to help me in that forum.

 

[200Puls]

Hi,

Ich habe den Benchmark gerade auf meinen Ryzen 7700x unter Linux (Manjaro) ausgeführt.

Dabei habe ich folgende Werte erhalten:

Single: 0.75
16 Threads: 6.71
8 Threads: 5.52

Die Threads werden auch hier sehr gleichmäßig fertig.

Ich habe noch einen 7800x3d im anderen Rechner. Wenn es auch interessant ist, könnte ich das morgen testen.

Grüße

 

[Volker_Dirr]

Danke!
Der 7800x3d mit dem vielen Cache interessiert mich auch. Würde mich sehr freuen, wenn du das auch testen würdest. Deine aktuellen Werte habe ich gerade bei mir im Forum übernommen. Vor ein paar Tagen habe ich übrigens mit dem Raspberry Pi 5 getestet, falls das einer vergleichen will. Fand ich überraschend schnell.
Ich gehe davon aus, dass du die vorkomplilierte Linux Version genommen hast. Falls du selbst kompiliert hast, gib mal noch bitte den Compiler und die Qt Version an.
Danke!

 

[200Puls]

Ja, genau ich habe das vorkompilierte AppImage genutzt.

Ich werde die anderen Ergbenisse dann morgen posten.

 

[200Puls]

Also Fazit vom 7800x3d Test ist: Takt schlägt Cache.

Single: 0.67
16 Threads: 5.93
8 Threads: 5.25

Ausgeführt auf meiner "Steam Box" mit Chmimera OS Linux.

 

[Müs Lee]

Das ist ein interessantes Optimierungsproblem. Könntest du ein paar Worte zum Algorithmus verlieren?

Hier mein AMD 5950X unter Windows 10. Ich kann auch mal meine Workstation testen. btw, ist das wirklich parallelisiert oder nur n einzelne simultane Threads?

Die Tests mit mehr Threads als physischen Kernen sind hinfällig, die SMT-Einheiten sind nicht für solche Belastungsarten gedacht. Das verlangsamt den ganzen Prozess. Die maximale Anzahl an Threads sollte daher die Anzahl der Kerne nicht übersteigen.

Single core
Timetable no: 1 => Generated in 0 hours, 2 minutes and 20 seconds. Tables per minute: 0.428571 Timetable no: 2 => Generated in 0 hours, 2 minutes and 11 seconds. Tables per minute: 0.442804 Timetable no: 3 => Generated in 0 hours, 2 minutes and 11 seconds. Tables per minute: 0.447761

Multicore
Timetable no: 2 => (Thread 2) Generated in 0 hours, 2 minutes and 58 seconds. Timetable no: 11 => (Thread 11) Generated in 0 hours, 2 minutes and 58 seconds. Timetable no: 14 => (Thread 14) Generated in 0 hours, 2 minutes and 58 seconds. Timetable no: 12 => (Thread 12) Generated in 0 hours, 2 minutes and 58 seconds. Timetable no: 15 => (Thread 15) Generated in 0 hours, 2 minutes and 59 seconds. Timetable no: 8 => (Thread 8) Generated in 0 hours, 2 minutes and 59 seconds. Timetable no: 13 => (Thread 13) Generated in 0 hours, 2 minutes and 59 seconds. Timetable no: 6 => (Thread 6) Generated in 0 hours, 2 minutes and 59 seconds. Timetable no: 9 => (Thread 9) Generated in 0 hours, 3 minutes and 0 seconds. Timetable no: 10 => (Thread 10) Generated in 0 hours, 3 minutes and 2 seconds. Timetable no: 1 => (Thread 1) Generated in 0 hours, 3 minutes and 15 seconds. Timetable no: 5 => (Thread 5) Generated in 0 hours, 3 minutes and 41 seconds. Timetable no: 3 => (Thread 3) Generated in 0 hours, 3 minutes and 52 seconds. Timetable no: 7 => (Thread 7) Generated in 0 hours, 3 minutes and 54 seconds. Timetable no: 4 => (Thread 4) Generated in 0 hours, 3 minutes and 55 seconds. Timetable no: 16 => (Thread 16) Generated in 0 hours, 3 minutes and 56 seconds. Tables per minute: 4.0678 Timetable no: 31 => (Thread 15) Generated in 0 hours, 2 minutes and 56 seconds. Timetable no: 29 => (Thread 13) Generated in 0 hours, 2 minutes and 58 seconds. Timetable no: 28 => (Thread 12) Generated in 0 hours, 2 minutes and 59 seconds. Timetable no: 25 => (Thread 9) Generated in 0 hours, 2 minutes and 59 seconds. Timetable no: 26 => (Thread 10) Generated in 0 hours, 2 minutes and 58 seconds. Timetable no: 30 => (Thread 14) Generated in 0 hours, 3 minutes and 4 seconds. Timetable no: 18 => (Thread 2) Generated in 0 hours, 3 minutes and 6 seconds. Timetable no: 27 => (Thread 11) Generated in 0 hours, 3 minutes and 11 seconds. Timetable no: 17 => (Thread 1) Generated in 0 hours, 2 minutes and 58 seconds. Timetable no: 24 => (Thread 8) Generated in 0 hours, 3 minutes and 28 seconds. Timetable no: 22 => (Thread 6) Generated in 0 hours, 3 minutes and 33 seconds. Timetable no: 23 => (Thread 7) Generated in 0 hours, 2 minutes and 56 seconds. Timetable no: 19 => (Thread 3) Generated in 0 hours, 2 minutes and 59 seconds. Timetable no: 21 => (Thread 5) Generated in 0 hours, 3 minutes and 18 seconds. Timetable no: 20 => (Thread 4) Generated in 0 hours, 3 minutes and 7 seconds. Timetable no: 32 => (Thread 16) Generated in 0 hours, 3 minutes and 17 seconds. Tables per minute: 4.43418


Xeon Gold 5218 auf W10 mit deaktiviertem HT, 1 core:
Timetable no: 1 => Generated in 0 hours, 3 minutes and 38 seconds. Tables per minute: 0.275229 imetable no: 2 => Generated in 0 hours, 3 minutes and 55 seconds. Tables per minute: 0.264901

Multicore, 16 Kerne alle auf einer CPU
Timetable no: 8 => (Thread 8) Generated in 0 hours, 6 minutes and 57 seconds. Timetable no: 9 => (Thread 9) Generated in 0 hours, 7 minutes and 2 seconds. Timetable no: 15 => (Thread 15) Generated in 0 hours, 7 minutes and 13 seconds. Timetable no: 2 => (Thread 2) Generated in 0 hours, 7 minutes and 15 seconds. Timetable no: 5 => (Thread 5) Generated in 0 hours, 7 minutes and 15 seconds. Timetable no: 6 => (Thread 6) Generated in 0 hours, 7 minutes and 16 seconds. Timetable no: 13 => (Thread 13) Generated in 0 hours, 7 minutes and 21 seconds. Timetable no: 14 => (Thread 14) Generated in 0 hours, 7 minutes and 23 seconds. Timetable no: 10 => (Thread 10) Generated in 0 hours, 7 minutes and 33 seconds. Timetable no: 12 => (Thread 12) Generated in 0 hours, 7 minutes and 38 seconds. Timetable no: 11 => (Thread 11) Generated in 0 hours, 8 minutes and 9 seconds. Timetable no: 3 => (Thread 3) Generated in 0 hours, 8 minutes and 13 seconds. Timetable no: 1 => (Thread 1) Generated in 0 hours, 8 minutes and 24 seconds. Timetable no: 4 => (Thread 4) Generated in 0 hours, 8 minutes and 36 seconds. Timetable no: 16 => (Thread 16) Generated in 0 hours, 9 minutes and 52 seconds. Tables per minute: 1.62162

Multicore, alle 32 Kerne beider CPUs
Timetable no: 31 => (Thread 31) Generated in 0 hours, 6 minutes and 47 seconds. Timetable no: 16 => (Thread 16) Generated in 0 hours, 6 minutes and 48 seconds. Timetable no: 13 => (Thread 13) Generated in 0 hours, 6 minutes and 48 seconds. Timetable no: 29 => (Thread 29) Generated in 0 hours, 6 minutes and 50 seconds. Timetable no: 30 => (Thread 30) Generated in 0 hours, 6 minutes and 50 seconds. Timetable no: 15 => (Thread 15) Generated in 0 hours, 6 minutes and 50 seconds. Timetable no: 32 => (Thread 32) Generated in 0 hours, 6 minutes and 50 seconds. Timetable no: 14 => (Thread 14) Generated in 0 hours, 6 minutes and 51 seconds. Timetable no: 23 => (Thread 23) Generated in 0 hours, 6 minutes and 51 seconds. Timetable no: 5 => (Thread 5) Generated in 0 hours, 6 minutes and 53 seconds. Timetable no: 22 => (Thread 22) Generated in 0 hours, 6 minutes and 54 seconds. Timetable no: 24 => (Thread 24) Generated in 0 hours, 6 minutes and 54 seconds. Timetable no: 21 => (Thread 21) Generated in 0 hours, 6 minutes and 55 seconds. Timetable no: 6 => (Thread 6) Generated in 0 hours, 6 minutes and 56 seconds. Timetable no: 7 => (Thread 7) Generated in 0 hours, 6 minutes and 56 seconds. Timetable no: 8 => (Thread 8) Generated in 0 hours, 6 minutes and 58 seconds. Timetable no: 2 => (Thread 2) Generated in 0 hours, 7 minutes and 4 seconds. Timetable no: 1 => (Thread 1) Generated in 0 hours, 7 minutes and 5 seconds. Timetable no: 4 => (Thread 4) Generated in 0 hours, 7 minutes and 6 seconds. Timetable no: 17 => (Thread 17) Generated in 0 hours, 7 minutes and 7 seconds. Timetable no: 20 => (Thread 20) Generated in 0 hours, 7 minutes and 8 seconds. Timetable no: 3 => (Thread 3) Generated in 0 hours, 7 minutes and 8 seconds. Timetable no: 18 => (Thread 18) Generated in 0 hours, 7 minutes and 9 seconds. Timetable no: 19 => (Thread 19) Generated in 0 hours, 7 minutes and 9 seconds. Timetable no: 12 => (Thread 12) Generated in 0 hours, 7 minutes and 19 seconds. Timetable no: 10 => (Thread 10) Generated in 0 hours, 7 minutes and 19 seconds. Timetable no: 27 => (Thread 27) Generated in 0 hours, 7 minutes and 19 seconds. Timetable no: 25 => (Thread 25) Generated in 0 hours, 7 minutes and 20 seconds. Timetable no: 28 => (Thread 28) Generated in 0 hours, 7 minutes and 20 seconds. Timetable no: 26 => (Thread 26) Generated in 0 hours, 7 minutes and 21 seconds. Timetable no: 11 => (Thread 11) Generated in 0 hours, 7 minutes and 23 seconds. Timetable no: 9 => (Thread 9) Generated in 0 hours, 7 minutes and 24 seconds. Tables per minute: 4.68293

 

[HITCHER_I]

Habe es auch mal probiert, mit R9-3900x, und 6.12 von Source kompiliert auf Fedora 38.
Etwas stimmt nicht, wenn ich 12 Stundenpläne erstelle, mit 24 Threads, dann sollen die Threads, die fertig sind, lieber aufhören, und nicht anfangen einen nächsten Stundenplan, der eh nicht gebraucht wird, zu erstellen.
Das selbe auch, wenn man mit 24 Threads, 24 Stundenpläne erstellen will.

Das Ergebnis schaut bei mir etwas anders aus, lässt sich aber zurückrechnen auf 6,72 Stundenpläne / Minute.

Liegt vielleicht an neuerem Qt6.6.

Edit:
Also diese Version ist nicht auf Benchmark-Modus eingestellt, aber hat trotzdem 24 (verschiedene) Ergebnisse produziert.

 

[Volker_Dirr]

Hui.. Danke für die Antworten!!! Ich lese sie mal einzeln und beantworte einzeln.

@200Puls: Mir war gar nicht klar, dass der 7800 langsamer getaktet ist als der 7700. Habe ich gerade erst gelesen. Danke für die Info. Ich hatte den Cache schon mal theoretisch mit Cachegrind abgeklopft. Ist natürlich abhängig vom Datensatz. Bei den Testdaten profitiert man ab 1MB pro Thread vom Cache nur noch im Bereich von unter 1%. Das war aber "nur" die Theorie, da Cachegrind eine alte Cachetechnik simuliert. Auswirkung auf neue/bessere Caches kannte ich daher noch nicht. Auf jeden Fall eine wichtige Bestätigung der bisherigen Theorie.

Ergänzung (16. November 2023)

@Müss Lee:

Könntest du ein paar Worte zum Algorithmus verlieren?

siehe: https://lalescu.ro/liviu/fet/doc/en/generation-algorithm-description.html
und https://lalescu.ro/liviu/fet/doc/en/generation-algorithm-details.html

Ist das wirklich parallelisiert oder nur n einzelne simultane Threads?

Nein, die Arbeiten nicht gemeinsam an einer Rechnung. Die Arbeiten in echt an verschiednenen Lösungen. Gemeinsam an einer Rechnung geht leider nicht. Da gibt es nichts, was man effektiv parallel machen könnte. Haben wir versucht, aber es wird dadurch leider nur langsamer statt schneller.
In der Praxis braucht man nur eine Lösung. Man lässt also im echten Leben auf allen Kernen rechnen und sobald einer die Lösung gefunden hat kann man aufhören. Ist ist also im Grunde so wie beim Bitcoinschürfen. Wer es genauer wissen will, der kann ja mal hier gucken, da erkläre ich das genauer:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Für den Benchmark lasse ich sie alle genau die gleiche Aufgabe lösen. Theoretisch müssten sie also exact gleich schnell fertig werden. Das macht in der Praxis natürlich keinen Sinn; daher auch die Warnung die Benchmarkversion nicht in der Praxis zu nutzen. Die dienst nur dazu CPUs gut und schnell vergelichen zu können, nicht um damit in der Praxis zu arbeiten. Technisch ist das so gelöst, dass beim Benchmark der Zufallsgererator mit den gleichen Startwerten (Seed) ausgeführt wird. In der Praxis startet man immer mit anderen Werten.

Die Tests mit mehr Threads als physischen Kernen sind hinfällig, die SMT-Einheiten sind nicht für solche Belastungsarten gedacht. Das verlangsamt den ganzen Prozess. Die maximale Anzahl an Threads sollte daher die Anzahl der Kerne nicht übersteigen.

Nein, das stimmt so nicht. Da man im schnitt mehr Lösungen erhält. Wie gesagt, sie arbeiten nicht an einer gemeinsamen Aufgabe, sondern an getrennten Aufgaben und man braucht nur eine Lösung. Guck dir mal das von mir gerade verlinkte Video an, dann verstehst du es besser. SMT macht hier sehr wohl Sinn.

Ergänzung (16. November 2023)

@Müss Lee:
Die SingleCore Wert vom 5950X verstehe ich. Ok.

Bei der Tabelle darunter bin ich mir unsicher, du hast es 2 mal mit 16 Threads laufen lassen?
Das könnte hinkommen. Es streut am Anfang etwas, wenn der Scheduler dem letzten Thread am meisten Zeit gegeben hat. Der letzte Thread berechnet immer den Durchschnitt. Daher sollte man den Test auch 3 oder mehr mal durchlaufen lassen, bis das Ergebnis "stablier" wird.
Lass mal ruhig mit allen Threads laufen. Es ist ganz normal, dass die Einzelzeiten dann langsamer werden. Es kommt im Grunde nur auf die "Tables per Minute" an. Das ist das wichtige. Mit SMT war es bei mir bisher so um 20% schneller. Ich tippe daher, dass du den auf einen Wert von etwa 5 kommen dürftest.

Die Werte von dem Gold 5218 sind noch nicht stabil. Wenn du mit 16 Kernen einen Wert von 1.6 Plänen pro Minute hast, dann wirst du mit 32 Kernen nie auf 4.6 Pläne pro Minute kommen.

Lass den Test mal bitte mindestens 3 mal laufen. Ursache ist wie gesagt, dass der Scheduler Zeiten nicht ganz gleichmäßig verteilt, dass kann ich aber nicht beeinflussen.

Ergänzung (16. November 2023)

@Müss Lee:
Die SingleCore Wert vom 5950X verstehe ich. Ok.

Bei der Tabelle darunter bin ich mir unsicher, du hast es 2 mal mit 16 Threads laufen lassen?
Das könnte hinkommen. Es streut am Anfang etwas, wenn der Scheduler dem letzten Thread am meisten Zeit gegeben hat. Der letzte Thread berechnet immer den Durchschnitt. Daher sollte man den Test auch 3 oder mehr mal durchlaufen lassen, bis das Ergebnis "stablier" wird.
Lass mal ruhig mit allen Threads laufen. Es ist ganz normal, dass die Einzelzeiten dann langsamer werden. Es kommt im Grunde nur auf die "Tables per Minute" an. Das ist das wichtige. Mit SMT war es bei mir bisher so um 20% schneller. Ich tippe daher, dass du den auf einen Wert von etwa 5 kommen dürftest.

Die Werte von dem Gold 5218 sind noch nicht stabil. Wenn du mit 16 Kernen einen Wert von 1.6 Plänen pro Minute hast, dann wirst du mit 32 Kernen nie auf 4.6 Pläne pro Minute kommen.

Lass den Test mal bitte mindestens 3 mal laufen. Ursache ist wie gesagt, dass der Scheduler Zeiten nicht ganz gleichmäßig verteilt, dass kann ich aber nicht beeinflussen.

Ergänzung (16. November 2023)

@HITCHER_I und alle anderen:
Danke. Habt ihr den Test alle so durchgeführt? Bitte nicht die Anzahl der Pläne reduzieren. Stattdessen einfach den Test nach einiger Zeit abbrechen. Grund: Wenn ihr die Anzahl der Pläne auf die Anzahl der Threads reduziert, dann ist der Test "unrealistisch", sobald der erste Thread seine Lösung gefunden hat. Denn dann ist der Core untätig und nutzt keinen geteilten Chache. Im echten Leben würden die Kerne aber immer laufen und Cache benötigen. Das Laufen der Kerne würde auch mehr Wärme produzieren und und ggf. den Takt senken.

@Alle: Vielen Danke für das Testen! Ich hatte schon gedacht, dass hier keiner mehr Antwortet und plötzlich 3 so aktive Mitglieder. Danke! Aber bitte lässt den Test mindestens 3 mal durchlaufen und macht es so, dass ihr den letzten Wert der "Timetables per minute" angebt, wie lange er für einen Plan löst ist im Grunde uninteressant. Wäre nur für den Single-Core interessant, aber damit das mit dem Multicore vergleichbar ist, habe ich die Zeit zum Lösen in die "gleiche Einheit" umgerechnet. (Ist ja mathematisch einfach nur der Kehrwert)

Danke für eure Antworten.

Ergänzung (16. November 2023)

Also diese Version ist nicht auf Benchmark-Modus eingestellt, aber hat trotzdem 24 (verschiedene) Ergebnisse produziert.

ahh... Jetzt sehe ich das erst, Nee, so kann man das absolut nicht gebrauchen. Da es absolut vom Zufall abhängt. Wenn du das nochmal machst kann es auf 10 Minuten Dauern und wenn du es nochmal machst nur eine Minute. Das ist wie beim Bitcoin Minen. Daher habe ich extra die Benchmark Version gemacht, da es dann immer gleich ist und vergleichbar wird.

@200Puls: Danke. Deine Werte habe ich übertragen. Sie sehen zumindest plausibel aus und ich gehe davon aus, dass du den Bechmark "richtig" durchgeführt hast.

 

[HITCHER_I]

Bitte nicht die Anzahl der Pläne reduzieren. Stattdessen einfach den Test nach einiger Zeit abbrechen. Grund: Wenn ihr die Anzahl der Pläne auf die Anzahl der Threads reduziert, dann ist der Test "unrealistisch", sobald der erste Thread seine Lösung gefunden hat. Denn dann ist der Core untätig und nutzt keinen geteilten Chache.

Nein, also unter Fedora-Linux 38 habe ich mit "cpupower monitor" im Terminal die CPU-Auslastung kontrolliert, die Threads, welche dann eigentlich fertig sind, rechnen einfach an einer neuen Lösung weiter, die wahrscheinlich gar nie benötigt wird, bis alle gesuchten Lösungen (zB. 24) gefunden wurden, dann brechen sie unfertig ab.

 

[Volker_Dirr]

hmm... Gucke mir gleich noch mal an. Du sprichst jetzt von der "richtigen" FET version?. Da macht das auch absolut Sinn. Ist auch richtig so. Ich muss noch mal in den Benchmark reingucken. Wenn ich es dort genau so gelassen hatte, dann wäre das gut, dann macht es keiner aus versehen falsch. Danke für das prüfen der Auslastung!

 

[HITCHER_I]

Ja, ist die offizielle Version, selbst kompiliert, kann man die auf Benchmark-Modus umschalten?

Archiv: fet-6.12.0.tar.bz2

 

[Volker_Dirr]

Nein, kannst du leider nicht umschalten. War uns zu gefährlich das in einer Version zu machen. Da kann man sonst sowohl als Programmierer als auch als Anwender zu schnell einen Fehler machen und dann muss ich das wieder im Support ausbaden.

 

[Müs Lee]

Aha, das Video klärt das Ganze etwas auf. Durchaus eine sehr interessante Aufgabe. Ich hantiere eher mit gut parallelisierbaren Problemen à la Strömungs- und Struktursimulationen, da ist SMT manchmal hinderlich. Hierbei mehr Threads zu starten als Kerne zur Verfügung stehen verlangsamt die Berechnung definitiv, daher war mir das Verhalten unbekannt. Am Ende deines Videos lief das Programm anscheinend knappe 16 Tage - ist das eine übliche Laufzeit für reelle Problemstellungen oder nur ein Extrem zur Darstellung des Verhaltens?

Ja, ich habe den 5950X zweimal mit 16 Threads laufen lassen. Ich bin gerade nicht an meinem PC, kann das aber eventuell am Wochenende mit mehr Läufen und mit 32 Threads wiederholen. Hier noch drei Läufe mit allen 32 Threads auf den Xeons:

Tables per minute: 4.92308
Tables per minute: 4.8731
Tables per minute: 5.17056

Es folgt gleich noch einer mit 16 Threads. Aufgrund anderer Programme habe ich KMP_AFFINITY = FALSE in den Umbegungsvariablen definieren müssen, eventuell hat das auch einen Einfluss auf die Ergebnisse, wenn nur ein Prozessor läuft.

4 Läufe mit 16 Threads auf einem Prozessor:

Tables per minute: 1.62437
Tables per minute: 1.65946
Tables per minute: 1.73494
Tables per minute: 1.94529

 

[HITCHER_I]

Habe die Benchmark-Version 6.9.6 Source jetzt doch noch mal extra kompiliert auf Fedora 38,
genauso wie zuvor die offiziell veröffentlichte Version.
gcc 13.2.1, qt 6.6.0

Also für R9-3900x unter Fedora 38. Nicht übertaktet. Scheinbar erreicht der R9-3900x momentan mit dem aktuellen Kernel gar nicht die max. Turbo-Taktfrequenz bei 1T von 4,6 GHz, sondern eher nur um die 4,5 GHz.

1T = 0,46 T/min
12T = 4,86 T/min
24T = 6,23 T/min