Mini HPC

Guten Morgen,

ich habe da mal eine Frage: Ich brauche mehr Rechenleistung für diverse Anwendungen. Die Software die ich benutze ist in der Lage einen Mehrkernprozessor auszulasten. Das Problem ist, dass bei mehr als vier Kernen der Leistungszuwachs abnimmt. Das heißt, wenn ich mehr Leistung brauche, bringt es mir nichts einen Prozessor zu kaufen, der der mehr als vier Kerne hat (jedenfalls nicht für die eigentliche Anwendung). Ich könnte also nur die vorhandenen Kerne schneller bekommen, indem ich sie übertakte - was für mich jedoch keine Lösung darstellt.

Gibt es eine Möglichkeit, die Rechenleistung zweier CPU-Kerne oder gar zweier CPUs gebündelt einem Betriebsystem zur Verfügung zu stellen?

Mir ist bewusst, dass es sowas in Renderfarmen usw. git. Ist sowas auch im Kleinen möglich mit Hilfe von Windows / Windows Server?

Wenn du 4 Kerne maximal auslasten möchtest, dann geht das über die Architektur (Rechenleistung pro Mhz) und/oder über eine möglichst hohen Takt pro Kern innerhalb dieser vier Kerne.

2 CPUs bringen in der von dir skizzierten Situation nichts, da sie ja (wahrscheinlich) mehr als 4 Kerne bereit stellen und das auch nicht gewünscht ist.

Wie ist denn dein aktuelles Setup und um welche Software bzw. welches Anwendungsszenario geht es denn?

Das ist ja eben der Gedanke! CPU1 und CPU2 werden von irgendeinem System verwaltet, dass die Rechenleistung einer Art virtuellen Maschine bereitstellt. In dieser virtuellen Maschine läuft dann meine Software. Die Software kriegt die entsprechende anzahl Kerne des virtuellen Prozessors zugewiesen und das verwaltende System verteil die Aufgabe dann auf die tatsächlich vorhandenen Kerne von CPU1 und CPU2

ML89 schrieb:

Gibt es eine Möglichkeit, die Rechenleistung zweier CPU-Kerne oder gar zweier CPUs gebündelt einem Betriebsystem zur Verfügung zu stellen?

Mir ist bewusst, dass es sowas in Renderfarmen usw. git. Ist sowas auch im Kleinen möglich mit Hilfe von Windows / Windows Server?

Zum Vergrößern anklicken....

Nein, ist nicht möglich. In Renderfarmen gibt es sowas auch nicht. Der Knackpunkt ist hier die Software, die ausreichend viele Threads öffnet, was gerade im Falle von Renderjobs noch vergleichsweise trivial ist. Das ist keine Frage des Betriebssystems, sondern eine Frage deiner Applikation.

Was du dir vorstellst wäre zwar denkbar, erfordert aber ebenso weitere Logik in Software, weil du ganz unten im Stack immer die Hardware hast der du bzw. deine Applikation nativ nicht genug Threads übergeben kannst.
Wenn du zwei physikalische Kerne zu einem logischen verbinden willst, dann brauchst du einen Software Layer, der die Jobs zwischen Kern 1 und Kern 2 verteilt. Das macht keine Hardware und kein Betriebssystem out of the Box.

Was du dir vorstellst wäre so eine Art Thread Multiplexer, der die vier Threads deiner Applikation nimmt und z.b. je einen auf vier Threads aufteilt, sodass der Workload am Ende in 16 Threads bearbeitet wird. Sowas existiert aber nicht, da sowas auch für jede Applikation individuell wäre. mal ganz abgesehen von konzeptionellen Problemen wie das zerlegen und wieder zusammensetzen von Workload.

Ich kenne grad keine Lösung, um CPU-Kerne in Reihe zu schalten, aber würde es dir nicht reichen, das DAN-Case zu nehmen, ein gutes MiniITX Board, viel RAM und dazu entweder i7-4790K oder i7-6700K, dazu HT abschalten und voilà, haste 4x 4Ghz Basistakt. Fertig ist der Mini-HPC, mit dem dein Programm umgehen könnte.

Alternativ gibt es SMP Seesaw, aber das würde dir nur was bei 2 CPUs bringen, so könnte dein programm eine der CPUs komplett für sich beanspruchen.

Nö, viel zu lahm .

Alternativ unterstützt die Software CUDA unter RHEL, aber ich will mich nicht mit Linux auseinandersetzen. Da reichen 5 Minuten und putze den Dreck wieder von der Platte.

@ML89
Dann lebe mit der Beschränkung, wenn du zwar eine Lösung vor dir hast, aber Linux für dich dreck ist. Kann ich gar nicht verstehen, warum bloß alle großen HPC auf Linux laufen....

DunklerRabe schrieb:

[...]

Zum Vergrößern anklicken....

Okay.

Oder reverse Engineering im Zweifelsfall und dann Quellcode richtig auf SMP optimieren (so das es halt JEDEN verfügbaren Kern nutzt). Neu kompilieren und mindestens nen 10kerner mit Hyperfred laufen lassen.

ML89 schrieb:

Das Problem ist, dass bei mehr als vier Kernen der Leistungszuwachs abnimmt.

Zum Vergrößern anklicken....

Ich würde gerne das Problem verstehen, tu' ich aber nicht.

Dass die Leistung nicht proportional wächst, wenn theoretisch beliebig mehrkernfähige Software statt vier auf 8 oder zwölf oder 16 Kernen läuft, ist logisch. Zum einen ist es ein Softwareproblem, da der Verwaltungsaufwand mit der Zahl der Kerne zunimmt, zum anderen ein Hardwareproblem, da es technisch nicht möglich ist, allen Kernen einer Vielkern-CPU das gleiche thermische Budget zur Verfügung zu stellen, wie bei Nutzung eines einzigen Kernes.

Das Softwareproblem würde bestehen bleiben bzw. sich noch vergrößern, wenn die Kerne nicht mehr auf einer CPU sondern auf mehreren belastet werden. Einzig das Hardwareproblem ließe sich angehen: die TDP von vier oder acht Pentiums ist halt ungleich höher als etwa die 135 Watt TDP eines Xeon E5-2690, abgesehen davon sind die Pentiums bedeutend günstiger.

Aber was heißt das konkret, dass der Leistungszuwachs abnimmt? Wenn ein Zuwachs abnimmt ist er zwar nicht mehr so groß aber immer noch vorhanden. Wie muss ich mir das vorstellen: die Verdoppelung der Threads von vier auf acht bringt schon etwas, aber z.B. nur 21% Zuwachs und wenn Du noch einmal von acht auf 16 Threads verdoppelst kommen weitere 9% dazu? Reden wir von solchen Größenordnungen oder gänzlich anderen?

Und vielleicht noch ein Hinweis, um welche Art Software es sich handelt und was das zeitkritisch an ihr ist.

Ja genau. Irgendwann macht es eben aus finanzieller Sicht (für mich, muhaha) keinen Sinn mehr in endlos viele Kerne zu investieren, da die Parallisierung abnimmt. Das sieht ungefähr so aus wie bei den GPUs mit SLI/Crossfire.

Was natürlich stimmt ist die Frage, ob man die Aufgaben übehaupt parallelisieren kann, bzw "in Reihe schalten"