Die Aussage versteh ich nicht...
Wie misst man die maximale Leistung einer CPU, wenn nicht am Beispiel von Programmen (sprich Programmcode?)
Es geht um praktische Läufe mit Programmcode und nicht um theoretische Betrachtungen. Die Grundproblematik ist, daß in normalen Betrieb das OS preemptives Multitasking unterstützt. D.h. sobald mehrere Programme ausgeführt werden müssen (ist bei modernen OS eigentlich immer der Fall), werden diese wechselseitig angehalten, die Caches geflusht, das neue Programm geladen, Daten gelesen und dann begingt das Spielchen von vorne. Das trifft auch bei den modernen MultiCore CPUs zu. Wenn ein solcher Kontextwechsel stattfindet, kann es sein, daß der Thread nicht mehr auf demselben Core wieder ausgeführt wird. Spätestens jetzt werden auch die readonly Cacheinhalte verworfen. Zum Teil verlagern die OS die Threads absichtlich, um die Cores kühler zu halten und so mehr vom Turbomode zu profitieren. Das ist für den Normalbetrieb das sinnvolle Vorgehen.
Allerdings trifft dies nicht zu, wenn man HPC macht. Mit HPC meine ich, daß der Computer in der Hauptsache nur noch ein Programm ausführt, und dies mehrere Stunden oder Tage. Dann ist es besser, wenn man die Threads fest an Cores bindet. Dann unterbricht das OS die Ausführung nur noch, wenn es ein anderes Programm ausführen muß. Es gibt somit sehr viel weniger Kontextwechsel. Weniger Kontextwechsel bedeutet weniger häufigeres Verwerfen der Cacheinhalte -> höhere Ausführungsgeschwindigkeit.
Hier gibt's ein PP Slide zum Thema:
http://www.rz.rwth-aachen.de/global/show_document.asp?id=aaaaaaaaaabsykd
Es sind am Ende Graphen enthalten, die die Problematik visualisieren.
Und in der Praxis ist es doch eher so, das es äußerst selten der Fall ist, das ein Programmcode so "gut" geschrieben ist, das dieser die CPU vollständig auslasten kann und folglich SMT nichts, aber auch gar nichts mehr bringt.
Wenn zwei Threads pro Core laufen, konkurrieren sie um die Caches. Wenn man halbwegs brauchbaren Code hat, dann profitiert dieser vom Cache. Cache Invalidierungen reduzieren somit die Ausführungsgeschwindigkeit. SMT hilft die CPU besser auszulasten, wenn es ohnehin ständig zu Kontextwechsel kommt, weil hier Pipelineinhalte weniger häufig verworfen werden müssen. Allerdings setzt das voraus, daß man überhaupt ständig Kontextwechsel hat. HPC bedeutet eben, daß man kaum Kontextwechsel braucht, somit ist SMT nicht sinnvoll.
Ich lehne mich sogar aus dem Fenster und sage, das es zum Teil sogar so ist, das man unabhängig von SMT sogar mit mehr wie einem Thread auf einem Core, eine höhere Gesamtleistung erzielen kann als im Vergleich zu einem einzigen Thread pro Core.
Das ist nachweislich nicht der Fall. Es gibt dazu eine ganze Reihe wissenschaftlicher Artikel. Ich muß mal nachschauen, welche davon frei erhältlich sind.
Für den oben aufgeführten Vergleich ist das aber alles ziemlich uninteressant. Denn für gewöhnlich hat der User auf die Programme selbst keinen Einflus,
Auch das ist inkorrekt. Zumindest unter Linux kann man Prozesse Coremasken zuweisen (taskset), das geht auch mit jedem x-beliebigen kommerziellen Programm. Bei einem Thread wird dieser somit an einen Core gebunden. Bei Programmen mit OpenMP (oder einen vergleichenbaren MT Lösung) kann man von außen Umgebungsvariablen setzen, die die Threads fest an bestimmte Cores binden. Es ist nahezu bei jedem kommerziellen HPC Programm möglich genau dies zu tun. Weil die Softwareautoren vorher nicht wissen können, wie die Topologie des jeweiligen Systems aussieht.
Dahingehend hat AMD ja grundsätzlich keinen Nachteil.
Die meisten Algorithmen skalieren nicht linear mit der Zahl der Cores, daher ist es schlechter für die gleiche Leistung mehr Cores zu benötigen.
---------- Post added at 09:27 ---------- Previous post was at 09:18 ----------
Deine Erklärung ist ja gut, aber eigentlich überflüssig, weil es in jeder Review Benches von normaler Software gibt wo die i7 mit SMT mehr leisten,
Thread Pinning (Thread Affinity) bringt ca. 20-30% Mehrleistung auf einem System mit einem NUMA Knoten. Hat das System mehrere NUMA-Knoten, sind die Ergebnisse zum Teil dramatisch unterschiedlich, da es hier mehr Möglichkeiten gibt, die Performance zu versauen, wenn die Threads auf dem falschen Core ausgeführt werden.
Du meinst vermutlich geflusht.
Dieses was wäre wenn, ist doch immer Banane. Bulldozer ist genauso auf den Markt gekommen, wie er auf den Markt gekommen ist - mit seinen Fehlern, Schwächen und , ganz böse, ohne für ihn optimierte Software. So ist das nun mal, der Drops ist gelutscht. Wichtig ist was 2012 und 2013 wird, die Börse ist zu letzt nicht mehr sonderlich von AMDs goldener Zukunft überzeugt gewesen. Kriegt man bis einschließlich Steamroller nicht die Kurve, haben die viel Zeit über hätte, wäre, wenn nachzudenken...