SMT/CMT-Kernzuordnen in Windows-Betriebssystemen

miriquidi schrieb:
Eigentlich sind A und A* die zwei logischen Kernen des ersten physischen Kerns. Meine Bezeichnung ist aber nicht sehr gut, das muss irgendwie besser gehen.
A1 und A2 als logische Kerne des physischen Kerns A?
AM für A Main und AS für A Secondary?


Gibt's hier noch Bulldozer-Nutzer mit Windows 7 oder 8?
Windows 7 mit den meisten aktuellen Windows-Updates, die nicht als fragwürdig gelten, auf meinem FX-8320E@4,2 GHz auf Asus M5A99X Evo R2.0:
http://up.picr.de/28124810mn.jpg
Coreinfo bestätigte das.
Auf einem Kern lief etwas Kleines nebenher.

Win7 ohne Updates sowie Win8.x mit der überwiegenden Anzahl Updates werden folgen.
 
Zuletzt bearbeitet:
Die Screenshots von WindHund zeigen aber eine "geordnete" Core-Reihenfolgen für den FX-8350. Eine Erklärung wäre, das AMD den Käse bei den 81xx-ern erkannt hat und bei Nachfolgern dies korrigierte.
Kannst du bei dir mal Coreinfo durchlaufen lassen? Dann sollte es klar sein.
Scheint aber so zu sein, dass man die Reihenfolge A1, A2, B1, B2, C1, ... weitgehend als Industriestandard ansehen kann.
 
AM für A Main und AS für A Secondary?



Windows 7 mit den meisten aktuellen Windows-Updates, die nicht als fragwürdig gelten, auf meinem FX-8320E@4,2 GHz auf Asus M5A99X Evo R2.0:
http://up.picr.de/28124810mn.jpg
Coreinfo bestätigte das.
Auf einem Kern lief etwas Kleines nebenher.

Win7 ohne Updates sowie Win8.x mit der überwiegenden Anzahl Updates werden folgen.
Auch eine Möglichkeit, ja.
In einem "Modul" können beide beides sein, wenn das richtige Flag gesetzt wurde. ;)

Kannst du bei dir mal Coreinfo durchlaufen lassen? Dann sollte es klar sein.
Scheint aber so zu sein, dass man die Reihenfolge A1, A2, B1, B2, C1, ... weitgehend als Industriestandard ansehen kann.
Wie bei Memory Controller?

Athlon 5350: http://abload.de/img/corepairingatlohn_yts7jsjg.jpg
 
@:miriquidi: Sorry, aber ich saß erst heute wieder vor der AMD-Kiste (war gestern nicht im Büro). PSCheck, Coreinfo und "meins" zeigen folgendes:

All.PNG


Ist für den FX-8120! Bestätigt aber mein vorheriges Geschriebene.
 
@Helle53
Mein Windows 7 Pro ist mit allen aktuellen Updates, es lief aber ein YT Stream im Hintergrund. ;D
Vielen Dank für dein kleines Progrämmchen, das macht schon was her (in der kurzen Zeit) ! *great*

Nutzt dein FX-81xx schon UEFI oder noch Bios?
ISt der AGESA code vom Mainboard aktuell?
 
Sorry wenn ich mich hier einmische und ich muss zugeben ich kann die Grundfrage nur rudimentär beantworten, aber ich stelle die Gegenfrage ob dieses "festnageln" heute überhaupt noch sinnvoll ist?
Dass wir hier über CPU-Kerne und dabei noch logische und reale etc. unterscheiden ist eine rein historisch gewachsene und dem konkreten Design von Hardware geschuldete Tatsache.
Wenn man sich aber Konstrukte wie Xeon Phi, GPUs sowie APUs ansieht und dazu die sich langsam entwickelnden Trends bei der Software, wird diese art von Zuteilung über kurz oder lang obsolet.
Man hat im Prinzip nur noch einen Pool von Computing-Ressourcen und befüttert ihn. Auf ähnliche Weise funktionieren die Thread-Pools in der TPL in .Net zusammen mit async/await. Man verwaltet nicht mehr Threads mit shared state, sondern bricht das Programm in möglichst viele unabhängige Einheiten herunter die man dann vom Scheduler auf die vorhandenen Computing-Ressourcen verteilen lässt. - Am Ende muss man quasi "nur" noch die Verdrahtung übernehmen wann wer auf das Ergebnis von wem anderen warten muss und quasi wieder composite Tasks zusammenbauen.
In Ähnliche Kerben schlagen Frameworks wie Akka in Java (Actors) und auch AMD will ja mit HSA effektiv dahin.
Man hat einen Pool von (mglw. unterschiedlichen) Ressourcen und versucht die gegebene Menge an Aufgaben (Tasks) möglichst rasch abgearbeitet zu bekommen. Dabei ist der Durchsatz wichtiger als die Latenz, d.h. lieber eine Task auf eine sub-optimale Recheneinheit schieben, als dass sie garnicht bearbeitet wird, bis eine der besseren Einehiten endlich frei ist...
Das dürfte das Programmiermodell der Zukunft sein was multithreading angeht und ist wesentlich besser skalierbar (Stichworte massively multicore, Virtualisierung, Cloud etc.) als der alte Ansatz.
Vorteile dabei sind dass man bei Änderung der Anzahl an Recheneinheiten nicht die Programmierung ändern muss, nur der Pool wird größer bzw. kleiner, ebenso spielt es keien Rolle ob echter Kern, SMT kern oder durch irgendwelche Virtualisierungsmechanismen simulierte, logische Computing-Einheit.
Konkret auf aktuelle CPUs und Bestandscode bezogen kommt noch ein Weiterer Punkt hinzu. Ich glaube die Diskussion hatten wir zu Bulldozer-Zeiten hier schonmal und auch wenn das bei Bulldozer sub-optimal gelöst wurde ist das nicht unbedingt ein Naturgesetz.
Wenn ich einen 4-Kerne mit HT habe und 4 Aufgaben zu verarbeiten habe, gibt es mind. 2 Möglichkeiten:
1. Ich nutze pro "echtem" Kern eine Aufgabe, umgehe also SMT und habe gleichmäßig jeden Kern ausgelastet.
2. Ich nutze die ersten beiden Kerne + ihre SMT-Zwillinge.
Nun ist es ein implementierungsdetail wer davon schneller ist. Das hängt nämlich maßgeblich von der SMT-Effizienz, Caching-Geschichten usw. und vor allem, Stromspar- und Turbomodi ab. Im 2. Fall kann der halbe Prozessor schlafen und die beiden arbeitenden physikalischen Kerne höher takten wegen freiem Thermal Budget.
Im zweigen Fall habe ich, dadurch dass kein Kern powergated werden kann, nicht soviel Spielraum.
Wir haben also den klassischen fall von eher wenigern, höher getakteten Transistoren, kontra mehr Transistoren auf niedrigerem Takt.
Und dabei hängt die Performance nun maßgeblich von anderen Faktoren und Details der Maschine ab als von CPU-Kern-Nummern.
(Das wird im Übrigen bei Zen auch noch interessant mal mit Bulldozer und den Intels zu vergeichen..)

Das ist einer der Gründe warum der Trend beim Multithreading eher weg geht von konkreten Kernen und irgendwelchen Zuordnungen hin zu flexiblen Pooling-Artigen Modellen.
Das mag für einzelne Workunits nicht immer zum optimalen Scheduling führen, ist in der Summe, aber am Durchsatzstärksten.
Ein Apache oder IIS schickt euch ja auch keine Fehlermeldung nur weil er gerade keine phyischen CPU-Kerne mehr frei hat um euren Request zu verarbeiten.

Soviel mal als Denkanstoß.
Das Thread-Scheduling im OS ist im Übrigen auch "subject to change" sobald sich die heterogenen Gerätschaften mehr durchsetzen. Da gibts dann bestenfalls noch eine Art Klassifizierung nach "Floating Point, Floating Point Vector, Integer, Integer Vector" o.ä. und Pools aus den selbigen.

Grüße,
Meine Wenigkeit.
 
Zuletzt bearbeitet:
Hat mal jemand einen Vergleich zwischen einem Urschleim Windows 7 und einer Version auf dem aktuellen Stand gemacht um den Einfluss des Shedulers zu untersuchen?
 
@helle53: Danke. Dann scheint das beim Bulldozer V1 ein (bedauerlicher) Einzelfall zu sein.

@Ge0rgy: Bringt es etwas. Ich kann das jetzt nur konkret für meine Applikation beantworten: Ein i7-Sandy Bridge Doppelkern mit aktivem HT rechnet mit 4 Threads ein wenig schneller als mit zwei Threads (die von Windows verteilt werden). Das ist jedoch sehr von der Tagesform von Windows abhängig und können durchaus mal 15 % sein.
Rechne ich mit zwei Threads und nagle sie auf die physischen Kerne fest, bringt das gegenüber 4 Threads nochmal 5,5 % mehr Geschwindigkeit. Bzw. in 3 Monaten eine Zeitersparnis von 4 Tagen. Oder anders betrachtet, bei einem "richtigen" Prozessor wie einem Xeon mit 16 Kernen bzw. 32 Threads mal eben 32 GB weniger RAM-Bedarf. Insofern würde ich sagen, ja es lohnt sich (für mich).
 
Zurück
Oben Unten