Multithreading, volatile, Cache usw.
-
@jenz
Du stellst dir das alles viel zu einfach vor.
Fakt ist, dass ein Cache auf den 2 oder mehr Cores gleichzeitig zugreifen können komplizierter und langsamer ist als ein Cache auf den nur eine CPU zugreifen kann.Deswegen baut man CPUs die für jeden Core einen eigenen L1 und L2 Cache haben, und schaltet dann erst einen gemeinsamen L3 Cache dahinter.
(Zumindest die aktuellen Intel und AMD CPUs machen das genau so)was genau muss sychronisiert werden?
bzw. wieso muss das vom cache synchronisiert werden?wenn auf gleiche daten zugegriffen werden soll, dann muss das doch von der software synchronisiert werden.
Ich wiederhole mich nicht gerne, aber... du stellst dir das alles viel zu einfach vor.
-
jenz schrieb:
Ja, das ist ja auch klar.
Wir sind aber bei einem ganz anderen Problem bzw. Fragestellung:
"Sind mehrere L1 Caches sinnvoller als ein gemeinsamer, bzw. warum nimmt man nicht einen gemeinsamen."jenz
Is des jetzt so schwer? Google mal: Datenkonsistenz. Wie willst du eine Datenkonsistenz in einem gemeinsamen Cache realisieren ...
// edit Zusatz: bei gleicher Geschwindigkeit!
-
Naja,
in dem schönen link von Michael E.
http://people.engr.ncsu.edu/efg/506/s01/lectures/notes/lec16.html
steht jedenfalls, dass man das für SingleChipMultiProzessoren genau so machen kann und anscheinend auch solche Architekturen existieren.
Also einen gemeinsamen L1 Cache.INTEL hat aber zum Beispiel nur den L3 geshared.
jenz
-
Hier lesen: http://www.elektronik-kompendium.de/sites/com/0309291.htm
DIe Frage die Ihr euch stellen könnt ist auch, warum hat der L1 Cache N kB und nicht 2*N kB? Weil einfach alles sehr kompakt ist! Es gibt platztechnische Probleme. Es gibt noch 100 Probleme, die vielleicht Grund sind, warum es nicht so ist.
Wie viel Strecke legt der Strom bei 3,6 GHz bei 70°C in Kupfer zurück, zzgl. der "Gatter". Angenommen er fließt Lichtgeschw. 0,3Gm/s (300 000km/s), würde er 8cm weit kommen.
Ich befasse zur Zeit mit OpenCL und da geht es um das Thema, wieviel Zukunft unsere Multicore CPUs haben. Nämlich 0! Mit zunehmender Frequenz steigt die Hitzeentwicklung (nicht nur linear). Würde man das Problem der Hitze lösen können, würde man an die physikalische Grenze der elektronische Flussgeschwindigkeit kommen, in Kombination der Schaltzeiten von "Gatter" uvm... also Manycore-ARchitekturen werden kommen und spätestens da, werden wir uns um mehrere SPeicherebenen kümmern dürfen, wie es in OpenCL bereits der Fall ist: Register, lokaler Speicher, konstanter Speicher (vergleichbar L3), globaler Speicher (RAM). Man sagt, dass der globale Speicher mit Faktor 100 langsamer arbeitet als der lokale. Bei solch einem Thema der Speicherverwaltung, ist es sinnvoll, dass der Programmierer Hirn investieren sollte, damit nicht unnötige Sachen passieren, aber synchronisieren darf er den lokalen Speicher und den globalen Speicher.Reicht das jetzt als Feeling, dass hier keine zusätzlichen Leiterbahnen verbaut werden können, was auch immer der Grund ist.
-
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.
