Multithreading
-
Wieviele Leute würden eigentlich drauf rein fallen, wenn man bei Berechnungen immeren zusätzlich ein paar threads startet die nichts tun außer CPU Zeit verbraten, damit es so aussieht, als ob die Anwendung multithreadingfähig wäre?
-
Imo ist es von aussen recht scher fets zu stellen, was ein Programm in welchem Thread macht..
Somit würde ich sagen, dass das kaum jemand merkt, der sich den Code zur Gemüte führt, oder eine grosse Unstimmigkeit feststellt (was ich für unwahrscheinlich halte).Aber was ist das überhaupt für eine Frage?!
-
War einfach nur so ne Idee. So ähnlich wie Splash Screens den Programmstart beschleunigen.
Gut beim Multithreading würde man es einfach feststellen können, wenn man die Zeit mit einem und mit Zeit Cores auf gleicher Hardware misst.
-
fragenderm schrieb:
Wieviele Leute würden eigentlich drauf rein fallen, wenn man bei Berechnungen immeren zusätzlich ein paar threads startet die nichts tun außer CPU Zeit verbraten, damit es so aussieht, als ob die Anwendung multithreadingfähig wäre?
viele, schätze ich. multithreading wird ziemlich überbewertet. bei single-core systemen bringts geschwindigkeitsmässig sowieso nix und bei multicores haste synchronisierte buszugriffe, die die CPUs ausbremsen. aber für benutzer, die gern mehrere anwendungen parallel betreiben, ist multitasking trotzdem toll. und sogar für programmierer, weil sie längliche schleifen statt state-machines oder irgendwas message-basiertes programmieren können. und man kann z.b. OOP damit pushen: objekte können autark irgendwas tun und nebenbei auf nachrichten reagieren. ohne multitasking muss man dafür mehr tricksen.
-
tasks und threads sind aber schon was Verschiedenes.
-
Ich schätze, dass nicht viele von den Leuten, die überhaupt in der Lage sind Multithreading zu erkennen, darauf reinfallen würden.
-
Multithreading wird oft unterbewertet, von Leuten die nicht wissen, wie man damit umgehen muss.
-
Erhard Henkes schrieb:
tasks und threads sind aber schon was Verschiedenes.
kommt auf die sichtweise an. der windoof-progger kennt threads, prozesse, tasks und jobs, für low-leveler (RTOS-user etc.) ist task und thread dasselbe, wenn sie das wort 'thread' in dem zusammenhang überhaupt kennen.
~aber gleich kommt unser bärchen mit dem entzündeten hals und wird uns diesbezüglich eine entspannte belehrung erteilen.~
-
nö ich hab halsweh und geh jetzt lieber heia
-
drakon schrieb:
Imo ist es von aussen recht scher fets zu stellen, was ein Programm in welchem Thread macht..
So ist es. In den meisten Windows-Anwendungen werden beispielsweise ein, zwei Hintergrundthreads von den Shell-Dialogen gestartet, zu welchem Zweck auch immer (ich vermute Shell-Notifications).
-
;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.
-
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.
und um auf ursprungsthema zurueck zu kommen, es wuerden die leute es merken die verschiedene cpus vergleichen.
-
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.
naja, das ist systembedingt, das liegt daran, dass das OS selber sowieso schon threads benutzt. z.b. du rufst irgendeine write-funktion auf und schiebst dabei daten in einen buffer. das I/O-system nudelt sie in einem separaten thread raus. ist der buffer voll, wird dein thread beim schreibversuch geblockt, trotzdem kannste in einem anderen thread parallel was anderes machen. für programmierer praktisch, aber ganz ohne multithreading wäre es schneller (wie die thread-umschalterei entfällt), nur komplizierter.
-
aber ganz ohne multithreading wäre es schneller (wie die thread-umschalterei entfällt), nur komplizierter.
das ist vollkommener unfug.
ganz ohne multithreading/multitasking müsste man auf die platte warten. wenn man sich was eigenes schreibt, um währenddessen was anderes zu machen, schreibt man sich eine eigene kleinen multithreading/multitasking implementierung.
-
ausserdem gibts auch noch so dinge wie hyperthreading
-
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.
-
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.
-
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.
-
;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.
-
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.
