Threads arbeiten nur auf einem Kern

[Patrick]

Hallo,

Ich habe es jetzt endlich geschafft meinen Code mit Threads zu parallelisieren, da taucht das nächste Problem auf:

Meine zwei erzeugten Threads arbeiten nur auf einem CPU-Kern anstatt alle zu verwenden. Ich arbeite nicht (oder nur sehr wenig) mit Synchonize. Die Threads sind ansonsten identisch und die Execute Funktion bearbeitet ne Menge unterschiedlicher Operationen (erzeugen und zerstören von Objekten, schleifen, String Operationen, usw... da ist alles dabei).
Tausche ich die Execute durch eine Schleife, die einfach einen Integer hoch zählt, funktioniert es hingegen und jeder Thread lastet einen Kern voll aus. Meine Frage ist: Warum? Und was kann ich dagegen machen?

Ich habe diesen Beitrag gefunden, bin aber nicht sicher, ob das mit meinem Problem zu verglichen ist.

[Cylence]

Hi,

ich lege die threads selbst auf andere Kerne, das geht so:


if JvComputerInfoEx1.CPU.ProcessorCount > 1 then
SetThreadAffinityMask(ThreadEx1.Handle,2);

[Patrick]

Das bewirkt lediglich, dass zwei Kerne jeweils zur Hälfte ausgelastet sind. Sie laufen immer noch nicht "echt" parallel.

[jfheins]

Gibt es vielleicht andere, ressourcen, die nur exklzusiv benutzt werden können?

Poste mal den Code der Execute Methode...

[himitsu]

Der Speichermanager Synchronisiert auch noch einiges ... kann sein, daß (wenn du sehr viele Speicheranfragen/-freigaben hast, im Verhältnis zum restlichen Code) da auch mehr in ein Thread reinsynchronisiert wird.
(der kann halt auch nicht alles paralell machen, wenn er eine gemeinsame Speicherverwaltung nutzt)


Wann wurde nochmal FastMM in Delphi integriert?
(bin mir nicht sicher, ob dieses erst ab Delphi 2006 drinnen ist)


Der alte Delphi-Speichermanager konnte immer nur einen Thread geichzeitig bediehnen.
Bei mehreren gleichzeitigen Anfragen, mußten andere warten.


FastMM versucht (ich glaub 3 Thread) gleichzeitig innerhalb verschiedenster Speichergrößen zu unterstützen, bei einer Speicheranfrage (also eine 10 Byte-Anfrage und Eine nach 10.000 Byte werden sich nicht behindern).
Ist ein Speicherblock grade blockiert, dann versucht er sofort den Nächsten und wenn Dieser es auch ist, dann noch eines weiter.
Ist alles blockiert, dann muß ebenfalls gewartet werden.

ABER, bei Speicherfreigaben und bei Reallocierungen muß er genau auf einen bestimmten Block zugreifen und das kann nur für einen einzigen Thread gleichzeitig bewerkstelligt werden.

[Patrick]

Das dürfte schwierig werden. Der Code erstreckt sich bestimmt über 10 verschiedene Klassen. Und mein Chef würde es, denke ich, nicht gerne sehen, wenn ich den Code hier einfach poste:wink:
Nenn doch bitte mal ein paar Beispiele für Ressourcen. Also Hardware-Ressourcen benutze ich da keine. Die meißte Zeit rechnet da der Interpreter.
Das interessante ist ja, dass er keinen deut über einen Kern hinaus kommt. Würde ich irgendwo eine exklusive Ressource verwenden könnte er ja wenigstens den Rest des Codes parallel abarbeiten und wäre so etwas über der Kapazität von einem Kern, was er aber nicht ist.

Ich verwende Delphi 2010, da ist FastMM drinn.

"Speicher" ist eine exklusive Ressource, aber ich mache teilweise auch einfach nur Berechnungen, die keinen Speicher allozieren.

[blackfin]

Auf welche Priorität sind denn die Threads gesetzt?
Ich habe die vage Vermutung, dass das gar nicht mal an Delphi liegt, sondern an Windows selbst.
Gibt es einen Unterschied und der Auslastungs-Verteilung, wenn du den Threads z.B. tpHigher oder tpHighest gibst?

Vielleicht hilft auch gfolgender Artikel:
http://hothardware.com/News/True-Mul...indows-Rework/

Interessant ist vielleicht auch folgender Artikel über FastMM, der vielleicht genau in diese Kategorie fällt?:
http://zachsaw.blogspot.com/2010/01/...d-apps-on.html

Zumindest folgende Kommentare daraus könnte vielleicht nützlich sein:

Zitat:

Notice that when you run the FastMM Test with CPU Affinity set to just one CPU, you'll end up with nearly the same performance as TBBMM. Once you enable multicores though, you'd immediately lose performance once again, running slower than with just one core.

Zitat:

There is a "bug" in the fastmm, floating around the internet.
This bug causes fastmm to call Sleep, when there are a contentions on Free. Try to set the "NeverSleepOnThreadContention" option and compile. You wil see this baby fly :-)

[generic]

Gab es nicht in Delphi *und* im FastMM eine Einstellung wie

Delphi-Quellcode:

Multithreaded := true;
isMultithreaded := true;

Beim FastMM ist es in der Options Include mit drin.

[himitsu]

@generic: Wenn man mit TThread einen Thread erstellt, dann wird diese Variable automatisch auf True gestellt.
(die WinAPI wie CreateThread macht sowas natürlich nicht, da es diese Delphi-Variable nicht kennen kann)

[Patrick]

Leider hatte weder IsMultiThread noch NeverSleepOnThreadContention einen Effekt.

Da die CPU Auslastung auf genau 50% (also ein Kern voll ausgelastet) verweilt, wenn die Threads laufen, glaube ich auch nicht, dass es daran liegt, dass FastMM langsam ist.

Hat noch jemand eine Idee?

[himitsu]

Zitat:

Zitat von Patrick (Beitrag 1033113)

Hat noch jemand eine Idee?

Da die Gesamtleistung ja (wie schon richtig erkannt) maximal 100% einer CPU ergibt, wird wohl irgendwo etwas sein müssen, welches immer nur einen Thread am laufen läßt.

Aber ohne genauere Erkenntnis über das Innere deiner Threads, können wir auch nicht weiterhelfen.
Du mußt ja auch "nur" rausfinden, welcher Code bei dir dafür verantwortlich ist.

[generic]

Ihr belebt hier übrigens diesen Beitrag von 2004 neu:
http://www.delphipraxis.net/48397-tt...maschinen.html

Ich hatte mich damals damit abgefunden.

[himitsu]

Was Anderes ...
sind bei dir eigentlich alles "echte" Kerne oder ist das nur so'ne Intel-Spar-CPU mit virtuellen Kernen?

[Patrick]

@generic
Hast du auch FastMM als MemoryManager gehabt?

@himitsu
Ich habe eine solide AMD 2-Kern CPU :wink:

[generic]

Bei mir waren es 4 phys. CPUs, dass Hyperthreading gab es damals noch nicht.
Bei dem Projekt glaube ich nicht, dass ich den FastMM genutzt.
Delphi 6 oder 7 war das damals.

[shmia]

Und wie oft wird in den Threads die Synchronize-Methode ausgerufen?
Jede Methode, die über Synchronize aufgerufen wird läuft im Kontext des Hauptthreads.

[igel457]

Ich kann dieses Verhalten weder mit Lazarus noch mit Turbo Delphi 2006 (mit FastMM) nachstellen. Dabei verwenden meine Threads durchaus relativ häufig ReallocMem und Konsorten. Trotzdem gelingt es mir meine beiden CPU-Kerne voll auszulasten.

Meiner Vermutung ist auch eher, dass hier ein konzeptuelles Problem bei der Threadverwendung vorliegt (Threads blockieren sich gegenseitig/benötigen Ergebnisse des jeweils anderen/verwenden Synchronize). Meine Erfahrung mit Multithreading war, dass ich meine ersten Gehversuche damit mittlerweile auch komplett entsorgen konnte. IMHO liegt zu 90% ein Fehler in der Planung vor, wenn man irgendwo überhaupt die Synchronize-Funktion verwenden muss oder zu viele Bereiche mit Mutices oder CriticalSections schützen muss.

Ohne entsprechenden Beispielcode kann ich jedoch natürlich nur Raten was ein Problem sein könnte. Eventuell ist ja auch eine verwendete Komponente für das Verhalten verantwortlich, da sie selbst den gemeinsamen Zugriff auf eine eigene Resource synchronisiert und somit deine Threads ausbremst.

Andreas

[generic]

Also ich habe das jetzt mal ausprobiert. Es hat mir keine Ruhe gelassen.
Delphi 2007 mit FastMM4

alles gut