SMP Kompatibilität

FLOI

Commodore Special
Mitglied seit
11.11.2001
Beiträge
436
Renomée
3
Hallo

ich finde es passt ganz gut hier rein

ist SMP eigentlich auch nach unten kompatibel
bisher werden die threads ja einfach verwaltet
bei dualcore optimierter software müsste ja expliziet dorststehen das macht prozessor1 und das macht prozessor2
was passiert wenn nun eine singlecore cpu in system steckt?

wie sieht das ungefähr aus?
oder auch bei 4 oder 8 cores
 
Du kannst als Programmierer nur festlegen, wieviele Threads dein Programm hat, aber nicht, auf welchen CPUs diese ausgeführt werden. Das ist auch durchaus sinnvoll, da du ja nicht wissen kannst, auf was für ein System das Programm mal läuft. Die Zuteilung der Threads auf die CPUs sollte eigentlich das Betriebssystem übernehmen. Ist das OS in der Lage, mit mehreren CPUs umzugehen, wird es die Threads automatisch verteilen. Ansonst ist die Situation äquivalent zu Einprozessorsystemen, es wird halt nur eine CPU genutzt.
 
Man kann dabei aber auch selbst nachhelfen. das OS kennt nicht unbedingt die "cleverste" bzw. performanteste Verteilung deiner Threads auf die CPUs.
Allerdings ist sowas recht komplex. (Multithreading fähig zu programmieren ist bei einigen Anwendungen schon unangenehm, aber auch noch selbst das Management zu übernehmen pfffffft. Das muss schon was besonderes sein)
 
Mit MPI oder OpenMP kann man echt parallele Programmierung machen. Ist aber - wie gesagt - recht tricky.

Es lohnt sich eher für mathematische Probleme, also Algorithmen, die aus der echten Parallelität Nutzen ziehen können.
 
MPI ist aber eher für cluster interessant ("distributed memory"), insbesondere auch für "heterogene" Netzwerke. Dagegen ist OpenMP für SMP Maschinen gedacht ("shared memory") und da SMP normalerweise ziemlich "homogen" ist, ist das "load balancing" entsprechend einfacher.

Vorteil von beidem gegenüber threads: Man hat einen portablen Standard... Und sooo tricky sind die Sachen nicht. Besonders mit OpenMP kann man mit wenigen Befehlen datenparallele Progs auf mehren CPUs verteilen. (Die andere Sorte der Parallelität wäre auf algorithmischer Ebene, daß einzelne Stufen parallel abgearbeitet werden. Dieses wird dann durch eine "pipeline" realisiert. Dies ist entsprechend schwieriger als Datenparallelität - insbesondere was das load balancing angeht.)

Worum es aber oben im thread geht ist "scheduling". Hat zwar was mit load balancing zu tun, aber ist doch ein (sehr komplexes) Gebiet für sich.
 
Zuletzt bearbeitet:
PuckPoltergeist schrieb:
in welcher Umgebung soll das ganze denn stattfinden? C? ASM? Java?
Visual Basic? :)

Ich habe selbst noch nie versucht den Scheduler für die TASK / SMP-CPUs nachzubilden.

Versuche doch erstmal dein Glück (sagen wir in C++) mit CreateThread().
Die CPU kannst du mit SetThreadIdealProcessor() versuchen festzulegen.

Du wirst genug damit zu tun haben die Threads und vorallem dessen (gemeinsame) Ressourcen zu managen dass du froh bist nichts mit der eigentlichen arbeit am Hut zu haben.
Du kannst die Threads auch bezüglich Ihrer Priorität beeinflussen: SetThreadPrioriy()


für den ganzen spass brauchst du die Kernel32.lib.
Viel Spass :)


Wo versagt denn das OS bei der Zuweisung?

Nur du kennst die Abläufe und Kommunikationen in deinem Programm. Abhängig davon wie stark die Threads gegenseitig auf ihre ressourcen zugreifen, ob du ein echtes SMP System hast oder nur HT oder ob NUMA zur Verfügung steht oder nicht kann es "performanter" sein einige Dinge direkt zuzuordnen....
 
EoR schrieb:
aus diesem Posting

in welcher Umgebung soll das ganze denn stattfinden? C? ASM? Java?
Visual Basic? :)

Ich habe selbst noch nie versucht den Scheduler für die TASK / SMP-CPUs nachzubilden.

Versuche doch erstmal dein Glück (sagen wir in C++) mit CreateThread().
Die CPU kannst du mit SetThreadIdealProcessor() versuchen festzulegen.

Du wirst genug damit zu tun haben die Threads und vorallem dessen (gemeinsame) Ressourcen zu managen dass du froh bist nichts mit der eigentlichen arbeit am Hut zu haben.
Du kannst die Threads auch bezüglich Ihrer Priorität beeinflussen: SetThreadPrioriy()


für den ganzen spass brauchst du die Kernel32.lib.
Viel Spass :)

Ich habe nicht vor, das selber zu machen. Wollte nur wissen, wie das möglich sein soll. Unter Linux (womit ich eigentlich fast nur arbeite) ist mir keine derartige Funktionalität bekannt, und mich hat halt interessiert, wie man sowas beeinflussen kann. Bis jetzt wahr ich nämlich der Meinung, dass dies so gar nicht möglich wäre. ;)

Nur du kennst die Abläufe und Kommunikationen in deinem Programm. Abhängig davon wie stark die Threads gegenseitig auf ihre ressourcen zugreifen, ob du ein echtes SMP System hast oder nur HT oder ob NUMA zur Verfügung steht oder nicht kann es "performanter" sein einige Dinge direkt zuzuordnen....

Also das muss schon eine sehr ausgefallene Situation sein, dass da der Scheduler des OS versagt. Eigentlich berücksichtigt das alles schon das OS, wenn es die Prozesse/Threads auf die einzelnen CPUs zuweist.
Ja ich weiß mittlerweile auch, dass der Windows-Scheduler wohl nicht so das Wahre ist. Unter Linux hatte ich bis jetzt jedenfalls noch kein Grund zur Beschwerde. :)
 
PuckPoltergeist schrieb:
aus diesem Posting

Ich habe nicht vor, das selber zu machen. Wollte nur wissen, wie das möglich sein soll. Unter Linux (womit ich eigentlich fast nur arbeite) ist mir keine derartige Funktionalität bekannt, und mich hat halt interessiert, wie man sowas beeinflussen kann. Bis jetzt wahr ich nämlich der Meinung, dass dies so gar nicht möglich wäre. ;)

Unter linux machsu:
#include <pthread.h>

pthread_create(...)

Mit den den Attributen (z.B. PTHREAD_EXPLICIT_SCHED) kannst du auch einfluss nehmen auf den Taskscheduler. Wie die direkte CPU Zuordnung funktioniert kann ich dir nicht sagen. Guck dir einfach mal pthread.h an.
 
EoR schrieb:
aus diesem Posting

Unter linux machsu:
#include <pthread.h>

pthread_create(...)

Mit den den Attributen (z.B. PTHREAD_EXPLICIT_SCHED) kannst du auch einfluss nehmen auf den Taskscheduler. Wie die direkte CPU Zuordnung funktioniert kann ich dir nicht sagen. Guck dir einfach mal pthread.h an.

Damit kann man aber nur festlegen, dass der Thread auf der CPU zu bleiben hat, auf welcher er erzeugt wurde. Andere Möglichkeiten gibts da IMHO nicht.
 
Zurück
Oben Unten