Multithreading

[Gast]

Es geht um die Ausnutzung von Prozessoren mit mehreren physischen (Multi-Core) oder logischen (SMT) Kernen.

Es wird ja bei Multi-Core immer argumentiert, dass diese nur durch Multi-Threaded Anwendungen ausgenutzt werden können. Was ja erstmal einleuchtet, denn wenn ein Programm in mehrern Threads ausgeführt wird, können diese auf verschiedenen Cores laufen.

Aber: was ist mit dem Betriebssystem selbst? Das BS hat doch intern auch jede Menge Threads, die es zur Betriebssystem-Verwaltung braucht. Also z.B. Scheduler usw. Was spricht dagegen, diese Threads ebenfalls auf die einzelnen Cores zu legen? Oder wird dies längst getan, und wenn ja, warum spicht immer jeder nur von "multi-threaded" Andwendungen (Programmen).

Z.B. schon damals mit der Einführung von SMT beim P4, warum wurde/wird immer argumentiert, dass der P4 _nur_ bei multithreaded Andwendungen einen Vorteil durch Hyperthreading ziehen kann? Theoretisch müsste man ja auch so schon einen Geschwindigkeitsvorteil spüren, wenn die BS-internen Threads auf die 2 logischen Cores ausgeführt werden können. Oder ist die CPU-Belastung solcher Verwaltungs-Threads ohnehin so gering im Vergleich zu den Anwendungen, die auf einem BS laufen, dass man keinen Vorteil spürt?

[Tesseract]

natürlich nutzt ein guter scheduler alle cores aus. nur wann soll dir das auf einem desktop-system auffallen? etweder du hast eine fette anwendung laufen (codieren, spielen etc.) oder die CPU ist sowieso zu 99% im idle.

[Gast]

ok, angenommen es läuft eine fette Anwendung (die aus nur 1 Thread besteht). Und angenommen diese Anwendung nimmt viele BS-Funktionen in Anspruch (was weiß ich, z.B. IO-Sachen). In dem Fall wäre es doch von Vorteil, wenn der Programm-Thread (in dem Fall wäre es wohl einfach ein Prozess) auf einem Core läuft (sei er jetzt logisch oder phsyisch), und auf dem anderen Core kann ein 2. Thread "ganz in Ruhe" die BS-Aufgaben erfüllen. Dann müsste man doch einen Vorteil sehen oder?

[dust]

ok, angenommen es läuft eine fette Anwendung (die aus nur 1 Thread besteht). Und angenommen diese Anwendung nimmt viele BS-Funktionen in Anspruch (was weiß ich, z.B. IO-Sachen). In dem Fall wäre es doch von Vorteil, wenn der Programm-Thread (in dem Fall wäre es wohl einfach ein Prozess) auf einem Core läuft (sei er jetzt logisch oder phsyisch), und auf dem anderen Core kann ein 2. Thread "ganz in Ruhe" die BS-Aufgaben erfüllen. Dann müsste man doch einen Vorteil sehen oder?

ja ist es

[Crystallion]

ok, angenommen es läuft eine fette Anwendung (die aus nur 1 Thread besteht). Und angenommen diese Anwendung nimmt viele BS-Funktionen in Anspruch (was weiß ich, z.B. IO-Sachen). In dem Fall wäre es doch von Vorteil, wenn der Programm-Thread (in dem Fall wäre es wohl einfach ein Prozess) auf einem Core läuft (sei er jetzt logisch oder phsyisch), und auf dem anderen Core kann ein 2. Thread "ganz in Ruhe" die BS-Aufgaben erfüllen. Dann müsste man doch einen Vorteil sehen oder?
Theoretisch ja, das Problem ist aber: Der Programm-Thread darf dann nicht auf das Ergebnis des BS-Calls warten, sondern muss sich in der Zwischenzeit (in einem anderen Thread) anders weiter beschäftigen, sonst verpufft dieser Vorteil wieder. Also sind wir wieder beim Punkt, dass die fette Anwendung auf die Möglichkeit mehrere parallel ausführbarer Threads vorbereitet sein muss.

[Gast]

Theoretisch ja, das Problem ist aber: Der Programm-Thread darf dann nicht auf das Ergebnis des BS-Calls warten, sondern muss sich in der Zwischenzeit (in einem anderen Thread) anders weiter beschäftigen, sonst verpufft dieser Vorteil wieder. Also sind wir wieder beim Punkt, dass die fette Anwendung auf die Möglichkeit mehrere parallel ausführbarer Threads vorbereitet sein muss.
Ja das klingt logisch.

Ich habe auch selbst nochmal drüber nachdeacht und kam zum Ergebnis, dass wahrscheinlich die BS-Aufrufe/Warten auf IO der limitierende Faktor ist.
Also im Prinzip das gleiche was du gesagt hast.

[rad05]

Schau dir Windoes nochmal auf einer Single-Core CPU an, und lass ein CPU-intensives Programm laufen und dazu surfst du noch im Internet. Dann merkst du, wie "unrund" Windows läuft. Wenn das System nicht ausgelastet ist, merkst du den Unterschied nicht, das die CPU ja sowieso genug Reserven hat im Leerlauf.

[Gast]

Das wird längst getan, das OS verteilt die Aufgaben in der Regel auf mehrere Cores (nicht die einer einzelnen Anwendung, sondern die komponenten vom OS und seine laufende Programme)

Problem ist aber: Es bringt nicht viel.Durch einen zweiten Kern gewinnst du vielleicht 5-10% an Mehrperformance bei der Anwendung gegenüber einem Singlecore.
Durch optimierte Grafiktreiber teilweise noch etwas mehr,aber was dann? Dann hängt es von der Anwendung ab... und wenn die nicht mitspielt, dann ist essig mit MultiThreading... die kleinen Steigerungen sind im Vergleich zu dem was möglich wäre gar nichts.Ein Videoenconder kann ja teilweise alle Cores auslasten,aber bei Spielen ist es dann wieder essig,wenn die nicht darauf ausgelegt sind und nur einen einzigen nutzen.Dann hast du die restlichen 2-3 Cores für andere Spielereien frei... :)

[Pennywise]

Dafür hatte Intel ja damals das Hyperthreading erfunden. War seinerzeit ein Riesenvorteil gegenüber einem einzelen Core, einfach weil immer noch ein Quentchen Rechenleistung für das BS über war. Was es brachte? Einfach ein etwas flüssigeres System.