Intel nimmt Anleihen bei der "Bulldozer"-Archtitektur?
Nein, denn der ganze untere Teil ab "Anleihen aus der Vergangenheit und Gegenwart" ist Quatsch, da es bei dem was Intel hier patentiert, um etwas ganz anderes geht als bei den AVX-512 Einheiten von Zen4 und Zen5 oder den Modulen der Bulldozerarchitektur. Die AVX-512 Einheiten der Zen4 waren nur 256 Bit breit und mussten 512 Bit breite Vektoren daher in zwei Schritten verarbeiten, aber bleibt wie bei Zen5 alles auf einem Kern und dessen Hardware. Würde es nach Intels neuem Patent funktionieren, würden die AVX-512 Einheiten von zwei Kernen verwendet um eine 512 Bit breite Berechnung in einem Schritt auszuführen und so etwas gab es bisher nie. Auch nicht bei Bulldozer, da war ja ein Modul im Grunde zwei Kerne die sich aber die FPU teilen müssen, entsprechend war die Integer Performance zwar gut, aber die FP Performance mies.
Dies hat eben auch nichts damit zu tun, dass ein Software Thread zeitgleich auf den Einheiten von mehr als einem Kern ausgeführt wird. Dies Konzept nennt sich bei Intel Rentable Units (RUs) und soll auf die Zeit vom Jim Keller bei Intel und sein Royal Core Konzept zurückgehen. Da war das Konzept direkt in Hardware umgesetzt und wenn z.B. ein Kerne mehr Intergereinheiten auslasten könnte als er hat, aber sein Nachbar seine Intergereinheiten nicht alle ausgelastet hat, dann könnte der andere Kern dort Berechnungen ausführen. Praktisch hätte damit jeder Kerne im Extremfalls, nämlich wenn der Nachbarkern Idle ist, doppelt so viele Verarbeitungseinheiten zur Verfügung als er selbst besitzt. Keine Ahnung wie genau sich dies nun mit der jetzt patentierten Lösung verhält, bei der ja nun auch Software eine Rolle spielt und es der Zeichnung nach ja nicht mehr nur feste Paare benachbarter Kerne sind, die zusammenarbeiten.
Dazu kommt: nicht alle Dinge lassen sich parallelisieren.
Das stimmt allerdings, denn immer wenn ein Ergebnis von dem Ergebnis der vorherigen Berechnung abhängt, muss man diese Ergebnis eben erst abwarten. Für Berechnungen wo ein wenig Parallelität vorhanden ist, machen die Kerne dies heute selbst, dafür nutzen sie ihre Out-of-Order Einheiten und die Tatsache, dass sie eben mehrere Ausführungen ihrer Integer und FP Einheiten haben und dort auch parallel Befehle ausführen können, die im Programmcode nacheinander ausgeführt werden. Das ist ja der Sinn einer Out-of-Order Architektur, die soll ja eben die Befehle so umordnen, dass die Befehlsfolge schneller abgearbeitet wird als würde man die Befehle nacheinander so abarbeiten wie sie kommen und da man dadurch mehrere Befehle auch in einem Kerne parallel abarbeiten kann, haben Kerne heute viele Integer-, FP-, Load- und Store Einheiten, sonst würde ja je eine Verarbeitungseinheit pro Kern reichen, wenn alle Befehle wie früher nur streng nacheinander abgearbeitet würden.
Deshalb lohnt es sich auch bei heutigen CPUs überhaupt nicht ganz kleine Aufgaben im Programmcode zu parallelisieren, denn dies macht der Kern schon selbst und der Overhead einen Thread zu starten und dann die Ergebnisse zu synchronisieren ist viel zu hoch. Einen SW Thread muss also schon genug unabhängig von den anderen Threads berechnen, damit es sich lohnt ihn zu starten und je mehr es ist, umso effizienter lassen sich alle Kerne auslasten. So wie bei Cinebench, wo eben jeder Thread einem Teilstück des Bildes rendert, wie man ja schön sehen kann und die Kerne daher fast die ganze Zeit unabhängig voneinander nur an ihren Daten arbeiten.
MD5 ist ein Beispiel wo man beides sehen kann. Um die MD5 z.B. eines RAM Bereiches zu berechnen, kann man nichts parallel machen, da hier das Ergebnis immer vom vorherigen Ergebnis und dem nächsten Byte abhängt. Aber es gibt die Passwortknacker die ganz viele MD5 Summen für Wörter im Wörterbuch oder zufällige Zeichenkombinationen parallel errechnen, wobei aber eben die Berechnung für jede einzelne Zeichenfolge nicht parallelisierbar ist. Der MD5 Algorithmus ist also nicht parallelisierbar, aber Anwendungen die eben mehrere MD5 Hashes erreichen, sind es sehr wohl.
