PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Sind Multithreaded-Anwendungen auf Single Core per se langsamer?


Benedikt
2005-12-06, 00:52:30
Frage siehe Topic: Kann in Threads unterteilte Programmierweise auch auf Single-CPUs Geschwindigkeitsvorteile bringen, oder erhält man dadurch hauptsächlich zusätzlichen Verwaltungsaufwand, welcher die Geschwindigkeit wieder drückt? Die Beispiele von multithreaded Software, die ich bisher genutzt habe, liefen eigentlich bei deaktiviertem Multithreading meist schneller auf meinem Einzel-P4.
Was ich hier nicht meine, ist unterteilte Programmierweise beispielsweise im Sinne von einem Hintergrundthread, der verhindert, dass das UI blockiert. Es geht mir hier wirklich "nur" um geschwindigkeitskritische, parallelisierbare Programmteile auf einem einzelnen Prozessor!?

ethrandil
2005-12-06, 01:26:41
Solange die parallelen Thrreads absolut Speicher oder CPU-lastig sind, kann ich mir nicht vorstellen, dass es was bringt (außer evtl. beim Hyperthreading).

Bei IO-Lastigem kann zwar durchaus ein Geschwindigkeitsvorteil erreicht werden, sowas hast du ja aber in deinem Beitrag fast ausgeschlossen ;o).

- Eth

zeckensack
2005-12-06, 01:30:54
Da gibt's einen gewissen Overhead. Jedes mal wenn der Scheduler auf einen anderen Thread wechselt, verlierst du in der Größenordnung 1~2µs an Zeit (Windows, >=2GHz CPU).

Es ist in der Tat sehr schwierig eine Applikation auf die Ausnutzung von Multicores auszulegen, ohne sie gleichzeitig auf Einzelprozessoren langsamer zu machen.
Im günstigsten Fall fragst du zur Laufzeit die Anzahl der Prozessoren ab, und wenn nur einer da ist, startest du einfach keine Arbeiterthreads, sondern arbeitest "direkt" (was genau das heißt hängt von deinem Design ab, aber ich war selber schon da ...).

Benedikt
2005-12-07, 01:14:43
Okay, also wenn möglich mit CPU-Abfrage. Danke! :)

Wie sieht's denn in punkto maximale (sinnvolle) CPU-Anzahl bei den derzeit am Markt erhältlichen, für Multithreading geeigneten Anwendungen aus? Es ist ja nur eine Frage der Zeit, bis aus Dual-Core-CPUs solche mit mehr Kernen (4, 8) werden - sind derzeitige auf Parallelbetrieb ausgelegte Anwendungen auch für mehr als zwei Kerne ausgelegt, oder steht uns da das nächste Henne-Ei-Problem ins Haus?

Neomi
2005-12-07, 01:44:32
Wie sieht's denn in punkto maximale (sinnvolle) CPU-Anzahl bei den derzeit am Markt erhältlichen, für Multithreading geeigneten Anwendungen aus? Es ist ja nur eine Frage der Zeit, bis aus Dual-Core-CPUs solche mit mehr Kernen (4, 8) werden - sind derzeitige auf Parallelbetrieb ausgelegte Anwendungen auch für mehr als zwei Kerne ausgelegt, oder steht uns da das nächste Henne-Ei-Problem ins Haus?

Zwei Kerne sind nur der erste Schritt, und der erste Schritt ist immer der schwerste. Solange die Arbeit weit genug aufgeteilt werden kann, kann jeder weitere Kern beschäftigt werden. Renderfarmen sind da ein sehr gutes Beispiel.

mapel110
2005-12-07, 01:50:28
Okay, also wenn möglich mit CPU-Abfrage. Danke! :)

Wie sieht's denn in punkto maximale (sinnvolle) CPU-Anzahl bei den derzeit am Markt erhältlichen, für Multithreading geeigneten Anwendungen aus? Es ist ja nur eine Frage der Zeit, bis aus Dual-Core-CPUs solche mit mehr Kernen (4, 8) werden - sind derzeitige auf Parallelbetrieb ausgelegte Anwendungen auch für mehr als zwei Kerne ausgelegt, oder steht uns da das nächste Henne-Ei-Problem ins Haus?
Soweit ich das hier im Forum mittlerweile mitbekommen habe, wird erst gar nicht auf 2 Kerne(Threads) optimiert, sondern wenn möglich generell auf beliebig viele (sinnvolle) Kerne bzw Threads, um sich eben Anpassungen für die Zukunft zu sparen.

Ganon
2005-12-07, 08:55:54
Wobei sich natürlich fragt ob ein normaler Anwender eine 4,8, oder mehr Core-CPU (wenn sie denn mal kommt) wirklich auslasten kann. Weil es geht ja im Endeffekt dahin das die Grafikkarte alles wirklich rechenintensive macht. Sei es Video-De/Encoding oder irgendwann Raytracing...

Köppchen
2005-12-07, 22:57:58
Das ist eine Frage der Implementierung.

Ein Beispiel aus der Praxis:
Bei DXO Optics, einer Software zum "entwicklen" von Digitalen Bildern wird in der neuesten Version dual Core unterstüzt.
Bei der Umsetzung in der Software hat man es sich recht einfach gemacht. Statt jedes Bild einzeln zu entwickeln (Batch) können nun entsprechend der Anzahl Prozessoren mehrere Bilder gleichzeitig entwickelt werden.
Diese Umsetzung war mit Sicherheit recht einfach und läuft auf einer Single Core CPU sicher nicht langsamer als vorher.
Aber für mehrere Cores sind die Folgen evtl. fatal. Der Verarbeitungsprozess für ein einzelnes Bild meiner Kamera (Canon 300D,6MPixel) benötigt ca. 500MB Hauptspeicher. Das bedeutet für 2 gleichzeitige Bilder würde etwa 1GB benötigt. Was bei (nur) 1GB Hauptspeicherausbau dann passiert kann man sich einfach ausmalen.

Gruß Markus

Benedikt
2005-12-08, 12:14:16
Aber prinzipiell muss man Multiprocessing-fähige Software, wenn ich das richtig verstanden habe, explizit für die gewünschte Anzahl von CPUs programmieren (z. B. durch die Aufteilung in die entsprechende Anzahl von Worker-Threads), oder? Worauf ich hinaus will: Multicore-optimierte Software ist nicht von vorn herein auf Skalierung/Nutzung von einer beliebigen Anzahl von CPUs festgelegt? Schade eigentlich - Apple wird mit seinen Quad-G5-Powermacs wohl auch vor demselben Problem stehen.


/Nachtrag: Obwohl, z. B. bei make unter Linux kann man ja mit -j[Anzahl] auch eine beliebige Threadanzahl festlegen...

Demirug
2005-12-08, 12:31:32
Abhängig von der Aufgabe kann man auch durchaus für eine Variable Anzahl von CPUs optimieren.

OpenMP zum Beispiel versucht das. Makiert man eine Schleife im Code als "Multicore fähig" wird sie von OpenMP in genau so viele Teile zerlegt wie CPUs zur Verfügung stehen.

Ganon
2005-12-08, 12:55:50
OpenMP zum Beispiel versucht das. Makiert man eine Schleife im Code als "Multicore fähig" wird sie von OpenMP in genau so viele Teile zerlegt wie CPUs zur Verfügung stehen.

Da wird dann eine Schleife mit 10 Durchläufen bei 2 CPUs also auf 2 Thread à 5 Durchläufe aufgeteilt, oder wie funktioniert das?

Demirug
2005-12-08, 12:59:20
Da wird dann eine Schleife mit 10 Durchläufen bei 2 CPUs also auf 2 Thread à 5 Durchläufe aufgeteilt, oder wie funktioniert das?

Ja genau so. Wobei es auch noch die Option für dynamische Verteilung gibt. Also immer wenn eine CPU mit einem "Durchlauf" fertig ist nimmt sie den nächsten der noch nicht bearbeitet wird. Das ist dann interesant wie die Arbeit pro Durchlauf nicht identisch ist.

Juerg
2005-12-08, 13:36:32
Da wird dann eine Schleife mit 10 Durchläufen bei 2 CPUs also auf 2 Thread à 5 Durchläufe aufgeteilt, oder wie funktioniert das?Wie Demirug schon sagte, mit der Einschränkung, dass der Druchlauf n nicht vom Resultat des Durchlaufs n-1 abhängt. Dies würde die Parallelität nicht verhindern aber doch stark einschränken.