Bestes OS für Multithreading?

Programmierung mit PostgreSQL (C#, PHP, Perl, Java, ...)
marc9022
Erfahrener Benutzer
Beiträge: 162
Registriert: Mo 19. Mai 2008, 08:42
Kontaktdaten:

Bestes OS für Multithreading?

Beitragvon marc9022 » Fr 26. Jun 2009, 09:42

Ok, der Begriff ist jetzt sicher unbeabsichtigt etwas provozierend aber die FRage ist durchaus ernst gemeint. Bei großen, Datenbank gestützten Websites kommt so langsam immer mehr in Mode das sie die COMET Technologie und Ajax als Client Counterpart einsetzen. Ajax erlaubt es bekanntlich nur bestimmte Teile einer Website neu zu laden, anstatt die ganze Seite neu anzufordern. Das dumme ist nur, bisher wurde dafür am Webserver jeweils ein neuer Workerthread gestartet.Die lösung scheinen, nicht blockierende, asyncrone Threads zu sein. Eine Tiefenanalyse eines amerikanischen Programmieres hat jedoch jetzt ergeben das die blockierende und nicht blockierendes threading vom Performanceansatz kaum voneinander differieren, die Performance bleibt also nahezu absolut gleich, obwohl man lange Zeit davon Ausging das nio und async Thread selbstredend besser abschneiden müssten! Ein großer Irrtum wie sich herausstellte. Der Grund dafür ist nicht die aktuelle Hardware, auch nicht Java oder andere Webapplikations-Systeme die Comet oder threaded
HTTP-Streaming nutzen sondern schlicht das OS und dessen Threading Architektur.

Ich gebe zu, ich habe schon von Windows bis Linux/Unix mit Threads gearbeitet aber mit der Frage welches OS z.B bei AMD64 Prozessoren das beste Usermode Threading bietet musste ich mich noch nicht auseinander setzen und leider gibt es erschreckend wenig lesenswertes Material zu genau diesen Thema, das angesichts von allgegenwärtigen Multicore und 64-Bit Systemen, Hyperthreading, Quadcores und demnächst 16 Core Systemen so langsam nicht mehr ganz unwichtig ist wenn es um skalierbare Anwendungen geht die die Hardwareressouren auch nutzen sollen.

Ich meine, es bringt ja rein gar nicht wenn man eine tolle, Threadbasierte Applikation entwickelt und das OS die ganzen Programmierbemühungen
zurnichte macht, weil der Kernel eben nicht über alle CPU's so skaliert wie es für eine Parallelisierung sinnvoll wäre.

symbiont
Erfahrener Benutzer
Beiträge: 1328
Registriert: Mo 17. Mär 2008, 11:45
Wohnort: NULL
Kontaktdaten:

Beitragvon symbiont » Fr 26. Jun 2009, 10:15

1. "die Performance" gibt es nicht - schon garnicht wenn du allgemeine problemstellungen zwischen blockierenden und nicht blockierenden nebenlaeufigkeiten betrachtest

2. es eher unwahrscheinlich, dass die implementation des threadings (system) selbst irgendeine signifikante rolle bei einer -> Webanwendung spielt. dieser aspekt ist dort definitiv kein engpass

marc9022
Erfahrener Benutzer
Beiträge: 162
Registriert: Mo 19. Mai 2008, 08:42
Kontaktdaten:

Beitragvon marc9022 » Fr 26. Jun 2009, 20:44

Also ich hatte entweder mit keiner oder wenn dann aber mit einer fundierten Antwort gerechnet. Deine war weder fundiert, noch das Thema reflektierend und verstanden hast Du auch nichts. Lass es am besten.

ads
Erfahrener Benutzer
Beiträge: 4148
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitragvon ads » Fr 26. Jun 2009, 23:17

marc9022 hat geschrieben:Deine war weder fundiert, noch das Thema reflektierend und verstanden hast Du auch nichts. Lass es am besten.

Danke!

Es gab mal Zeiten, da waren die Festplatten der Flaschenhals. Irgendwann danach war es der Hauptspeicher. Die CPU ist sowieso immer zu langsam und verbraucht zusätzlich auch noch zuviel Strom.
Ok, ernsthaft: Threading und geforkte Prozesse gibt es schon eine Weile, die massiv parallelen CPUs sind aber recht neu in der Hardware Welt. Die Programmiertechniken in herkömmlichen OS sind einfach nicht auf so etwas ausgelegt und es wird auch eine Weile dauern, bis sich daran etwas ändert. Hinzu kommen GPUs, die heute schon auf massiv paralleles Berechnen ausgelegt sind und derzeit nur mit speziellen Bibliotheken vernünftig nutzbar sind.

Wenn ich mir nur anschaue, wie stark ein einzelner globaler Spinlock ein herkömmliches System blockiert und wie sich die Situation in einem massiv parallelen System entwickelt ...

Persönlich denke ich, dass die Entwicklung weg von einer großen, starren Anwendung hin zu vielen kleinen (Teil)anwendungen gehen wird, die alle (quasi) unabhängig voneinander laufen können. In so einem System kannst du ggf. Tausende Prozesse parallel ausführen, ohne das sich diese gegenseitig stören. Quasi viele kleine Sandboxen. Nur auf die Art kannst du auf die veränderten Rahmenbedingungen reagieren und die anfallende Rechenlast auf alle vorhandenen Resourcen verteilen.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support

marc9022
Erfahrener Benutzer
Beiträge: 162
Registriert: Mo 19. Mai 2008, 08:42
Kontaktdaten:

Beitragvon marc9022 » Sa 27. Jun 2009, 10:01

ads hat geschrieben:Danke!

Es gab mal Zeiten, da waren die Festplatten der Flaschenhals. Irgendwann danach war es der Hauptspeicher. Die CPU ist sowieso immer zu langsam und verbraucht zusätzlich auch noch zuviel Strom.
Ok, ernsthaft: Threading und geforkte Prozesse gibt es schon eine Weile, die massiv parallelen CPUs sind aber recht neu in der Hardware Welt. Die Programmiertechniken in herkömmlichen OS sind einfach nicht auf so etwas ausgelegt und es wird auch eine Weile dauern, bis sich daran etwas ändert.


Dann ist das aber ein großes generelles Problem. Ich meine wenn ich unter Linux was mit Threads machen will, dann definiere ich die zwar in meinem Source, aber der SMP Kernel sagt dann wann und wo meine Threads laufen. Unter Windows ist das mit SMP eigentlich ein großer Witz, da muss ich mich komplett selber drum kümmern und mehr als 8 CPU's sind sogar bei den teuren Server Editionen nicht so ohne weiteres drin.Wenn aber Linux/Unix Threads/Forks nicht sauber an die Cores die da sind verteilen kann, dann nützt mir ja auch meine ausgefeiltestes Thread Programm nichts wenn ich skalieren möchte. Die Java JVM kapselt das sogar noch. Sie läuft wie mein C Programm auf dem SMP Kernel und Threaded und Forkt unter Linux/Unix munter drauf loß. Nach dem Comet Async Test Bericht ist aber klar, das zumindest unter Linux noch erheblicher Nachbesserungsbedarf auf unterster Schiene im Kernel besteht. Wie schaut das da im Gegenzug z.B mit Solaris oder FreeBSD aus? Solaris war offenbar einer der ersten Multi CPU Betriebssysteme. Bezieht sich das nun wieder nur auf Sparc oder auch die AMD64
CPU's ?

Es kommt mir schon sehr komisch vor das alle paar Monate mehr Cores in den Rechnern verbaut werden und die Betriebssysteme das gar nicht richtig
ausnutzen, das macht irgendwie keinen großen Sinn.... Sogar bei der PS/3 "CELL" scheint es für die Entwickler gar nicht so trivial zu sein die angebotene
Parallelisierung richtig zu nutzen.

ads
Erfahrener Benutzer
Beiträge: 4148
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitragvon ads » Sa 27. Jun 2009, 12:57

marc9022 hat geschrieben:Dann ist das aber ein großes generelles Problem. Ich meine wenn ich unter Linux was mit Threads machen will, dann definiere ich die zwar in meinem Source, aber der SMP Kernel sagt dann wann und wo meine Threads laufen.

Richtig. Und das würde auch wunderbar funktionieren, wenn es nicht trotzdem Operationen gibt, die zwischen allen Threads abgestimmt werden müssen.

Als Beispiel: wenn zwei Threads auf den gleichen Speicherbereich zugreifen wollen, aber auf verschiedenen CPUs laufen, bremsen sie sich trotzdem gegenseitig aus. Das ist aber eine Frage der Aufgabenstellung und des Betriebssystems, nicht der eigentlichen Threadfunktionalität an sich.

Wenn es der Programmierer schafft, die Aufgaben wirklich zu parallelisieren, kann er die Arbeit über alle vorhandenen Kerne verteilen.



Unter Windows ist das mit SMP eigentlich ein großer Witz
No comment.



Es kommt mir schon sehr komisch vor das alle paar Monate mehr Cores in den Rechnern verbaut werden und die Betriebssysteme das gar nicht richtig ausnutzen, das macht irgendwie keinen großen Sinn.
Wenn du - wie jetzt - drüber nachdenkst, merkst du das. Aber für die Masse ist das schlicht nur: "Mehr = Besser". Die Marketingabteilungen der Prozessorhersteller lassen die Leute auch brav in dem Glauben.



Sogar bei der PS/3 "CELL" scheint es für die Entwickler gar nicht so trivial zu sein die angebotene Parallelisierung richtig zu nutzen.
Es hat halt keiner so wirlkliche Erfahrung damit.
Die ersten, die das ausgenutzt haben, waren gleich mal Programme zum Berechnen von großen Datenmengen. Dafür war die PS3 zwar nicht gedacht, aber in diesem Bereich gibt es bereits massive Erfahrungen, wie man Arbeiten über Tausende Rechner verteilt.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild



Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler



PostgreSQL Service & Support

symbiont
Erfahrener Benutzer
Beiträge: 1328
Registriert: Mo 17. Mär 2008, 11:45
Wohnort: NULL
Kontaktdaten:

so

Beitragvon symbiont » Mo 29. Jun 2009, 14:51

und jetzt finden wir mal den Bogen zurueck zu einer web-anwendung - kontextfrei war das OP nicht, es wurde u.a. Ajax genannt ..

und Ajax als Client Counterpart einsetzen. Ajax erlaubt es bekanntlich nur bestimmte Teile einer Website neu zu laden, anstatt die ganze Seite neu anzufordern. Das dumme ist nur, bisher wurde dafür am Webserver jeweils ein neuer Workerthread gestartet.


und schon stellen wir fest, dass "mehr = besser" durchaus eine sinnvolle formel darstellt, weil sich threading-konzepte im OS oder support durch CPU-typ auf einem unverwandtem abstraktionsniveau abspielen .. "mehr = besser" hat zwar mit der frage wenig zu tun - aber wenigstens führt sie zu fruchtigen erkenntnissen/lösungen - nämlich was passiert wenn ich tatsaechlich gleichzeitig viele requests zu bearbeiten habe .. so ein thread zu erzeugen geht im netzwerk unter (latenz) - zuwenig prozessorzeit hingegen spuert man mitunter sehr deutlich. ersteres manko laesst sich durch pools zudem sehr elegant lösen - was ja auch getan wird.

weiterhin muss beachtet werden, dass es nachwievor durchaus ueblich ist, serverseitig keine threads zu starten - sondern prozesse geforkt werden - was erheblich "teurer" als erstere variante - das nimmt man aber aus anderen bekannten gründen in kauf.

die ganze frage eruebrigt sich somit wegen dem aufgaben-schwerpunkt des vorgegebenen kontext.

aber gross rumtönen

ads
Erfahrener Benutzer
Beiträge: 4148
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitragvon ads » Mo 29. Jun 2009, 15:07

symbiont hat geschrieben:weiterhin muss beachtet werden, dass es nachwievor durchaus ueblich ist, serverseitig keine threads zu starten - sondern prozesse geforkt werden - was erheblich "teurer" als erstere variante - das nimmt man aber aus anderen bekannten gründen in kauf.

Beweise das bitte.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild



Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler



PostgreSQL Service & Support

symbiont
Erfahrener Benutzer
Beiträge: 1328
Registriert: Mo 17. Mär 2008, 11:45
Wohnort: NULL
Kontaktdaten:

Beitragvon symbiont » Mo 29. Jun 2009, 15:11

ads hat geschrieben:Beweise das bitte.


postgres :) auch apache wird so gern betrieben

oder brauchst du eine erklaerung, warum prozesse erzeugen teurer ist als die erzeugung von threads?

ads
Erfahrener Benutzer
Beiträge: 4148
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitragvon ads » Mo 29. Jun 2009, 15:15

symbiont hat geschrieben:postgres :) auch apache wird so gern betrieben

Warum wohl?


oder brauchst du eine erklaerung, warum prozesse erzeugen teurer ist als die erzeugung von threads?

Ja, danach fragte ich dich.
Und vor allem auch nach einigen Zahlen zu deiner Behauptung.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild



Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler



PostgreSQL Service & Support


Zurück zu „Programmierung“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste