Multiprozessoranpassung von Software

[Doh!]

Ich habe gerade festgestellt, dass ich noch eine klaffende Wissenslücke in Sachen Multiprozessor-Systeme habe, die mir eine Google-, freehackers-, gcc-, linuxforen-, uvm-, Suche nicht beantworten konnte.

Kann man Software beim Kompilieren ebenfalls an Multiprozessorumgebungen anpassen (mit einem entsprechenden Flag) oder geht alle Multiprozessormacht nur vom Kernel aus?

[HEMIcuda]

AFAIK ist Software, wenn sie mit Threads kompiliert wurde, multiprozessorfaehig. Da braucht man
sich nicht gesondert drum kuemmern. Ob das Programm was mit mehreren Prozessoren anfangen
kann, steht allerdings auf einem ganz anderen Blatt.

'cuda

[Jasper]

Original geschrieben von HEMIcuda
AFAIK ist Software, wenn sie mit Threads kompiliert wurde, multiprozessorfaehig. Da braucht man


wenn du damit 'multithreaded' meinst, ja, ansonsten nein. die software muss von sich aus bereits für mehrere threads ausgelegt sein (sync/lock-probleme). man kann natürlich die gleiche applikation mehrere male starten, aber das ist trivial und hier sicher nicht gemeint.

kurz gesagt, man kann nicht durch einen magischen schalter eine software smp-fähig im sinne von ausnutzen aller prozessoren machen.


-j

[Doh!]

Original geschrieben von Jasper


kurz gesagt, man kann nicht durch einen magischen schalter eine software smp-fähig im sinne von ausnutzen aller prozessoren machen.


-j

Das wollte ich wissen. Das heißt der Kernel verteilt die Prozesse auf die Prozessoren, das war's

[HEMIcuda]

Original geschrieben von Jasper
wenn du damit 'multithreaded' meinst,[...]
Aehm... ja :D

'cuda

[Jasper]

Original geschrieben von Doh!
Das wollte ich wissen. Das heißt der Kernel verteilt die Prozesse auf die Prozessoren, das war's

yep, mehr macht er nicht. ein thread ist für den kernel auch nur prozess, eine art "light"-prozess. alle kernel bis 2.6 haben allerdings ein kleines problem, der scheduler verteilt die prozesse "blind", d.h. prozesse wandern im worst-case zwischen den prozessen. dadurch verlieren die prozessor-caches (L1 und L2) ihre funktionalität, schlimmer noch, durch die cache-misses sinkt die performance. das ist bei 2.6 behoben. da sind die prozesse cpu-affin (das feature nennt sich prozessoraffinität oder cpu-affinity (falls jemand danach suchen will), d.h. der scheduler weist die prozesse möglichst immer wieder dem gleichen prozessor zu.
der neue O(1) scheduler im 2.6 ist richtig gut.

mist, schon wieder soviel geschrieben :)


-j

[zander]

Man sollte jedoch beachten, daß nicht jede Anwendung mit mehreren threads auch merklich von einer Mehrprozessorarchitektur profitiert; beachtliche Gewinne wird man nur beobachten können, wenn die threads ähnlich komplexe Aufgaben übernehmen; das ist bei vielen solchen Anwendungen nicht der Fall, quake3-smp und tribes2 benutzen so z.B. getrennte threads nur für I/O und renderer (hier sind auch negative Auswirkungen denkbar). Es gibt (abgesehen von Servern) nicht sehr viele Anwendungen, die unmittelbar profitieren würden.