ThreadPool bei "Heavy Load"

[creality]

Hey Leute,

ich habe einen ThreadPool geschrieben um massiv parallel Bilder zu analysieren. Dabei schneidet ein Manager das Bild in X Teile und übergibt jedem Job ein Bildschnipsel.
Und nun rattern die Threads los...und nach paar Minuten wird wieder alles gemerged. Soweit wunderbar.

Feststellung
- Egal wie viele Threads man nimmt - eine wirkliche Zeitersparnis kommt nicht zu stande
- Ein einzelner Thread der das ganze Bild analysiert braucht nur minimal länger als mehrere "Teil Threads"
- wenn kein Bild analysiert wird, sondern der Job nur 100000000x die Wurzel aus (1000000000) bildet soll funktioniert alles super und die Zeitersparnis ist enorm

Frage
Kann es sein, das die Analyse von Bildern so Speicherlastig ist, dass ein ThreadPool nur bedingt Vorteile bringt?

System
2xQuad Xeon
4GB Ram
XP32

[OldGrumpy]

Verteilst Du die Threads explizit auf die einzelnen Cores?

[creality]

Nein das überlasse ich Windows...funzt auch. Alle Kerne voll ausgelastet.

[sirius]

Und die Threads arbeiten völlig unabhängig ohne Synchronisationen?

[OldGrumpy]

Prinzipiell teilen sich alle Kerne ja mehr oder weniger die Hauptspeicherzugriffe, das wird hier wohl der Flaschenhals sein. Abhilfe bringt es wenn man Codemenge und Datenmenge soweit reduziert, dass die Cores weitgehend mit ihrem Cache arbeiten können. Je nach Datenmaterial und Aufgabenstellung ist das natürlich ein Problem. Evtl. macht es Sinn, die Cores unterschiedliche Aufgaben machen zu lassen, indem man die Verarbeitung in mehrere Stages aufteilt. Ein Core macht dann z.B. Preprocessing, der nächste Weiterverarbeitung Stage 1, usw. - ohne detailierte Kenntnis der Problemstellung ist das aber natürlich erstmal nur ein Schuss ins Blaue.

[creality]

Hmm...das ist schon ein guter Schuss.

Nur leider wird sich das so nicht verwirklichen lassen. Ich berechne sozusagen den Mittelwert eines Bildstapels der aus 30 Bildern besteht. Also 30x33MByte an Daten. Dazu kommen noch etliche Ergebnis-Zwischenspeicher um Zwischenergebnisse extra zu behandeln.

Insgesamt kratze ich dadurch an 2.1GByte Hauptspeicher rum...und leider gibts hier keine Extra Stages. Ich denke Du hast Recht mit der Aussage das der Cache und die Ramzugriffe hier der Flaschenhals sind. Verdammt...wie machen das nur die Leute bei Adobe?!?! Die nutzen auch ImageSliceing und nen Pool.

Tja...da werd ich mir wohl was anderes überlegen müssen ;-(

[shmia]

Viele Threads können nur dann schneller sein, als ein einzelner Thread, wenn bei der Arbeit, die zu tun ist,
auf Resourcen gewartet werden muss.
Anderst gesagt, die Arbeit muss Wartezeiten wegen externer Resourcen enthalten.

Positiv-Beispiele:
A.) Ich möchte 100 Dateien aus den Internet runterladen.
Ich bin schneller wenn mehrere Thread dies tun und so meine lokale Netzwerkbandbreite komplett auslaste,
als wenn ich jede Datei sequenziell runterlade.
B.) ich möchte viele Dateien laden und die MD5 Prüfsumme bilden.
Mehrere Threads sind schneller, da während der eine Thread auf Daten von der Platte wartet, während der andere die MD5 Berechnungen durchführt.
Hier wird der Festplattendurchsatz maximiert. (aber nur, wenn es nicht zu viele Thread sind)

Negativ-Beispiel:
Ich möchte ein Mandelbrot Bild im Standardalgorithmus zeichen.
Es bringt leider nix, wenn ich 16 Threads starte, die jeweils ein 16tel Bild berechnen.
Die Rechenarbeit bleibt in der Summe gleich (+ Thread overhead).

Dies gibt für einen Einzelprozessor.
Für einen Doppelkernprozessor müsste sich der Durchsatz maximieren, wenn ich 2 Threads verwende und jeweils an einen bestimmten Kern binde.

==> Ergo: bei massiven Rechenarbeiten verwendet man einen Thread pro Kern.
Bei Arbeiten, die Wartezeiten enthalten, darf die Threadanzahl 2 bis 10 Mal höher sein.

[creality]

Tja das dachte ich ja auch. Ich habe ja 8 Kerne --> 8 Threads. Leider ist es nicht so, dass hier ein Vorteil zu erkennen ist. Bei einem Einzelkernprozessor isses klar das mehrere Threads in der Regel nur wenig bringen.

[shmia]

Zitat:

Zitat von creality

Tja das dachte ich ja auch. Ich habe ja 8 Kerne --> 8 Threads. Leider ist es nicht so, dass hier ein Vorteil zu erkennen ist.

Versuch doch mal mit SetThreadIdealProcessor() jedem Thread seinen Kern zwischen 0..7 zuzuweisen.
Mit SetThreadAffinityMask() kann man die Zuordnung zwischen Thread und Kern noch härter setzen.