PCGH_Carsten
Ex-Redakteur
AW: Große Bitte an Besitzer einer Ryzen-CPU | und alle anderen, speziell 2011-3
Hm, ok. Ich dachte du hättest dir den Code möglicherweise mal angesehen.
Aber ja: Sobald SMT viel hilft, laufen Ausführungseinheiten leer. Das muss aber nicht unbedingt was mit schlecht optimiertem Code zu tun haben - manche Algorithmen sind einfach speicherlastig sodass häufig auf Daten aus RAM oder Cache gewartet werden muss. Prominentes Beispiel - und dort ist es volle Absicht, um es ASIC resistent zu machen - ist der Dagger-Hashimoto der Ethereum Blockchain. Aber natürlich gibt es auch welche, bei denen das auf mangelnde Optimierung schließen lässt.
Das muss dabei gar nichtmal die Schuld der Programmierer sein - der Benchmark könnte immerhin schon 11 Jahre alt sein, wenn ich nach dem Änderungsdatum des Daten-Files gehe (und da sage noch einer, wir nutzen veraltete Spiele... ) [edit: Februar 2007: CASE Lab Research: Euler3d Benchmark]. Vektoreinheiten wie AVX gab es damals noch nicht. Im Grafikbereich etwa hat sich für bestimmte Funktionen auch irgendwann der mathematische anstelle des texturbasierten (LUT) durchgesetzt allein weil die Rechenleistung massiv schneller gewachsen ist als die Speichertransferrate.
Was mich zu der Frage bringt: Müsste der Algorithmus prinzipiell nicht super auf GPUs oder ASICS laufen, wenn er tatsächlich stark von der Rechenleistung abhängig ist? Schonmal ausprobiert?
Ich kenne mich selbst mit CFD nicht gut aus, kann hier also nur ableiten.
Das hängt größtenteils vom Solver-Typ ab. Die zu lösenden Grundgleichungen sind natürlich immer ähnlich. Aber nach der Übersetzung in eine brauchbare mathematische Formulierung und schließlich in einen numerischen Algorithmus gibt es einfach zu viele Möglichkeiten um das festmachen zu können.
Mittlerweile stehe ich diesem Benchmark recht kritisch gegenüber, aus 2 Gründen:
1) Die Ergebnisse die man auf verschiedenen Seiten zu den gleichen CPUs findet unterscheiden sich qualitativ und quantitativ, und das teils erheblich.
2) Ich bin mittlerweile überzeugt davon dass der Benchmark nicht ganz repräsentativ für einen typischen CFD-Workload ist. Müsste ich auf Basis meiner eigenen Programmiererfahrung raten würde ich sagen es liegt unter Anderem daran dass der Code noch nicht ausreichend optimiert ist. Dass Hyperthreading hier so viel hilft ist ein Anzeichen dafür, ebenso dass man mit einer größeren Anzahl Threads als die CPU zur Verfügung stellt noch höhere Benchmark-Scores erreichen kann.
Hm, ok. Ich dachte du hättest dir den Code möglicherweise mal angesehen.
Aber ja: Sobald SMT viel hilft, laufen Ausführungseinheiten leer. Das muss aber nicht unbedingt was mit schlecht optimiertem Code zu tun haben - manche Algorithmen sind einfach speicherlastig sodass häufig auf Daten aus RAM oder Cache gewartet werden muss. Prominentes Beispiel - und dort ist es volle Absicht, um es ASIC resistent zu machen - ist der Dagger-Hashimoto der Ethereum Blockchain. Aber natürlich gibt es auch welche, bei denen das auf mangelnde Optimierung schließen lässt.
Das muss dabei gar nichtmal die Schuld der Programmierer sein - der Benchmark könnte immerhin schon 11 Jahre alt sein, wenn ich nach dem Änderungsdatum des Daten-Files gehe (und da sage noch einer, wir nutzen veraltete Spiele... ) [edit: Februar 2007: CASE Lab Research: Euler3d Benchmark]. Vektoreinheiten wie AVX gab es damals noch nicht. Im Grafikbereich etwa hat sich für bestimmte Funktionen auch irgendwann der mathematische anstelle des texturbasierten (LUT) durchgesetzt allein weil die Rechenleistung massiv schneller gewachsen ist als die Speichertransferrate.
Was mich zu der Frage bringt: Müsste der Algorithmus prinzipiell nicht super auf GPUs oder ASICS laufen, wenn er tatsächlich stark von der Rechenleistung abhängig ist? Schonmal ausprobiert?
Ich kenne mich selbst mit CFD nicht gut aus, kann hier also nur ableiten.
Zuletzt bearbeitet: