Maximale Threadanzahl / Anzahl der Threads für Programm / Prozeß erhöhbar?

[Delphi-Laie]

Liebe Delphifreunde!

Zur Zeit bastele ich an einem Algorithmus, der aus dem vollen schöpft und Threads in fast beliebiger Anzahl kreiert. Inzwischen läuft er auch so, wie er soll, fehlt nur noch der Feinschliff, so dieses Problem: Windows verweigert bei irgendeiner Threadanzahl die Erstellung weiterer Threads. Folge ist, daß das Programm stehenbleibt. In meinem Windows 7 64 Bit z.B. wird - anscheinend ist das nicht bei jedem Programm gleich - bei 1.000 < x < 1.500 Threads die Neuerstellung weiterer Threads blockiert.

Nun meine Frage: Gibt es irgendeine Möglichkeit (API-Funktion o.a.?), Windows "anzubetteln", daß man die maximale Anzahl dieser Threads für das jeweilige Programm erhöhen kann?

Bitte jetzt keine Hinweise, daß das schlechter Programmierstil sei, das ist mir bekannt. Mir geht es nämlich gerade darum, möglichst viel (scheinbar oder tatsächlich) gleichzeitig ablaufen zu lassen und das auch darzustellen, also lebt eine solche Demonstration geradezu von der Anzahl ihrer Threads. Um das Nähkästchen zu öffnen: Das klassische Mergesort läßt sich parallelisieren, und das möchte ich visualisieren, was mir, wie gesagt, inzwischen gelang.

Vielen Dank und Gruß

Delphi-Laie

[Sir Rufo]

Jeder Thread hat einen Stack und irgendwann ist eben kein Speicher mehr da.

http://blogs.msdn.com/b/oldnewthing/...29/444912.aspx

[Delphi-Laie]

Zitat:

Zitat von Sir Rufo (Beitrag 1280770)

Jeder Thread hat einen Stack und irgendwann ist eben kein Speicher mehr da.

http://blogs.msdn.com/b/oldnewthing/...29/444912.aspx

Das hilft mir schonmal sehr weiter, besten Dank! D.h., wenn man die Stackgröße erhöht, dann hat man auch die Chance, daß mehr Threads gestartet werden können, nicht wahr?

[Delphi-Laie]

So, ich habe selbst erfolgreich herumexperimentiert: Man muß die maximale Stackgröße verringern, dann passen auch mehr Threads in den Prozeß (bildlich gesprochen).

[Medium]

Für genauere Infos zu den internen Abläufen dazu, siehe diesen Blog-Eintrag. Allerdings muss man auch trotz dieser berechenbaren Dinge aufpassen, da die letztendliche Anzahl stark mit davon beeinflusst wird, wie viel Speicher der Elternprozess bereits nutzt, und wie stark dieser fragmentiert ist. Wenn man also nicht 100% weiss was der Delphi MM tut, und dieses voll deterministisch auf den eigenen gesamten Code angewended quatifizieren kann, wird eine harte feste definitive theoretische Zahl mit praktischer Relevanz ziemlich unmöglich.

In einem Stackoverflow-Thread habe ich auch noch die Aussage gefunden (auf 32 Bit Prozesse bezogen):
Zig: Quasi immer möglich
Hunderte: Vermutlich meistens okay, je nach dem
Tausende: Fast nie erfolgreich

Ich denke, mit deinen 1000-1500 bist du schon recht nah an der praktisch möglichen Grenze für den allgemeinen Fall.

[Delphi-Laie]

Danke!

Zitat:

Zitat von Medium (Beitrag 1280810)

Ich denke, mit deinen 1000-1500 bist du schon recht nah an der praktisch möglichen Grenze für den allgemeinen Fall.

Ich weiß nicht, was genau alles auf dem Stack abgelegt wird - Variablen gewiß, aber auch Code? Gerade bei letzterem wäre der Stack viel eher gefüllt.

Für mich ein Grund mehr, den Stack nicht zu mögen, der war mir noch nie sympathisch. Jetzt tut sich sogar noch ein Zielkonflikt auf: Threadanzahl versus Rekursion.

Was schätze ich deshalb stack-, konkreter rekursionsbefreite Algorithmen, nur, in diesem Falle geht es wohl nicht ohne Stack, und diese "Stellschraube" zur Erhöhung der Threadanzahl war mir vorher auch gar nicht bekannt.

[BUG]

Zitat:

Zitat von Delphi-Laie (Beitrag 1280816)

Für mich ein Grund mehr, den Stack nicht zu mögen, der war mir noch nie sympathisch.

Das ist irgendwie schon eine lustige Aussage :mrgreen:
Der Stack ist einfach eine (ziemlich effiziente) Datenstruktur zur Speicherverwaltung.

Zitat:

Zitat von Delphi-Laie (Beitrag 1280816)

Ich weiß nicht, was genau alles auf dem Stack abgelegt wird.

Im Grunde Argumente, Rücksprungadressen und lokale Variablen (+ temporäre Zwischenergebnisse). In der Regel kein Code.

[Medium]

Steht alles in dem verlinkten Artikel.

[Sherlock]

Aussage, die früher oder später hier kommen muss: Was machst du Dir eigentlich Gedanken über die maximal mögliche Thread-Anzahl? Abseits von einem Server, gibt es keine sinnvolle (aka zeitsparende) Anwendung von mehr Threads als CPU-Kernen. Da Du sicherlich nicht der Herr über 1000+ Kerne bist (auf jeden Fall nicht, wenn Du mit Delphi entwickelst), ist das doch allenfalls eine akademische Frage, oder?

Aber falls Du einen wie auch immer gearteten Server entwickelst, solltest Du Dir überlegen eventuell ruhende Verbindungen (=Threads) auszulagern. Dafür gibts sicherlich einen coolen Pattern Namen, der mir aber gerade nicht einfallen will.

Sherlock

[JasonDX]

Hatt ich mir auch gedacht, dann hab ich den letzten Absatz im ersten Post gelesen ;)

Aber was in dem Kontext sicherlich auch spannend wäre: Zeige, wie sich unterschiedliche Threadanzahlen auf das Laufzeitverhalten auswirken. I.e.: Lass die Simulation mal mit 1, 10, 100, 500, 1000 etc. Threads laufen und vergleiche das Ergebnis. Der größte Trugschluss den ich in Konversationen über Parallelisierung gefunden habe ist, dass mehr Threads mehr Geschwindigkeit bedeuten.

Zitat:

Zitat von Sherlock (Beitrag 1280873)

Abseits von einem Server, gibt es keine sinnvolle (aka zeitsparende) Anwendung von mehr Threads als CPU-Kernen.

Doch. Einfachstes Beispiel: Threads brauchen teure IO-Operationen. Während ein Thread auf die Festplatte wartet, kann ein anderer den Kern einnehmen. Das geht natürlich nur, wenn du mehr Threads als Kerne hast :)
Natürlich, es braucht ein gesundes Maß von Threads vs Kernen.

[Delphi-Laie]

Zitat:

Zitat von Sherlock (Beitrag 1280873)

Was machst du Dir eigentlich Gedanken über die maximal mögliche Thread-Anzahl? Abseits von einem Server, gibt es keine sinnvolle (aka zeitsparende) Anwendung von mehr Threads als CPU-Kernen.

Sherlock, dazu äußerte ich mich bereits in meinem Eröffnungsbeitrage. Nicht immer geht es nämlich um (maximale) Geschwindigkeit, sondern manchmal steht die Gleichzeitigkeit ganz oben auf der Wunschliste. In Kürze werde ich den Algorithmus (auch) hier in der Delphipraxis veröffentlichen.

[Sir Rufo]

Dann bin ich mal gespannt, wie du auf einem System mit CPU(kern) <<< Thread-Anzahl die "Gleichzeitigkeit" definierst. Das ist dann sowas wie die Quadratur des Kreises.

[Delphi-Laie]

Zitat:

Zitat von Sir Rufo (Beitrag 1280956)

Dann bin ich mal gespannt, wie du auf einem System mit CPU(kern) <<< Thread-Anzahl die "Gleichzeitigkeit" definierst. Das ist dann sowas wie die Quadratur des Kreises.

Die ist dann natürlich nur gefühlt, fälschlicherweise wahrgenommen. Unsere Sinne und unser Gehirn lassen sich leicht betrügen, was oft sogar nützlich ist. In ein Beispiel schauen wir gerade: Eine ausreichend hohe Flimmerfrequenz wird als kontinuierliches Leuchten wahrgenommen.

[Sir Rufo]

Aus dem Grund wundere ich mich, warum du so viele Threads benötigst, aber lassen wir uns überraschen

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1280956)

Dann bin ich mal gespannt, wie du auf einem System mit CPU(kern) <<< Thread-Anzahl die "Gleichzeitigkeit" definierst.

Nenn es einfach "Nebenläufigkeit", dann dann bist du fein raus :mrgreen:

[Daniel]

Naja, es ist ein akademisches Beispiel und man wird vermutlich sehr schön sehen können, wie sich die Threads gegenseitig auf den Füßen herumstehen.

[Delphi-Laie]

Zitat:

Zitat von Daniel (Beitrag 1281024)

Naja, es ist ein akademisches Beispiel und man wird vermutlich sehr schön sehen können, wie sich die Threads gegenseitig auf den Füßen herumstehen.

Nur bei einem Prozessor(kern)!

So, es ist vollbracht, nochmals besten Dank an alle für die Hilfe und Geduld!

Mein Sortieranimationsprogramm enthält nunmehr den zweiten parallelisierten Sortieralgorithmus, eben Mergesort. Der Unterschied in der Arbeitsweise zum einfachen Mergesort ist deutlich erkennbar - und genau darauf kam es mir an. Natürlich hätte ich auch mit einem Threadpool arbeiten können, doch das wäre viel komplizierter geworden, dem hätte ich mich nicht gewachsen gefühlt. Natürlich hätte ich auch nur mit 2 Threads arbeiten können, die je die beiden Teilmengen parallel mit dem klassischen Mergesort sortieren, und danach wird final verschmolzen, doch dann wäre die Multithreading-Arbeitsweise nicht so deutlich geworden, wenn, dann schon richtig.

Bitte auch auf mein letztes Edit dort achten.

Erstaunlicherweise läuft dieser Algorithmus bei mehr als 2 Prozessoren bzw. Prozessorkernen nicht nennenswert schneller, also scheint dann schon die Ausgabe "der Flaschenhals" zu sein.

[Daniel]

Zitat:

Zitat von Delphi-Laie (Beitrag 1281048)

Erstaunlicherweise läuft dieser Algorithmus bei mehr als 2 Prozessoren bzw. Prozessorkernen nicht nennenswert schneller, also scheint dann schon die Ausgabe "der Flaschenhals" zu sein.

Wenn man es - wie Du in diesem Fall - darauf anlegt, möglichst viele Threads zu erzeugen, ist das in meinen Augen auch kein Wunder. Du stresst Dein Betriebssystem ganz erheblich, zwischen all den Threads umzuschalten. Bei dieser Anzahl an Threads dürfte der Verwaltungsaufwand höher sein als die produktive Arbeit, die von den Threads verrichtet wird.
Ich finde das Beispiel durchaus spannend - aber nicht, um die Performance eines Algorithmus zu ermitteln - diese Messung machst Du durch die große Anzahl an Threads zunichte.

[himitsu]

Wenn eine Funktion mit 100%-CPU-Leistung der Kerne laufen soll, dann nimmt man eben nur so viele Threads, wie es (arbeitslose) Kerne gibt.
Bei mehr wird, in der Regel, der Verwaltungsaufwand immer mehr Rechenleistung auffressen, zzgl. der Synchronisation usw.

Wenn die Threads fast nichts zu rechnen haben, oder eben auch nacheinander ausgeführt werden können, dann wäre ein Thread-Pool oder Fiber eine Alternative, mit einer aktiven Threadanzahl entsprechend der Kerne.


Es sind sogar Leute auf die kranke Idee gekommen Dateioperationen in Threads laufen zu lassen (siehe Microsoft Suche), wo der Flaschenhalt der Datenträger ist, also 1 Thread pro Festplatte. :roll:
Dort merkt man das sogar noch krasser (bei mechanischen HDDs), daß sich mehrere Threads gegenseitig bremsen und es mit mehr Threads immer langsamer wird.
Theoretisch kann man es auch mit Threads machen, aber nur wenn im Thread auch noch was Anderes gemacht, welches die meiste Zeit beansprucht, wie z.B. eine Verarbeitung der Dateidaten.

[OlafSt]

Mit anderen Worten: Threads gibt es nicht umsonst.

Jedes Umschalten des Threads kostet Rechenzeit, weil innerhalb der CPU massenhaft Register ausgetauscht werden müssen (das sind BEI WEITEM nicht nur EAX, EBX und Konsorten !). So ein Umschalten, Kontextwechsel genannt, frißt so an die 1000-2000 Takte.

Bastelt man auf einem Quadcore nun 4 Threads, läuft auf jedem Core ein Thread. Die Anzahl der Kontextwechsel ist gleich null. Erstellt man 8 Threads, bürdet man jedem Kern 2000 Extra-Takte für einen Kontextwechsel auf. Und erstellt man 12000 Threads, dann eben 12000/4 = 3000 * 2000 = 6Mio. Takte NUR für Kontextwechsel.

Dir wird auffallen, das die verwaltung all dieser Threads und das Umschalten zwischen diesen irgendwann mehr Zeit verbraucht, als du durch die Threads einsparst. Als Faustregel kann man sagen: Jeder Thread > ANZ_CORES bringt nur noch 80% Gewinn.

Auf Singlecore-Maschinen also:

- 1 Thread = 1
- 2 Thread = 1 + 0.8 = 1.8 (und nicht 2.0)
- 3 Thread = 1 + 0.8 + 0.64 = 2.44 (und nicht 3.0)

usw.

[JasonDX]

Zitat:

Zitat von Delphi-Laie (Beitrag 1281048)

Erstaunlicherweise läuft dieser Algorithmus bei mehr als 2 Prozessoren bzw. Prozessorkernen nicht nennenswert schneller, also scheint dann schon die Ausgabe "der Flaschenhals" zu sein.

Das ist genau das, was dir Leute versucht haben, mitzuteilen: Ab einem gewissen Punkt bringen mehr Threads nix mehr. Das hat höchstwahrscheinlich nix mit "Ausgabe" zu tun. Das kannst du auch gut nachprüfen: Schalt einfach temporär die Ausgabe aus.
Falls du ein bisschen was über Parallelisierung lernen willst: Füg einen Parameter ein mit dem du steuern kannst, wieviele Threads die Sortierung bearbeiten, und beobachte die Auswirkungen ;)

[Delphi-Laie]

Leute, noch einmal: Ich wollte nicht zeigen, daß sich der Algorithmus durch Multithreadverwendung beschleunigen läßt - ein solches Ziel wäre hiermit auch widerlegt, wenn auch nicht grundsätzlich, sondern nur eben auf meinem Wege - sondern, daß er sich parallelisieren läßt, und das sogar ganz massiv. Und das bezeichne ich als gelungen.

Die Geschwindigkeitsmessung ist ohnehin ohne allzugroße Aussgakraft, ich implementierte sie auf Wunsch eines einzelnen und weil der Aufwand dafür überschaubar war.

Im "nackten" Windows, also dem frischen Installationszustand ohne zusätzlich gestartete Anwendungsprogramme, sind bereits hunderte Threads gestartet. Wieviele sind davon mehr oder weniger, d.h., wenigstens sporadisch aktiv? Vermutlich eine ganze Menge. Auch, wenn es nur ein winziger Teil der Gesamtanzahl ist, so sind es doch mit Sicherheit deutlich mehr als die Anzahl der Prozessoren / Prozessorkerne. Also gehört das ständige Umschalten zwischen einzelnen Threads auch ohne meinen "Quälalgorithmus" zu einer häufigen Aufgabe des Betriebsprogrammes.

Schon beim parallelen Quicksort versuchte ich, die Anzahl der Threads zu begrenzen, was mir aber nicht gelang. Vielleicht wage ich mich noch einmal daran, auch beim hier thematisierten Mergesort.

[hathor]

Ich habe jetzt nicht alles gelesen, aber diese Info habe ich vermisst:

64‑bit versions of WINDOWS can support up to 256 processor cores.


Es macht also nicht viel Sinn, mehr Threads zu starten, als VIRTUELLE CORES (Beispiel: i7-3610: Anzahl der Kerne: 4, Anzahl der Threads: 8) vorhanden sind.

[Sir Rufo]

Zitat:

Zitat von hathor (Beitrag 1281075)

Ich habe jetzt nicht alles gelesen, aber diese Info habe ich vermisst:

64‑bit versions of WINDOWS can support up to 256 processor cores.


Es macht also nicht viel Sinn, mehr Threads zu starten, als VIRTUELLE CORES (Beispiel: i7-3610: Anzahl der Kerne: 4, Anzahl der Threads: 8) vorhanden sind.

Ähm, nicht ganz: Es macht nicht viel Sinn mehr Threads mit Last zu starten als Cores vorhanden sind. Wartende Threads kannst du nach Belieben (bis der Speicher kneift) erstellen, die werden den Rechner nicht stressen.