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?