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

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

markieren

Delphi-Quellcode:

Multithreaded := true;
isMultithreaded := true;

Beim FastMM ist es in der Options Include mit drin.

@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)

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?

Zitat von Patrick:

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.

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

Ich hatte mich damals damit abgefunden.

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

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

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