Multithreading

[Stevie]

Zitat von Gruber_Hans_12345:

Damit ich es nochmal verstehe das genau das das Problem ist.

Kern 1 lädt die 64Byte wo die variable RandSeed ist in die CacheLine des Kern1
Kern 2 ... Kern 4 machen das gleiche
da nun einer der Kerne die Variable Randseed ändert, muss der Kern nun die 64Byte aus der CacheLine wieder zurück in den RAM speichern - und dabei markiert er bei allen anderen Kernen nun das die 64 Byte die die anderen Kerne in der Cacheline haben ungültig sind und diese müssen die nun erneut laden.

Korrekt, das ganze nennt sich Cache-Kohärenz

Zitat von Gruber_Hans_12345:

1. Das passiert aber nur wenn der Kern auch Daten ändert, ein nur lesen wäre kein Problem gewesen
2. Je mehr Kerne da nun das ausgeführt hätten, desto langsamer würde das werden (die Anzahl der Threads ist nebensächlich, da wenn 10 Threads auf einem Kern laufen es ja auch nur eine CacheLine gibt) nur die echten Kerne die auch eine CacheLine haben zählen hier
3. Wie sicher ist die 64Byte Grenze, und wie kann man das im echten Leben dann sicherstellen das die Variablen sich nicht überschneiden?

1. korrekt, wenn sich nix ändert, muss auch nichts abgeglichen werden
2. richtig
3. "Niemand wird mehr als 64Byte große Cachelines benötigen" - Spaß beiseite, derzeit ist das auf allen gängigen CPUs (zumindest auf denen Delphi läuft) ausschließlich so. Man kann das nun so machen wie das, was Uwe schon erwähnt hat, oder man setzt fest auf 64 Byte und kümmert sich darum, das anzupassen, sollte es mal passieren, dass CPUs rauskommen, bei denen das anders ist.
Hier ist ein Beispiel, wie ich das in Spring gelöst habe, damit sich Daten nicht überschneiden. Beim Allokieren des Speichers muss ich dann noch den Speicher auf 64byte alignen, damit die Daten immer genau in einer Cacheline liegen.

[himitsu]

Statt "blind" 64 Byte, kannst'e auch einfach 8KB oder 64KB nehmen oder Sicherheitshalber 1GB

Da belegt zwar die Variable bissl unnötig viel Speicher, aber was soll's.

Nja 64 bzw 8 KB sind die Größen, wie Windows den RAM verwaltet.
64KB die Mindestgröße beim VirtualAlloc, aber intern dennoch nochmal in 8KB Stückchen verwaltet.
Größer wird wohl keiner "diesesn" Cache bauen.
* erstmal unnötig viel Platz in der CPU und wenn die CacheLine abgeglichen werden muß, müsste dann auch noch viel mehr geladen werden, was dann wiederrum auch viel mehr Zeit verschlampt.

[Gruber_Hans_12345]

Zitat von himitsu:

Wie läuft es mit den Zeiten, wenn SetThreadAffinityMask(GetCurrentThread {oder Self.Handle}, $00000001); als Erstes im Execute, mit originalem Random.

Gilt nur, wenn du maximal 64 Kerne hast, sonst fängt man eventuell auch noch mit Prozessorgruppen an.

Also damit braucht er mit egal wievielen Threads immer annähernd gleich lang (bisschen overhead)
Ist aber doppelt so schnell wie wenn sich die verschiedenen Kerne den Cache ständig ungültig machen.

[himitsu]

Ja, so lange es gleich schnell ist, ist alles OK. (sind ja auch alle Threads an den selben Kern gebunden )
Schlimm wäre es nur, wenn es bei mehr Threads viel langsamer würde. (ein Bissl ist klar, durch die Overhad der Threadverwaltung)