Multithreading

[byto]

rapso schrieb:

byto schrieb:

;fricky schrieb:

bei single-core systemen bringts geschwindigkeitsmässig sowieso nix

Das ist falsch, denn es gibt auch noch Sachen wie I/O, wodurch auch ein Kern mal nichts zu tun hat.

das war richtig, auf applikationsseite bringen mehrere threads in dem fall nichts, denn jedes OS kuemmert sich schon mit threads um die sache.

Klar kümmert sich das OS darum. Ändert trotzdem nichts, dass der Worker-Thread Deiner Applikation u.U. blockiert, bis der I/O Vorgang beendet ist. Lässt Du also einen zweiten Thread laufen, kannst Du den entstandenen Leerlauf sinnvoll nutzen.
Der Overhead des OS-Schedulers bei einem Thread mehr oder weniger ist im Übrigen verschwindend gering.

Anderes Beispiel wären GUI Applikationen. Hier stehts wohl ausser Frage, dass man auch bei einem Kern Multithreading benötigt.

[;fricky]

hustbaer schrieb:

ganz ohne multithreading/multitasking müsste man auf die platte warten.

auch ohne multitasking kann man die wartezeit nutzen, um was anderes zu machen. das ist nur etwas aufwendiger (schrieb ich ja bereits).

Anderes Beispiel wären GUI Applikationen. Hier stehts wohl ausser Frage, dass man auch bei einem Kern Multithreading benötigt.

nö, bei den ollen windosen, win 3.11 und so, gings auch ohne.

[byto]

Manche geben auch einfach zu, wenn sie unrecht hatten. Denn das lässt sie auf Dauer nicht immer unglaubwürdiger erscheinen. Aber wahrscheinlich ist es bei Dir auch schon längst zu spät dafür.

[volkard]

;fricky weiß es nicht schrieb:

Anderes Beispiel wären GUI Applikationen. Hier stehts wohl ausser Frage, dass man auch bei einem Kern Multithreading benötigt.

nö, bei den ollen windosen, win 3.11 und so, gings auch ohne.

Win 3.11 hatte doch Multithreading.
Du verwechselst das in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.

[;fricky]

volkard schrieb:

Win 3.11 hatte doch Multithreading.
Du verwechselst das in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.

nee, win 3.11 lief unter DOS ohne threading u.ä. das fensterlesystem kam völlig ohne aus (wie übrigens auch heute noch). der unterschied war: wenn eine anwendung hing, hingen alle. heute läuft jede windosen-anwendung als separater thread und wenn eine in eine längliche schleife gerät, sind die anderen trotzdem noch bedienbar.

[byto]

;fricky schrieb:

heute läuft jede windosen-anwendung als separater thread und wenn eine in eine längliche schleife gerät, sind die anderen trotzdem noch bedienbar.

Die Anwendung selbst wäre aber halt nicht mehr bedienbar, wenn die lange Operation im selben Thread laufen würde wie der Event Dispatcher der GUI. Von daher brauchst Du bei GUI Anwendungen immer Multithreading, egal ob ein oder mehrere Kerne.

[volkard]

;fricky schrieb:

volkard schrieb:

Win 3.11 hatte doch Multithreading.
Du verwechselst das in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.

nee, win 3.11 lief unter DOS ohne threading u.ä. das fensterlesystem kam völlig ohne aus (wie übrigens auch heute noch). der unterschied war: wenn eine anwendung hing, hingen alle. heute läuft jede windosen-anwendung als separater thread und wenn eine in eine längliche schleife gerät, sind die anderen trotzdem noch bedienbar.

Du verwechselst Threads in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.
http://de.wikipedia.org/wiki/Thread_(Informatik)
Schau dort bei Windows 3.1

[;fricky]

volkard schrieb:

Du verwechselst Threads in deinem jugendlichen Leichtsinn vielleicht mit preemtiven Multitasking.
http://de.wikipedia.org/wiki/Thread_(Informatik)
Schau dort bei Windows 3.1

ja, stimmt, diese manuelle umschaltung hab' ich dabei ganz unterschlagen.

Die Anwendung selbst wäre aber halt nicht mehr bedienbar, wenn die lange Operation im selben Thread laufen würde wie der Event Dispatcher der GUI. Von daher brauchst Du bei GUI Anwendungen immer Multithreading, egal ob ein oder mehrere Kerne.

oder du siehst zu, dass du keine langen operationen hast, bzw. bei 'user threads' musste innerhalb von langen operationen die 'switch_to_another_thread()' funktion aufrufen, damit's nicht hängt.

[byto]

;fricky schrieb:

oder du siehst zu, dass du keine langen operationen hast

Das lässt sich in nicht-trivialen Anwendungen ja auch so gut verhindern.

bzw. bei 'user threads' musste innerhalb von langen operationen die 'switch_to_another_thread()' funktion aufrufen, damit's nicht hängt.

Läuft die Operation in einem eigenen (User-) Thread, dann ist ja alles gut.
Keine Ahnung, was der zweite Teil des Satzes bedeuten soll.

[;fricky]

byto schrieb:

;fricky schrieb:

oder du siehst zu, dass du keine langen operationen hast

Das lässt sich in nicht-trivialen Anwendungen ja auch so gut verhindern.

naja, dazu musste längere operationen zeitlich zerbröseln. das geht schon, ist aber unbequem. deshalb lasset und danken, dass heutige betriebssysteme dem programmierer multitasking/threading anbieten. dadurch wird's zwar ein wenig langsamer (was meisten sowieso egal ist), aber dafür ist vieles bequemer.

Keine Ahnung, was der zweite Teil des Satzes bedeuten soll.

schau hier: http://de.wikipedia.org/wiki/User_Thread
(unter scheduling).

[byto]

OK, die Operation müsste demnach in nem Kernel Thread laufen statt in nem User Thread. mir war der Unterschied - ehrlich gesagt - entfallen. Das Infostudium liegt einfach zu lange zurück und da ich seit Jahren nur noch Java entwickel, ist das ganze praktisch irrelevant, denn Java-Threads werden von der JVM auf Kernel Threads gemappt.

[rapso]

byto schrieb:

rapso schrieb:

byto schrieb:

;fricky schrieb:

bei single-core systemen bringts geschwindigkeitsmässig sowieso nix

Das ist falsch, denn es gibt auch noch Sachen wie I/O, wodurch auch ein Kern mal nichts zu tun hat.

das war richtig, auf applikationsseite bringen mehrere threads in dem fall nichts, denn jedes OS kuemmert sich schon mit threads um die sache.

Klar kümmert sich das OS darum. Ändert trotzdem nichts, dass der Worker-Thread Deiner Applikation u.U. blockiert, bis der I/O Vorgang beendet ist.

sorry, aber wieso sollte man das machen? es waere doch dumm mehr aus dem I/O zu schoepfen als moeglich ist.
in dem fall haettest du natuerlich recht. du kannst auch einen thread machen der auf vsync wartet um zur richtigen zeit die zeichen auf dem bildschirm zu bringen. Einen thread der auf user keyboard-input wartet. doch das ist reine faulheit und hat nichts performancemaessiges gebracht, es kommen lediglich die kosten vom OS hinzu die threads zu verwalten, die threadsafe datenkapselung und die zusaetzlichen buffer hinzu. denn genauso gut kann der buffer deines extra threads ueberlaufen mit dem dein hauptthread kommuniziert und dann hast du nichts gewonnen, nur die folgen verschoben.

Lässt Du also einen zweiten Thread laufen, kannst Du den entstandenen Leerlauf sinnvoll nutzen.

wenn du was zu tun hast, hast du keinen leerlauf.

schau dir einfach an wie nutzlos ein extra thread ist.

ohne thread: (die eckigen klammern sollen den OS bereich representieren)

[hardware <--OS/driver-thread/interrupt--> buffer/cache] <--APP--> variablen@application

mit thread

[hardware <--OS/driver-thread/interrupt--> buffer/cache] <--I/O-thread--> buffer/cache <--memcpy/bufferswap-APP--> variablen@application

wenn das zweite schneller/besser waere auf einem singlecore system, dann waere es doch ratsam noch mehr thread zu generieren:

[hardware <--OS/driver-thread/interrupt--> buffer/cache] <--I/O-thread0--> buffer/cache <--I/O-thread1--> buffer/cache <--memcpy/bufferswap-APP--> variablen@application

sicher sagst du jetzt "das ist doch bloedsinn", ja, weil du sehr offensichtlich siehst, dass der gewinn nicht durch mehr threads entstehen kann, bestennfalls durch mehr buffer, aber du siehst hoffentlich auch, dass genau diese im OS schon vorhanden sind. du kannst, wenn es dir drauf ankommt, den fuellstand abfragen und nur dann schreiben/lesen, denn ganau das selbe wuerde dein hauptthread auch machen wenn er die daten aus dem "I/O-thread" nutzen will, denn ansonsten wuerdest du genau den selben buffer over bzw underflow haben.

Der Overhead des OS-Schedulers bei einem Thread mehr oder weniger ist im Übrigen verschwindend gering.

das problem ist nicht wieviel man damit verliert, sondern dass man auf jeden fall damit verliert und nie performance gewinnt. es ist einfach nur ein thread der daten kopiert.

Anderes Beispiel wären GUI Applikationen. Hier stehts wohl ausser Frage, dass man auch bei einem Kern Multithreading benötigt.

wenn man es nicht anders hinbekommt responsibilitaet zu haben, kann man das machen, wuerde ich auch.
das wird aber nicht performanter laufen und steht in keinem kontext zu dem was ich sagte, denn das gequotete war "...geschwindigkeitsmässig...".

Der irrglaube mit I/O threads stammt aus zeiten als ein OS keine caches und oft keine threads hatte. wenn man sound abspielen wollte, oder von der festplatte lud oder uebers modem daten empfing, dann war man grundsaetzlich immer geblockt, es gab schlichtweg keinen ausreichenden puffer dazwischen, oft nur ein paar byte(z.b. maus input) bis wenige kb (z.b. beim sound), weil man eben direkt auf die hardware zugriff.
In dem falle musstest du einen "thread" oder eher interrupthandler( hiess TSR, terminate but stay resistant, unter dos) implementieren, es war oft garnicht anders moeglich, denn ansonsten gingen die daten sogar verloren weil das OS keinen handler dafuer hatte.
aber genau das macht heutzutage ein OS bzw die treiber, und zwar weit aus effektiver.

deswegen macht ein extra thread auf applikationsseite keinen sinn wenn man damit auf einem single-core system performance erhalten will.
arbeitest du auf nem embeded system, kann das sehr wohl einen sinn machen.

[;fricky]

rapso schrieb:

deswegen macht ein extra thread auf applikationsseite keinen sinn wenn man damit auf einem single-core system performance erhalten will.
arbeitest du auf nem embeded system, kann das sehr wohl einen sinn machen.

auch nicht. pro zeiteinheit kann 'ne CPU nur soundsoviele befehle ausführen. mit multithreading auf nur einer CPU ist gewinnt man luxus für programmierer (dass die schöne schleifen coden können), aber niemals geschwindigkeit.

[zusammenfassung]

hier gibts ne ganze menge klugscheißer und erbsenzähler

[;fricky]

zusammenfassung schrieb:

hier gibts ne ganze menge klugscheißer und erbsenzähler

muss manchmal sein und manchmal auch nicht. hauptsache, wir haben alle spass dabei.

[ownpwnd]

byto schrieb:

Manche geben auch einfach zu, wenn sie unrecht hatten.

Die, die meinen, dass man für GUIs Multithreading braucht?

[Grohool]

;fricky schrieb:

rapso schrieb:

deswegen macht ein extra thread auf applikationsseite keinen sinn wenn man damit auf einem single-core system performance erhalten will.
arbeitest du auf nem embeded system, kann das sehr wohl einen sinn machen.

auch nicht. pro zeiteinheit kann 'ne CPU nur soundsoviele befehle ausführen. mit multithreading auf nur einer CPU ist gewinnt man luxus für programmierer (dass die schöne schleifen coden können), aber niemals geschwindigkeit.

Eine CPU wird durch einen thread aber in der Regel nicht voll ausgelastet, z.B. wenn daten aus dem Arbeitsspeicher geladen werden müssen muss der Prozessor warten. Manche Prozessoren können in so einem Fall dann mit einem zweiten thread die Wartezeit überbrücken.

[hustbaer]

;fricky schrieb:

hustbaer schrieb:

ganz ohne multithreading/multitasking müsste man auf die platte warten.

auch ohne multitasking kann man die wartezeit nutzen, um was anderes zu machen. das ist nur etwas aufwendiger (schrieb ich ja bereits).

nein fricky. wie nennt man es noch schnell im englischen wenn man mehrere dinge gleichzeitig macht? hmmm....
achja: multitasking

du ziehst hier vollkommen willkürlich eine grenze, die da IMO nicht hingehört.

[;fricky]

Grohool schrieb:

Eine CPU wird durch einen thread aber in der Regel nicht voll ausgelastet, z.B. wenn daten aus dem Arbeitsspeicher geladen werden müssen muss der Prozessor warten. Manche Prozessoren können in so einem Fall dann mit einem zweiten thread die Wartezeit überbrücken.

ok, ein gut gemachtes multitasking-system bringt die CPU in einen stromsparmodus, wenn kein thread was zu tun hat. ich hab' z.b. den 'TNKernel' (auf meinem LPC23XX-system) dahingehend erweitert, dass er keine low-priority 'idle-loop' durchläuft, wenn nichts zu tun ist, sondern die CPU abschaltet, bis der nächste interrupt eintrifft (also mindestens ein timer-interrupt, der den scheduler antickert). das ist natürlich auch ein vorteil eines multitasking-systems, der hier bisher nicht genannt wurde. aber mal angenommen, du hast ein system, bei dem ständig irgendwelche daten durchgepumpt werden und bei dem energieverbrauch egal ist, dann biste ohne preemptives multitasking besser dran, weil die ganze rechenzeit für nützliche dinge benutzt wird, und nicht z.b. für's umschalten von tasks usw.

[byto]

ownpwnd schrieb:

byto schrieb:

Manche geben auch einfach zu, wenn sie unrecht hatten.

Die, die meinen, dass man für GUIs Multithreading braucht?

Alle mir bekannten aktuellen UI Frameworks sind multithreaded: QT, WPF, Cocoa, SWT, Swing, ... aber laber ruhig.