Zitat:
Original geschrieben von alfora
Wenn ich jetzt versuche, die Aussage von ganz oben zu interpretieren, dann passt nur Möglichkeit A dazu. Dann weiß ich aber noch immer nicht, warum ich extra für MultiCores programmieren müsste. Ich muss ja schon bei Single-CPUs auf die Qualität meiner Threads achten, damit dort nicht zuviel Rechenleistung durch unnötige Kommunikation verbraten wird.
|
Es ist sicher Variante A und Threads haben auch auf einem Single CPU System Vorteile naemlich dann wenn mehrere Sachen einfach "parallel" machen moechte. Die laufen dann aus CPU Sicht nicht wirklich parallel sondern bekommen vom Scheduler entsprechende Zeitscheiben zugewiesen. Das switchen zwischen den Threads erfolgt dann aber so schnell das es aus Sicht des Users praktisch parallel laeuft. Bspw. mochte man in einem GUI Menuefenster nicht unbedingt den weiteren Programmablauf blockieren bis die Eingaben dort abgeschlossen sind. Sie ermoeglichen also auch eine Form der strukturierten Programmierung ohne alles in einer riesigen unuebersichtlichen Schleife reinquetschen zu muessen. Dabei kann die anfallende CPU-Arbeit auch extrem asymetrisch verteilt sein. Ein GUI oder Eingabetread verbraucht vielleicht nur 0.1% CPU Last gegenueber der eingentlichen Rechenaufgabe des Programms folglich ist der Gewinn wenn man ihn parallel auf einer 2. CPU laufen lassen wuerde auch nur entsprechend gering.
Um wirklich Gewinn von Multiprozessorsystemen zu ziehen muss das Programm also Threads schaffen die die Gesamtarbeit auch wirklich moeglichst gut aufteilen.
Und dies bedeutet nichts anderes als zu schauen wo faellt welche Arbeit an und wo gibt es welche Abhaengigkeiten.