dual core / quad core optimiert programmieren
-
CMatt schrieb:
Allen den Fakt, dass sich die kerne den selben L2 cache teilen kann man sehr gut ausnutzen, oder eben nicht und halt nur 120% statt 200% aus deinem code raus hohlen wegen das ständigen cache-misses.
Ich glaube nicht, dass man das direkt ausnutzen sollte. Und zwar, weil dieses Architekturdetail nur auf eine Teilmenge der momentan erhältlichen 2-Kern-CPUs zutrifft. Das ist nur bei den Core 2 Duos der Fall. Bei den Prozessoren von AMD ist das nicht der Fall, beim Pentium D ist das nicht der Fall und beim neuen 4-Kern Prozessor von Intel ist das auch nur zur Hälfte der Fall. Wenn man soetwas direkt ausnutzt, dann stellt sich doch die Frage, welche Auswirkungen das bei Prozessoren hat, bei denen die Kerne keinen gemeinsamen L2 Cache haben.
Aber abgesehen davon: Mir ist eh nicht ganz klar, wie Du das genau ausnutzen willst. Wie würde denn eine entsprechende Optimierung aussehen, die Du bei getrennten L2 Caches nicht machen würdest. Und warum würdest Du diese Optimierung da nicht machen.
Ich sehe den gemeinsamen L2 Cache der Kerne eigentlich als Bonus, der sich völlig unabhängig von der Software positiv auswirkt: Man hat einfach effektiv mehr Cache im Prozessor. Wenn man da ein Programm mit nur einem Thread nutzt, dann hat dieses den doppelten Cache zur Verfügung und wenn man mehrere Threads nutzt, dann werden Daten zumindestnicht mehrmals im Cache gespeichert, wodurch man letztendlich auch wieder mehr Cache zur Verfügung hat.
-
@Gregor
Mehrere Cores und ein L2 Cache sorgt dafür, das besonders Anwendungen, die viel aus dem Speicher lesen (eben oft den Cache brauchen) und sich schlecht parallelisieren lassen (also von mehreren Prozessen nicht so viel profitieren), mit einem Core schneller sind, als mit allen Vieren. Ob das nun ein Nachteil ist (Man gibt Geld für n unnötige Cores aus) oder ein Vorteil (man erhält einen Core mit großem L2) ist natürlich die Frage des Betrachters
-
rüdiger schrieb:
Mehrere Cores und ein L2 Cache sorgt dafür, das besonders Anwendungen, die viel aus dem Speicher lesen (eben oft den Cache brauchen) und sich schlecht parallelisieren lassen (also von mehreren Prozessen nicht so viel profitieren), mit einem Core schneller sind, als mit allen Vieren.
Das kann ich erstmal nicht nachvollziehen. Ich kann mir vorstellen, dass diese Anwendungen durch mehrere Kerne nicht beschleunigt werden können, aber ich kann erstmal nicht nachvollziehen, dass sie dann plötzlich langsamer sein sollen. Erklär das mal.
Abgesehen davon: Was genau hat das mit speziellen Optimierungen für einen gemeinsamen L2 Cache aller Kerne zu tun?
-
Um mal auf die ursprüngliche Frage einzugehen:
Verwende VS2005 mit OpenMP:
http://msdn.microsoft.com/msdnmag/issues/05/10/OpenMP/default.aspx
-
Gregor schrieb:
rüdiger schrieb:
Mehrere Cores und ein L2 Cache sorgt dafür, das besonders Anwendungen, die viel aus dem Speicher lesen (eben oft den Cache brauchen) und sich schlecht parallelisieren lassen (also von mehreren Prozessen nicht so viel profitieren), mit einem Core schneller sind, als mit allen Vieren.
Das kann ich erstmal nicht nachvollziehen. Ich kann mir vorstellen, dass diese Anwendungen durch mehrere Kerne nicht beschleunigt werden können, aber ich kann erstmal nicht nachvollziehen, dass sie dann plötzlich langsamer sein sollen. Erklär das mal.
Sie sind eben schneller, wenn sie einen großen L2-Cache haben, als einen Cache der von 4 Prozessen geteilt wird. Ich habe da mal so Benchmarks gesehen, als IBM damals die Multicore-Prozessoren eingeführt hat (das war afair ein paar Jahre vor Intel/AMD). Ich werde mich mal auf die Suche gehen.
-
rüdiger schrieb:
Sie sind eben schneller, wenn sie einen großen L2-Cache haben, als einen Cache der von 4 Prozessen geteilt wird. Ich habe da mal so Benchmarks gesehen, als IBM damals die Multicore-Prozessoren eingeführt hat (das war afair ein paar Jahre vor Intel/AMD). Ich werde mich mal auf die Suche gehen.
Das glaube ich gerne. Brauchst gar nicht suchen, das nehme ich Dir auch so ab. Und mir ist auch klar, dass ein gemeinsamer Cache für mehrere Kerne von Vorteil ist. IMHO ging es aber gar nicht darum. Ich glaube, wir haben da etwas aneinander vorbeigeredet: Mir ging es eigentlich um Optimierungen der Software für einen gemeinsamen bzw. getrennte Caches. Vielleicht sollten wir das einfach so beenden.
-
Warum wird da gleich zu OpenMP oder MPI oder allgemein Parallel Computing geraten?
Ich hab den Eindruck alles was der Threadersteller braucht ist ein Verweis auf Threads bzw. Multithreaded Programming. (kann mich auch irren, muss der Ersteller entscheiden).Mal ganz allgemein gefragt (von OpenMP weiss ich nur soviel, wie ich gerade im dt. Wikipedia ueberflogen hab):
wenn ihr ein Programm schreiben wollt, welches von Mehr-Kerne Prozessoren profitieren soll, verwendet ihr dann Threads oder greift ihr zu Methoden des Parallel Computing? Was sind die Vorteile der jeweiligen Vorgehensweisen?
-
OpenMP hat den grossen Vorteil, dass Du Dich nicht darum kümmern musst die Aufgaben auf die Anzahl der Prozessoren zu verteilen; sondern dies wird eben selbsständig gemacht.
OpenMP ist eigentlich das was Du sonst als "Rahmenwerk" drum-rum basteln müsstest umd die Aufgaben auf eine entsprechende Anzahl zu verteilen.
Ein simpler Verweis auf Threads ist nicht sehr hilfreich, da er das eigentliche Problem (aufteilung auf eine vorher nicht bekannte Anzahl von Threads) löst.Also: Wenn Zeit wirklich eine Rolle spielt und man so viel wie möglich Leistung aus dem Rechner holen will und man auch noch relativ einfach damit Programmieren will, dann führt IMHO an OpenMP nichts vorbei.
Alle anderen mir bekannten Ansätze sind wesentlich komplexer und bieten für ein (nicht verteiltes) PC-System keinen Vorteil.
-
Gregor schrieb:
Das kann ich erstmal nicht nachvollziehen. Ich kann mir vorstellen, dass diese Anwendungen durch mehrere Kerne nicht beschleunigt werden können, aber ich kann erstmal nicht nachvollziehen, dass sie dann plötzlich langsamer sein sollen. Erklär das mal.
das kann viele ursachen haben beim p4HT z.b. cache trashing, oder pipeline-loops/stalling . dazu gibt es so einige paper, manche leider nicht public. am ende verhaellt sich eh jede cpu-art anders und man muss fuer diese dann optimieren.
grundsaetzlich sollte man eine neuere cpu haben (p4HT ist suboptimal), dann nur die daten die read only sind zwischen threads sharen, ansonsten die daten mehrfach anlegen. am besten ist natuerlich wenn aus shared-readonly daten neue daten generiert werden ohne das auf vorherige daten aufgebaut wird z.b. beim rendern eines bildes kann man perfekt das bild in unabhaengige stuecke aufteilen.
-
DeEX schrieb:
Daher ist die frage nun: was muss ich beim programmdesign beachten um entstehende rechenlast gleichmäßig auf 2 od. 4 bzw später auch mal mehr kerne zu verteilen.
Cluster Computing | ISBN: 3540422994
Das Buch ist einfach nur geil!
Es geht aber nicht speziell auf Dual-/Quadprozessoren ein, sondern generelle CPU Architekturen, Lastverteilung und Kommunikation!cu
P84