Multiprozessoren nutzlos ohne Multithreading

Dinh

Dinh

Well-Known Member
Moin

Lars hat in diesem Thread [1] auf folgenden Artikel [2] verwiesen, über den ich gerne eine kleine Diskussion starten würde.

Beim Lesen des Artikels sind mir ein paar Fragen durch den Kopf geschossen:

- Wie sieht das bei xorg und den grossen DE (xfce, kde, gnome) aus? Ist bei denen noch alles singlethreaded?
- Wie weit ist da Microsoft mit Vista + dessen tools?
- Ist das nicht auch 'ne riesen Möglichkeit für Softwareentwickler die Konkurrenz hinter sich zu lassen?
Man denke an Spielehersteller, deren 3d-Games mit 3x mehr Details auf Multicore-Prozessoren laufen, als die der Konkurrenz.
Oder, wenn Vista das noch nicht unterstützte, könnten die freien OS' darauf setzen und so mehrmals schneller laufende Betriebssysteme anbieten.

Nur so ein paar Gedankengänge zu denen mich eure Meinung interessiert! :)



[1] http://www.bsdforen.de/showthread.php?p=103741#post103741
[2] http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=333
 
Die grossen Unix Desktop Environments sind meist iirc singlethreaded aber mit mehreren Prozessen. Auf Windowsplattformen finden sich weniger Prozesse, dafür mehr Threads. Dies liegt einfach daran, dass auf Unix Prozesse, auf Windows Threads "billig" sind. Traditionell jedenfalls. Auf Dragonfly dürften Threads billiger sein (Vermutung).

In Computerspielen ist das problematisch. Quake 3 zum Beispiel kann SMP ausnutzen, die Synchronisierung ist allerdings richtig problematisch. Dazu kommt dann noch die Tatsache, dass die meisten Grafikkartentreiber da schlicht nicht mitspielen.
War also alles schonmal da, aber wenig praktikabel. Das ist auch der Grund, warum Doom 3 kein r.smp=1 flag mehr hat, es war aufgrund externer Faktoren (Treiber...) sowieso praktisch nicht verwendbar.
Unter Windows hat man aber den Vorteil, CPU Affinität festlegen zu können. Wirf das Spiel auf den einen Core und alles andere auf den anderen. Bringt schonmal ein bisschen was.

Sobald Multicore CPUs eine ausreichende Marktdurchdringung vorzuweisen haben, werden Sie sicher genutzt werden. SMP-Systeme bei "Heimanwendern" waren schlichtweg zu selten um den nicht unerheblichen Mehraufwand in der Entwicklung zu rechtfertigen. Haben genug Leute SMP Systeme und sind ausreichend viele Spiele in der Lage dies auszunutzen haben die Grafikkartenhersteller gar keine andere Wahl als ihr Threading zu reparieren - wenn sie im Markt bleiben wollen.
 
also ich finde der artikel ist nicht ganz realistisch, m.e. wird die anpassungsphase besonders im oss bereich viel schneller gehen...
wenn k42 stabil laueft, habne wir den ersten multi-threaded kernel, der noch dazu linux-kompatibel ist und oss...
und was normale software angeht ist der artikel auch nciht sehr korrekt:
With the possible exception of Java, there are no widely used commercial development languages with MT extensions
Zum Vergrößern anklicken....
es gibt mehrere mt extensions fuer c++ (ich geh mal davon aus dass c++ die "widely used development language" ueberhaupt ist) und die qt multi-thread extension laeuft auch in python soweit ich weiss, also stimmt das schon mal nicht.
threaded zu programmieren ist zwar gewoehnungsbeduerftig, aber wer sauberen, gut strukturierten code schreibt, wird damit keine probleme haben. ich selber kanns zumindest und halte mich nicht fuer besonders :gpaul:
bei quake3 soll der mt support einfach schlecht gemacvht gewesen sein, aber vielleicht sehen wir da ja verbesserungen nach dem code release (OT: hat sich schon jemand um einen quake3-port bemueht?).
 
Der FreeBSD Kernel ist seit 5.x Multithreaded :)

Und zumindest auf FreeBSD mit libpthread oder libc_r sind Threads auch billig. (mit libthr müsste ein Thread ungefähr so "teuer" sein wie unter Windows, linuxthreads dürften die teuersten sein; das ganze bezogen auf erschaffen und verwalten). Korrigiert mich bitte falls ich mich irre.

Für C gibt es gute Threading Unterstützung.
 
Elessar schrieb:
Die grossen Unix Desktop Environments sind meist iirc singlethreaded aber mit mehreren Prozessen. Auf Windowsplattformen finden sich weniger Prozesse, dafür mehr Threads. Dies liegt einfach daran, dass auf Unix Prozesse, auf Windows Threads "billig" sind. Traditionell jedenfalls. Auf Dragonfly dürften Threads billiger sein (Vermutung).
Zum Vergrößern anklicken....


Mh, das stimmt glaube ich nicht.

Von der Idee her ist das Erzeugen eines neuen Threads immer billiger als ein neuer Prozess, denn ein Thread benutzt denselben Speicherbereich und dieselben sonstigen Ressourcen wie der Prozess, zu dem er gehört. Das gilt unabhängig vom OS, gilt also für Windows genauso wie für Linux und die BSDs.

Siehe auch den Wikipedia-Eintrag zu Threads

Es ist halt nur so, daß unixartige Systeme traditionell eine eher schlechte Unterstützung für Threads gehabt haben. Das betrifft sowohl Probleme hinsichtlich der Zuverlässigkeit als auch Probleme mit der Skalierbarkeit bei vielen Threads als auch Effiziensprobleme im Multithreadingbetrieb.

Erst in den letzten Jahren hat sich da so richtig viel geändert. Mittlerweile gibt es einige ganze Reihe an Neuentwicklungen mit verschiedenen Stärken und Schwächen für verschiedene Situationen.

Es ist wichtig, daß das OS eine gute Unterstüzung für Thread bietet. Aber das allein reicht noch nicht aus. Das Problem ist nämlich, daß man vorhandenen single Thread Code aus Anwendungen und Bibliotheken nicht mal eben so umgestalten kann, daß mehrere Threads benutzt werden. Das ist kompliziert, und es gibt eine Menge zu beachten, damit man sich keine Race Conditions, deadlocks und so weiter einhandelt.

SMP ist dann wieder ein ganz anderes Thema. Bislang ging es in meinem Beitrag ja darum, daß Software unter unixartigen Systemen in der Vergangenheit selten mehrere Threads benutzt hat, obwohl das in vielen Fällen die natürliche Vorgehensweise gewesen wäre. Stattdessen haben viele Softwareprodukte entweder alles in einem einzigen Prozess mit einem Thread erledigt (und haben Parallelausführungen intern selbst gemanaged), oder sie haben mehrere Prozesse benutzt, die dann über verschiedenden Techniken miteinander kommuniziert haben (etwas über shared memory). Beide Lösungen haben den Programmierern einen erheblichen Aufwand aufgebürdet, der sich mit einer ordentlichen Thread-Unterstüzung des OSes erheblich hätte verringern lassen.

Bei SMP-Skalierbarkeit geht es aber nicht mehr um die Frage, wieviele Threads man für Problem X natürlicherweise erzeugen würde, sondern wieviele man überhaupt maximal erzeugen kann. Diese Zahl ist nämlich oft einfach begrenzt. MySQL arbeitet zwar multithreaded, bearbeitet aber eine Anfrage immer nur mit einem Thread. Ein einzelnes SELECT Kommando ist also auch auf einem System mit 64 CPUs nicht schneller als auf demselben System mit nur einer aktivierten CPU. Bei Apache mit dem worker mpm ist es dasselbe: Ein Thread wird natürlicherweise für eine Anfrage benutzt. Und eine CPU reicht von der Leistung her ja für eine Anfrage aus.

Aber wenn ein einzelnes zu bearbeitendes Problem schon so aufwendig ist, daß man sich wünscht, von mehreren CPUs profitieren zu können, dann stellt man oft fest, daß das nicht so ohne weiteres möglich ist, weil die zugrundeliegenden Algorithmen sich nicht so ohne weiteres parallelisieren lassen. Zumindest nicht in dem Sinne, daß mehrere Threads benutzt werden können, die mehrere CPUs gleichzeitig auslasten können. Ein kleines Beispiel, wo das gelungen ist, ist eine Änderung/Neuimplementierung des bzip2-Algorithmus, siehe http://compression.ca/pbzip2/ Aber bei vielen Algorithmen hat man überhaupt noch keine Möglichkeit gefunden, sie zu parallelisieren.

Zusammenfassung:

Ich bin absolut dafür, daß mehr Software für unixartige Systeme Threads benutzt, wo es ein natürliches Bedürfnis ist. Ich glaube auch, daß es einen erheblichen Aufwand bedeuten würde, diverse OpenSource Produkte und Libraries auf die Verwendung von Threads umzuschreiben. Aber ich bin der Ansicht, daß der Typ, der diesen ACM Queue Artikel geschrieben hat, keine Ahnung hat, daß es nicht mal eben so ohne weiteres durch hinzufügen von Threads möglich ist, daß eine einzelne Anwendung auf 100 CPUs hundert mal so schnell läuft wie auf einer CPU.
 
Der Autor (mache@creeger.com) behauptet nirgends, was du ihm in deiner Zusammenfassung vorwirfst.

Hat hier jemand eigentlich ein MP-System und kann Messwerte für FreeBSD 6.0 vs. 4.x und/oder FreeBSD 6.0 auf UP vs. FreeBSD 6.0 auf MP angeben?
 
Danke für eure Schilderungen.
Ist mir jetzt alles ein bisschen Klarer. :)

SMP ist dann eigentlich "nur" noch dafür zuständig, alle Threads (z.B. eines Multithread-Programms) schön auf alle Prozessoren zu verteilen. Hab ich das auch richtig verstanden?

In Google finde ich leider keien Informationen dazu, wie Microsoft an das Problem rangeht.
 
Und zustaendig ist dafuer einzig der Scheduler. Und der hat unter FreeBSD noch einige Probleme mit logischen/physischen CPUs (ULE und BSD)
 
lars schrieb:
Der Autor (mache@creeger.com) behauptet nirgends, was du ihm in deiner Zusammenfassung vorwirfst.
Zum Vergrößern anklicken....

Bezieht sich das auf meinen Beitrag?

Ich will mich jetzt nicht darum streiten, finde das auch ehrlich gesagt nicht interessant genug, aber ich glaube schon, daß er das gemeint hat:

"Each application would gracefully increase its performance as more and more processors became available for use."

Es ist doch wohl ziemlich klar, daß er im folgenden Multithreading als die Lösung darstellt, oder?

Ich wollte mit meinem Hinweis nur darauf aufmerksam machen, daß das Problem komplizierter ist. Eine Umstellung von single threaded Code auf multi threaded Code ist schon schwierig genug, aber leider trotzdem nicht ausreichend, um die Leistung von "immer mehr CPUs" auch ausnutzen zu können.
 
Ja, das hat sich auf deinen Beitrag bezogen.

Ich will mich jetzt auch nicht wirklich streiten, nur darauf aufmerksam machen,
dass du eventuell den Text, oder Teile davon, missverstehst.

Schliesslich beendet er den Abschnitt, aus dem du zitierst, mit folgendem Satz:
"Sounds reasonable, right? Don’t count on it."

Ist jetzt nicht gerade ultrawichtig, finde ich auch.
 
Dinh schrieb:
Oder, wenn Vista das noch nicht unterstützte, könnten die freien OS' darauf setzen und so mehrmals schneller laufende Betriebssysteme anbieten.
Zum Vergrößern anklicken....
Für Multiprozessoren/SMP/... gibt es bereits DragonFlyBSD :D

EDIT: Ups, hab das Datum übersehen, dachte, dass hier noch heiß diskutiert wird. Ist eben ein Kommentar, für jemanden, der ein SMP-System sucht...
 
<off-topic>
ist doch nicht schlimm, im Vergleich zu der Leiche (den Thread über Tastatursicherheit) die ich letztens hier ausgegraben hab :D
</off-topic>
 
Hallo Dinh,

Wie weit ist da Microsoft mit Vista + dessen tools?
Zum Vergrößern anklicken....
Bei Windows ist es etwas anders. Hier mußt Du zwischen GUI und Kernel trennen.
Die meisten GUI-Anwendungen unter Windows sind mitnichten multithreaded. Es wird für jede gestartete Anwendung vom Scheduler der GUI ein Thread erzeugt, der die message-queue (Mausbewegung, window messages, usw.) abarbeitet. Dadurch kann es selbst bei einer Blockade der Anwendung zu keinem Blockieren der GUI kommen. Warum das Ganze? Nun, es ist teuerer eine multithreaded Anwendung zu entwicklen, als eine singlethreaded. Man bedenke allein schon die Synchronisation (Semaphoren!) des Zugriffs auf Prozess-globale Variablen.
Also, bei Windows muß man unterscheiden zwischen multithreading und multiple message queues.
Auf nicht-GUI-Ebene sieht es anders aus - aber schreibt dafür eigentlich jemand Programme :D

Viele Grüße

Jürgen
 
Hast schonmal mit Borland Zeugs Windows Apps entwickelt? Da blockiert die GUI ständig, logischerweise, wenn man etwas aufwendigere Sachen in einem Event berechnet. Ist ja klar. Diese primitive Schleife wird dann auch unterbrochen. Borland Programmierer fügen dann gerne mal ein Application->ProcessMessages() in den Code ein, was die ganze Sache aber total verschlimmert, und an locking denkt ja dann auch keiner.

Es gibt allerdings auch sinnvolle Anwendungen für Message Queues wie kqueue(2) unter FreeBSD :)
 
Moin,

das ist sehr interessant. Unter WinNT4 war dieses Verhalten nicht zu beobachten - zumindest bei VisualAge C++. Die rechenintensiven Anwendungen, die wir damit erstellt hatten, waren aus kostengründen nicht multithreaded. Da hat nix die GUI blockiert, idle-Funktionen oder ähnliches wurde auch nicht verwendet.
Also auch hier der sprichwörtliche M$-Fortschritt - wen wundert es...

Viele Grüße

Jürgen
 
lars schrieb:
Der Autor (mache@creeger.com) behauptet nirgends, was du ihm in deiner Zusammenfassung vorwirfst.

Hat hier jemand eigentlich ein MP-System und kann Messwerte für FreeBSD 6.0 vs. 4.x und/oder FreeBSD 6.0 auf UP vs. FreeBSD 6.0 auf MP angeben?
Zum Vergrößern anklicken....


koennte ich, auf einem compaq proliant server (2x P-III 550mhz) wenn du mir sagst, was zu tun ist. :D
 
Danke für dein Angebot.

Felix von Leitner hat im Jahre 2003 eine Kontroverse ausgelöst, als er
die Benchmark-Ergebnisse von Free-, Net-, OpenBSD und Linux verglich.

Daher würde mich sehr interessieren, wie es jetzt damit aussieht.

Siehe daher sein Setup und seine Methoden hier:
http://bulk.fefe.de/scalability/

Da hättest du die Gelegenheit die Kontroverse von neuem anzufachen :-)
 
Skalierbarkeitsmessung von drei, vier syscalls != Benchmark

Der Skalierbarkeitsvergleich ist nur fuer die Entwickler interessant, fuer normale Anwender laesst sich daraus absolut garnix ableiten.
 
Also die Spiele sind heutzutage alle Multithreaded, um die HT Technologie richtig auszunutzen.
Also zumindest die neuen Windows Games...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben