JobQueue - MultiThread

[Kiffi]

[ot]
Sorry für Offtopic, aber ich wollt mich einfach mal bei dir bedanken Alex.
Deine Codes in hier sind eine echte Bereicherung fürs Board, ich hab immer
wieder Spaß daran sie mir durchzusehen - du schreibst echt gut!
Bitte weiter so...
[/ot]

ganz dickes +1

Grüße ... Kiffi

[cxAlex]

Update:

• JobQueue_Free(), JobQeue_Pause(), JobQueue_Resume(): Reagieren nun sofort und nicht erst nach Abarbeitung aller Jobs
• JobQueue_AddWorker(), JobQueue_RemoveWorker(): Optinaler Parameter um x Worker zu entfernen/hinzuzufügen
• JobQueue_WaitForFinish(): Warten bis alle Jobs erledigt werden
• JobQueue_WaitForJob(): Warten bis ein bestimmter Job erledigt wurde
• JobQueue_Init(): Optinaler Parameter um Stack-Blockgröße einzustellen
• MutexLock bei ReadOnly - Zugriffen auskommentiert

Weiter Details:

Während die Worker pausieren erfolgt durch sie keine Anfragen an die Mutex mehr, ebenso JobQueue_WaitForFinish(), JobQueue_WaitForJob() beantragen beim Warten keinen Mutex Zugriff da alles über Semaphoren getriggert wurde. Der Stack vergößert und verkleinert sich nun Blockweise, wodurch schon ein kleiner Performancegewinn erkennbar wurde. Intern wurden kleine Optimierungen vorgenommen, speziell das neue 3. Expample im Downloadpacket wurde dadurch in der Performace gesteigert, dort balgen sich immerhin 128 Threads um einige Tausend Jobs (~100-110x schneller als seriell). Der MutexLock wurde bei ReadOnly - Zugriffen entfernt, bisher hatte ich damit keine Probleme, sollten doch welche auftreten hab ich ihn sicherheitshalber nur auskommentiert.

Wenn ihr Bugs findet, euch eine bestimmte Funktion wünscht, Kritik oder Verbesserungsvorschläge habt, würde ich mich sehr freuen wenn ihr die hier Posten würdet. Auch interessieren würde mich die Ergebnisse der Demos auf anderen CPU , Single/Dual/Quad/OctaCore, leider hab ich hier nur QuadRechner zum testen. Auch interessant währen Ergebnisse von Intel Xeon und AMD Opteron Prozessoren, da ich das System gerne in Server Software verwenden würde.

@milan1612 & Kiffi:

Danke, fühle mich geehrt. Werde natürlich so weitermachen.

Das größte Lob ist es wenn sich Leute die Mühe machen einen Code zu testen, ihn sich anzusehen und dem Programmierer ihre Ergebnisse und Verbesserungsvorschläge mitteilen. Danke @ freak, das hat mir wirklich sehr geholfen.


Download im 1. Post

[cxAlex]

Update:

• JobQueue_ClearReturnBuffer(): Clear wird nur durchgeführt wenn alle Jobs beendet sind (sonst gefährlich im Zusammenhang mit Child/Parent Objekten)
• JobQueue_CountWorkers(): Anzahl Worker Threads ermitteln
• ReturnBuffer wird nun beim Clearn mit der festgelegten Blockgröße wiederhergestellt
• Mutex - Zugriffe optimiert

im Detail:

Die Mutex Zugriffe wurden nun optimiert, sodas die Worker diese intelligenter einsetzen. Überflüssige Worker, die nichts zu tun haben, greifen überhaupt nicht mehr auf die Mutex zu, was alleine im 3 Beispiel bei 1000 Threads zu einem 1700% igem Performancegewinn führt. Auch die Zeit die ein Worker die Mutex lockt wurde verringert.

Wie immer, Bugs, FeatureRequests, Verbesserungsvorschläge oder Ergebnisse der Democodes bitte hier posten, sonst muss ich noch annehmen das mein Code perfekt ist .

Download im 1. Post oder:

http://www.paladiumx.forgesoft.net/publ ... Thread.zip

[ts-soft]

Wie immer, Bugs, FeatureRequests, Verbesserungsvorschläge oder Ergebnisse der Democodes bitte hier posten, sonst muss ich noch annehmen das mein Code perfekt ist

Gute Arbeit, aber von perfektion noch weit weg

In der Haupdatei sind 3 Variablen nicht deklariert!

Demo2.pb und Demo3.pb stürzen immer ab!

Demo.pb läuft sauber durch, mit 4 Threads ist es 1.71x, mit 2 Thread nur
1.61x schneller, wobei mit 2 Threads bleibt die CPU Auslastung in
aktzeptablen Bereich (100% ist für mich inakzeptabel )

Gruß
Thomas

[cxAlex]

> In der Haupdatei sind 3 Variablen nicht deklariert!
k, ist schnell erledigt...

> Demo2.pb und Demo3.pb stürzen immer ab!
kannst du den Debugger mal einschalten und sagen wo die Abstürzen, bei mir laufen die sauber durch. Kann das wer bestätigen?

> Demo.pb läuft sauber durch, mit 4 Threads ist es 1.71x, mit 2 Thread nur 1.61x schneller, wobei mit 2 Threads bleibt die CPU Auslastung in aktzeptablen Bereich

Klar, du hast nen DualCore, bei dir müssten beim Demo1 2 Jobs zu 2 Threads am schnellsten sein.

>100% ist für mich inakzeptabel

Der Code ist dazu da die CPU voll auszunutzen

[ts-soft]

Der Code ist dazu da die CPU voll auszunutzen

Guck Du mal Simpsons am PC wenn da so ein Democode 100% verbraucht

IMA in Stack_PushF(), Zeile 62, CopyMemory, manchmal auch in
Stack_Free(), Zeile 36, FreeMemory (demo3)

IMA kommt immer (x86, Vista)

[cxAlex]

So, downloade es bitte nochmal, der Fehler sollte behoben sein.
War ne kleine verschiebung beim resizen des Stacks (drum ists bei mir nicht aufgetreten, weil die Jobs so schnell abgearbeitet wurden das der Stack nie resized werden musste )

Geht jetzt alles glatt?

PS: die 3 Variablen hab ich jetzt auch noch deklariert

http://www.paladiumx.forgesoft.net/publ ... Thread.zip

[ts-soft]

> Geht jetzt alles glatt?
Demo2: ca 1,5x
Demo3: ca 100x

Mein Stack muß auch nicht resized werden, wenn mein PC im Hintergrund
schläft, macht er aber nie, der Ackert die ganze Zeit

[cxAlex]

Ah, gut dann wars der Stack. (Ich währ durchgedreht wenns die Mutex gewesen währe, das währ ne Arbeit gewesen den zu finden ).

Wie viele Threads hast du beim 2. Demo aktiviert (4/8/10/16) ?
oder, wie sind die Werte bei den einzelnen Threads? In deinem Fall währen außedem 2 Threads interresant.

[ts-soft]

Ah, gut dann wars der Stack. (Ich währ durchgedreht wenns die Mutex gewesen währe, das währ ne Arbeit gewesen den zu finden ).

Wie viele Threads hast du beim 2. Demo aktiviert (4/8/10/16) ?
oder, wie sind die Werte bei den einzelnen Threads? In deinem Fall währen außedem 2 Threads interresant.

Das was Du vorgegeben hast, im Democode, mit 2 ändert sich nicht viel,
1,56, das kann aber auch andere Gründe haben.