Multithreading
-
ten schrieb:
byto schrieb:
Laut Bruce Eckel (Autor von Thinking in C++ & Thinking in Java) bringt Multithreading praktisch häufig auch auf 1-Prozessor-Systemen leicht bessere Performance.
ich würde eher sagen leicht schlechtere.
das task switching selber verbrät ja auch rechenleistung.
beste performance hat man, wenn die cpu ungehindert rennen kann, ohne interrupts usw...
kommt wohl drauf an, ob man vorher ein Rechner hatte auf dem das Ding exklusiv lief oder ein Rechner hatte, auf dem eh schon ein Betriebssystem war, vielleicht sogar eines, was ständig GUI und N andere Programme laufen lässt
Aber Threading bietet eben den Vorteil, das die Anwendung besser skaliert, wenn man weitere Rechner oder CPUs hinzufügt.
-
Aber Threading bietet eben den Vorteil, das die Anwendung besser skaliert, wenn man weitere Rechner oder CPUs hinzufügt.
Das kommt, wie schon hier gesagt, auf den Algorithmus an. Devide&Conquer-Algos profitieren am meisten von MT, aber andere, in denen ein Ergebnis auf einen anderen aufbaut profitieren überhaupt nicht davon.
-
DEvent schrieb:
Aber Threading bietet eben den Vorteil, das die Anwendung besser skaliert, wenn man weitere Rechner oder CPUs hinzufügt.
Das kommt, wie schon hier gesagt, auf den Algorithmus an. Devide&Conquer-Algos profitieren am meisten von MT, aber andere, in denen ein Ergebnis auf einen anderen aufbaut profitieren überhaupt nicht davon.
Das ein Algorithmus den man nicht in mehrere Threads aufteilen kann von Threads nicht profitiert, dürfte ja selbst redend sein...
-
Apollon schrieb:
Und AFAIK ist ++i atomar, i++ ist es nicht.
Das ist wohl egal. Entscheidend ist wohl eher, ob i in nem register steht oder nicht. Wenn du eine einfache for schleife hast, wird der assembler code wohl immer
inc cxsein, egal ob du i++ oder ++i schreibst. Wenn die Schleife komplizierter ist und auch mal was anderes als i in cx steht, so das i von speicher gelesen werden muss, dann ist es nicht mehr atomar
-
Hm was mich mal interessieren würde:
Gehen wir mal von folgender Situation aus 2 Bitmaps (800x600) die ineinander geblendet werden sollen. Währe ja ein einfach realisierbares Multithreading Szenario.
Ab wann lohnt sich Multithreading (Ist eventuell die benötigte Zeit um die Threads starten zu lassen höher als es in einem zu Berechnen). Bzw sollte man die Thread dauerhaft laufen lassen und ihnen ihre Aufgaben zu kommen lassen.
Wie bestimmt man wieviel Threads sich lohnen für eine Rechenoperation mit 800x600 Schleifendurchläufen. Also das von Multi Threading profitiert wird und nicht der Verwaltungsaufwand zu groß wird. (Hängt wahrscheinlich auch von Anzahl CPUs ab also muss die ja auch mit einbezogen werden)
mfg
-
Mit dem Satz "Hängt wahrscheinlich auch von Anzahl CPUs ab also muss die ja auch mit einbezogen werden" wäre ich vorsichtig. Bei gängigen Betriebssystemen bekommt nur dein Prozess die Rechenzeit zugeteilt und dieser verteilt diese wiederum an die entsprechenden Threads. Es gibt aber auch Betriebsysteme (z.B. irgendwelche Serverbetriebssysteme) die "schwergewichtige Threads" (die genaue Bezeichnung weis ich jetzt nicht mehr) unterstützen und den einzelnen Threads direkt Prozessorzeit zuweisen.
Ich bin allerdings erst dabei mich in die Materie einzuarbeiten. Darum kanns sein das mein Post nicht 100%ig vollständig ist (man möge mich berichtigen
).
-
Ja das ist ja sowieso klar aber wenn man zu tun hat bekommt man auch Rechenzeit vom OS und das gibt normal über alle Prozessoren. In Windows kann der User im Task Manager dann einschränken.
Die Linuxer sind ja die die schweren Threads (eher Prozesse) nutzen mit ihrem fork Befehl, da sieht man selten das die pthreads einsetzen. Und ich denkmal bei den schweren Prozessen ist der Aufwand jedenfals höher.
Die Frage ist eher wie schätzt man sinnvoll für einen bestimmten algorithmus mit einer bestimmten prozessoranzahl wie groß die optimale threadanzahl ist ohne performance tests auszuführen. Vieleicht gehts ja auch nur ueber Erfahrung/Schätzung, aber es währe doch toll wenns da eine Formel für gäbe und zur Laufzeit bestimmt wird wieviele Threads angebracht währen.
-
Also die gesuchte Formel lautet:
T=CUnter der Annahme, daß C die Anzahl Cores ist und T die optimale Anzahl von Threads. Teile also so viele Aufgaben aus, wie Du Ausführungseinheiten hast.
Wie bereits erwähnt gilt das allerdings nur, wenn die Threads wirklich ungehindert arbeiten können. Sobald ein Thread auf I/O wartet, ist es besser, man hat einen wartenden Thread, der die CPU dann beschäftigen kann.
Als Linux-Programmierer muß ich auch noch ein Wort zu DaRpH sagen: Wie kommst Du darauf, daß die Linuxer fork zur Performancesteigerung nutzen? Also ich nutze ausschliesslich Threads zu diesem Zweck.
Tntnet
-
Weil ichs zu oft seh
bzw nutzenses zur einfachen parallelisierung von Performancesteigerung hab ich nix gesagt.Naja egal war ja nur ein Beispiel, nicht gleich angegriffen fühlen.
-
Leute, hier liegt wohl ein grosses grosses Misverständnis vor.
Weder "i++" noch "++i" sind atomar.
Read-modify-write ist auf einem x86 System immer teilbar, es sei denn man verwendet einen "interlocked" Befehl, ala InterlockedCompareExchange oder InterlockedExchangeAdd etc.
-
DaRpH schrieb:
Die Linuxer sind ja die die schweren Threads (eher Prozesse) nutzen mit ihrem fork Befehl, da sieht man selten das die pthreads einsetzen. Und ich denkmal bei den schweren Prozessen ist der Aufwand jedenfals höher.
Wie teuer nun ein Thread ist und ob sicher der Overhead lohnt, hängt immer von den verwendeten Threads und des Betriebssystem ab. Erlang zB (eine Programmiersprache, die auf (Buzzwordalarm) "Concurrent Programming" ausgelegt ist), benutzt User-Level-Threads, die im Grunde nichts kosten. Auch Linux erzeugt sehr schnell Prozesse und Threads. Bei Kernel-Threads hat man aber in der Regel einen großen Speicher-Overhead (idr. eine Page)
-
rüdiger schrieb:
...Erlang zB (eine Programmiersprache, die auf (Buzzwordalarm) "Concurrent Programming" ausgelegt ist), benutzt User-Level-Threads, die im Grunde nichts kosten.
werden wohl ähnlich funzen wie das hier: http://www.sics.se/~adam/pt/
