Multithreading, volatile, Cache usw.
-
1.) I$ braucht nicht geshared sein.
2.) D$ soll nicht geshared sein, da mehrere Prozesse unterschiedliche Daten verarbeiten. Warum soll mein Videoplayer den gleichen Cache benutzen, wie mein Videospiel, dass nebenbei laeuft? Also konsistente Caches bringen nur in wenigen Faellen etwas, z.B. Supercomputing. Dafuer gibts dann von Intel Larrabee/Knights Corner (ka. wie es final heissen wird). Wobei geben zuviel gesagt ist, die Entwicklung dauert offiziell schon 5 Jahre, inoffiziell ...Wenn alle Prozessoren auf dem selben Cache arbeiten, dann sind die Daten doch automatisch konsistent.
Die Schwierigkeiten ergeben sich bei der Realisierung. Multithreading ist normalerweise so gestrikt, dass eben nicht auf den gleichen Daten gearbeitet wird.
Klar wird der Cache immer dicker, wenn er mehr Leitungen hat, aber das ist doch kein prinzipielles Problem.
Doch!
Warum sollte der gleichzeitige parallele Zugriff auf einen gemeinsamen Cache so problematisch sein? Also rein vom Prinzip her stelle ich mir dir Frage.
Weil es immernoch zu Race Conditions kommen kann.
-
PhilippHToner schrieb:
Is des jetzt so schwer? Google mal: Datenkonsistenz. Wie willst du eine Datenkonsistenz in einem gemeinsamen Cache realisieren ...
// edit Zusatz: bei gleicher Geschwindigkeit!Ach komm, darum geht es doch gar nicht.
Wenn alle Prozessoren auf dem selben Cache arbeiten, dann sind die Daten doch automatisch konsistent. Also sehen wir mal von den Registerwerten ab.
Die Schwierigkeit ergibt sich doch eben erst bei mehreren getrennten Caches.
Und was ich eben noch nicht verstehe:
Warum sollte der gleichzeitige parallele Zugriff auf einen gemeinsamen Cache so problematisch sein? Also rein vom Prinzip her stelle ich mir dir Frage.Klar wird der Cache immer dicker, wenn er mehr Leitungen hat, aber das ist doch kein prinzipielles Problem.
-
Noch was:
wie es gelöst wurde ist es genau richtig. Ein Problem zu parallelisieren setzt Nebenläufigkeit voraus. Dieses "Nebenläufige" landet im L1 Cache und da es Nebenläufig ist, besteht kein Bedarf an Shared Cache. Danach kommt der Synchronisationspunkt.
Alle Threads fangen gleichzeitig an, aber eine blockiert kurzzeitig beim Syncen alle (oder nur einen Teil), und nach und nach kommen die Threads durch und sind soweit verschoben, dass sich "wahrscheinlich" nie wieder welche blockieren. DIe Frage ist also, wann sollte denn dann ein SharedCache sinnvoll sein?
-
knivil schrieb:
1.) I$ braucht nicht geshared sein.
2.) D$ soll nicht geshared sein, da mehrere Prozesse unterschiedliche Daten verarbeiten. Warum soll mein Videoplayer den gleichen Cache benutzen, wie mein Videospiel, dass nebenbei laeuft? Also konsistente Caches bringen nur in wenigen Faellen etwas, z.B. Supercomputing. Dafuer gibts dann von Intel Larrabee/Knights Corner (ka. wie es final heissen wird).Wenn alle Prozessoren auf dem selben Cache arbeiten, dann sind die Daten doch automatisch konsistent.
Die Schwierigkeiten ergeben sich bei der Realisierung. Multithreading ist normalerweise so gestrikt, dass eben nicht auf den gleichen Daten gearbeitet wird.
Und das würde ja auch nichts machen.
Die Konsistenz diesem gemeinsamen Cache kommt ja "for free", die kostet nix.
-
Die Konsistenz diesem gemeinsamen Cache kommt ja "for free", die kostet nix.
Wenn Prozess A den Cache von Prozess B immer kaputt macht als auch anders herum, dann arbeitet Programm A und B langsamer, als wenn sie einen getrennten Cache benutzen. Nix ist for free!
-
jenz schrieb:
PhilippHToner schrieb:
Is des jetzt so schwer? Google mal: Datenkonsistenz. Wie willst du eine Datenkonsistenz in einem gemeinsamen Cache realisieren ...
// edit Zusatz: bei gleicher Geschwindigkeit!Ach komm, darum geht es doch gar nicht.
Wenn alle Prozessoren auf dem selben Cache arbeiten, dann sind die Daten doch automatisch konsistent. Also sehen wir mal von den Registerwerten ab.
Nein!!!!!! Der Prozessor addiert keine Werte aus dem Cache direkt zusammen und schreibt sie wieder in den Cache so ein Blödsinn! Er braucht alles erst einmal in einem Register um damit was machen zu können!!!!! Programmier Mal Assembler! Google, was eine ALU macht!
-
okay, wenn man mehr als nur seinen xten teil nutzen können soll, dann wird die verwaltung aufwendiger. dann sollte man den cache doch besser in gleiche teile aufteilen auf denen immer nur ein prozessor die hoheit hat.
Aehm also eigentlich wie getrennte Caches! Auch deine anderen Argumente sind eher ... undurchdacht.
"Destructive interference—the converse of overlapping working sets"
haben wir ja schon gelöstJa, mit getrennten Caches.
wieviel Zukunft unsere Multicore CPUs haben. Nämlich 0! Mit zunehmender Frequenz steigt die Hitzeentwicklung
Die Anzahl der Kerne hat nichts mit der Frequenz zu tun.
-
PhilippHToner schrieb:
jenz schrieb:
PhilippHToner schrieb:
Is des jetzt so schwer? Google mal: Datenkonsistenz. Wie willst du eine Datenkonsistenz in einem gemeinsamen Cache realisieren ...
// edit Zusatz: bei gleicher Geschwindigkeit!Ach komm, darum geht es doch gar nicht.
Wenn alle Prozessoren auf dem selben Cache arbeiten, dann sind die Daten doch automatisch konsistent. Also sehen wir mal von den Registerwerten ab.
Nein!!!!!! Der Prozessor addiert keine Werte aus dem Cache direkt zusammen und schreibt sie wieder in den Cache so ein Blödsinn! Er braucht alles erst einmal in einem Register um damit was machen zu können!!!!! Programmier Mal Assembler! Google, was eine ALU macht!
Das ist mir klar und steht hier überhaupt nicht zu debatte.
-
knivil schrieb:
wieviel Zukunft unsere Multicore CPUs haben. Nämlich 0! Mit zunehmender Frequenz steigt die Hitzeentwicklung
Die Anzahl der Kerne hat nichts mit der Frequenz zu tun.
Ich meinte damit, dass wir weg von Multicore, hin zu niedriggetakteten Manycore kommen werden, blöd bin ich auch nicht! Weniger Hitzeentwicklung bedeutet auch weniger Strom.
-
knivil schrieb:
Die Konsistenz diesem gemeinsamen Cache kommt ja "for free", die kostet nix.
Wenn Prozess A den Cache von Prozess B immer kaputt macht als auch anders herum, dann arbeitet Programm A und B langsamer, als wenn sie einen getrennten Cache benutzen. Nix ist for free!
Ja, das ist auch klar.
Aber das hat doch auch nichts mit dem Problem hier zu tun.
-
jenz schrieb:
PhilippHToner schrieb:
jenz schrieb:
PhilippHToner schrieb:
Is des jetzt so schwer? Google mal: Datenkonsistenz. Wie willst du eine Datenkonsistenz in einem gemeinsamen Cache realisieren ...
// edit Zusatz: bei gleicher Geschwindigkeit!Ach komm, darum geht es doch gar nicht.
Wenn alle Prozessoren auf dem selben Cache arbeiten, dann sind die Daten doch automatisch konsistent. Also sehen wir mal von den Registerwerten ab.
Nein!!!!!! Der Prozessor addiert keine Werte aus dem Cache direkt zusammen und schreibt sie wieder in den Cache so ein Blödsinn! Er braucht alles erst einmal in einem Register um damit was machen zu können!!!!! Programmier Mal Assembler! Google, was eine ALU macht!
Das ist mir klar und steht hier überhaupt nicht zu debatte.
Ja doch, du kommst mit deinem tollen SharedCache her aber dass der ganze Müll auch in Registern ist, ist dir Wurst? Willst du jetzt mit SharedRegistern arbeiten
-
Ja, das ist auch klar. Aber das hat doch auch nichts mit dem Problem hier zu tun.
Doch. der wie willst du entscheiden, wie viel Cache ein Prozess benutzen darf?
-
knivil schrieb:
okay, wenn man mehr als nur seinen xten teil nutzen können soll, dann wird die verwaltung aufwendiger. dann sollte man den cache doch besser in gleiche teile aufteilen auf denen immer nur ein prozessor die hoheit hat.
Aehm also eigentlich wie getrennte Caches! Auch deine anderen Argumente sind eher ... undurchdacht.
"Destructive interference—the converse of overlapping working sets"
haben wir ja schon gelöstJa, mit getrennten Caches.
wieviel Zukunft unsere Multicore CPUs haben. Nämlich 0! Mit zunehmender Frequenz steigt die Hitzeentwicklung
Die Anzahl der Kerne hat nichts mit der Frequenz zu tun.
Bei getrennten Caches brauche ich doch ein cache kohärenz protokoll, also ein verfahren dass über die caches hinweg die gleichen daten in die caches schreibt.
wenn jeder prozessor aber gleich in allen bzw in dem einen großen cache lesen kann, dann braucht man das eben nicht.
-
knivil schrieb:
Ja, das ist auch klar. Aber das hat doch auch nichts mit dem Problem hier zu tun.
Doch. der wie willst du entscheiden, wie viel Cache ein Prozess benutzen darf?
Wieso denn eigentlich Prozess?
Wir reden doch über Prozessoren und ihre L1 Caches.Aber das ist auch interessant.
Kann man einem Prozess einen bestimmten Teil vom Cache zuordnen?
-
jenz schrieb:
Bei getrennten Caches brauche ich doch ein cache kohärenz protokoll, also ein verfahren dass über die caches hinweg die gleichen daten in die caches schreibt.
wenn jeder prozessor aber gleich in allen bzw in dem einen großen cache lesen kann, dann braucht man das eben nicht.
Des gilt nur für L3, weil shared! und ist im Hintergrund! Und das "Protokoll" ist schneller als ein RAM Zugriff!
-
Du brauchst immer ein Protokoll wenn mehrere Einheiten auf einen gemeinsamen Speicher zugreifen. http://de.wikipedia.org/wiki/Arbiter . Das gleiche Problem tritt ja auch auf, wenn mehrere DMA-Engines auf den RAM zugreifen.
Wieso denn eigentlich Prozess?
Einem Prozessor, der nichts macht, ist es egal ob er einen getrennten Cache benutzt oder nicht.
-
jenz schrieb:
knivil schrieb:
Ja, das ist auch klar. Aber das hat doch auch nichts mit dem Problem hier zu tun.
Doch. der wie willst du entscheiden, wie viel Cache ein Prozess benutzen darf?
Wieso denn eigentlich Prozess?
Wir reden doch über Prozessoren und ihre L1 Caches.Aber das ist auch interessant.
Kann man einem Prozess einen bestimmten Teil vom Cache zuordnen?Er meint Prozessor, aber das lässt sich über Heuristiken lösen. Hitrates, oder letzte Zugriffszeit
-
jenz schrieb:
Und was ich eben noch nicht verstehe:
Warum sollte der gleichzeitige parallele Zugriff auf einen gemeinsamen Cache so problematisch sein? Also rein vom Prinzip her stelle ich mir dir Frage.Klar wird der Cache immer dicker, wenn er mehr Leitungen hat, aber das ist doch kein prinzipielles Problem.
Für nur lesen wäre das vielleicht noch denkbar (aber eher nicht, siehe weiter unten).
Aber wie willst du in so einen Cache schreiben?
Jeder "gute" Cache ist "multi-way associative", d.h. jede RAM Adresse kann an verschiedenen Stellen im Cache liegen. D.h. es gibt hier gewisse Registerbänke die "Verwaltungsdaten" enthalten. Es wird z.B. auch vermerkt wann eine Cache-Line das letzte mal verwendet wurde, damit entschieden werden kann welche Lines rausfliegen wenn neue Daten dazukommen.
Um also einen neuen Wert in den Cache zu tun muss man erstmal folgendes machen:
* In allen Cache-Lines die in Frage kommen nachgucken wie alt sie sind
* Die älteste ermitteln
* Diese Cache-Line ggf. in den Speicher (oder darunterliegenden Cache) zurückschreiben
* Die neuen Daten in die Cache-Line stecken
* Den "letzer Zugriff" Wert aktualisierenWie soll das funktionieren wenn das 2 Cores gleichzeitig machen sollen?
Und nochmal zurück zum "nur gleichzeitig lesen, und nur einer darf schreiben" Gedankenexperiment: wie willst du das alles synchronisieren, so dass während ein Cache-Update im Gange ist, die lesenden Cores nicht Mist lesen?
Und zwar so synchronisieren, dass alles 100% gleich schnell bleibt?
Zeig mir eine CPU mit shared L1 Cache, und ich zeig dir eine CPU die Performance verschenkt.
-
PhilippHToner schrieb:
Ja doch, du kommst mit deinem tollen SharedCache her aber dass der ganze Müll auch in Registern ist, ist dir Wurst? Willst du jetzt mit SharedRegistern arbeiten
Man PhillipHToner,
es geht um die Konsistenz zwischen den L1 Caches...
Die Register sind mal längst völlig uninteressant.
-
jenz schrieb:
es geht um die Konsistenz zwischen den L1 Caches...
Die Register sind mal längst völlig uninteressant.Mein NOT-Shared L1 Cache braucht gar nix bzgl. Konsistenz und wenn doch, dann kümmert sich dass OS darum, weil ich in meinem Programm explizit ein Mutex locke.
Dein Shared L1 Cache hat mein geschildertes Problem!!
