Descentforum.DE

[King Lo]

Hey,

hatte grad mit d3jake eine interessante Diskussion, in wie viel Threads wir den Netzwerkcode von FlightBack aufspalten sollen. Ich hatte eine Idee, ca. 8 Threads für den Netzcode zu verwenden (und später noch viele mehr). Ich würde Dinge, die eigentlich ohnehin nicht viel machen, gerne in Threads aufspalten (Ein Thread, der einkommende Pakete AntiCheat-scannt, einer, der ausgehende Pakete multiplext, einer, der sie nur quittiert, .....). Das ganze hat Zukunft und ist vermutlich sogar einfacher zu programmieren.

jake hingegen meinte, man sollte lieber Rücksicht auf Leute mit älterer Hardware nehmen. Die kritischeFrage ist, wie viele Thread-Switches man PCs mit einem Core und nicht so viel RAM zumutet... (U.u. wird sogar sinnlos zu Threads geswitched, die gar nix zu tun haben?).

Wie sieht denn die Zukunft nun aus?

• Laut Intel haben wir in einigen Jahren schon Millionen-Cores...
  
• Jemand an der Uni meinte neulich, dass der RAM zur Engstelle wird, da man es nicht bezahlen kann, Millionen RAM-Bausteine auf einer Platine unterzubringen, und sich deshalb eh die meisten Threads den Memory teilen, und Threads daher *nicht unbedingt* die Zukunft sind...

Um noch mal zur Frage zurückzukehren: Sollte man ein Programm "auf Teufel komm raus" multi-threaden, d.h. jede einfachste Tätigkeit nochmal versuchen zu spalten? Und was meinen dann die Anwender, die bei alter Hardware evtl. mit den Thread-Switches zu kämpfen haben?

Würde mich freuen ein paar Meinungen zu hören!
Gruß,
Lo

[Floyd]

frag mal in einem programmiererforum nach. hier sind größtenteils nur spieler und vermutlich hat mehr als die hälfte davon keine ahnung wovon du hier redest .
viel sinnvoller wäre die frage: "was habt ihr derzeit für hardware und was plant ihr für die zukunft?" den rest musst du als angehender softwareingenieur selbst herausfinden.

[Do_Checkor]

[Floyd]

sind doch mehr als die hälfte

[Pffzzhh]

Da ich mit Programmierung auch so meine Erfahrung habe, gebe ich mal meinen Senf dazu.

Ich empfinde das aufteilen kleinster Teile in noch kleinere Teile nicht sinnvoll. Wenn wir von vielleicht 5 % Laufzeit für den Netzcode ausgehen, macht eine weitere Unterteilung kaum Sinn. die anderen 95 % sollten besser aufgeteilt werden, auch wenn dass schwierig ist.

Zuviele Threads kann man selbst für Singlecore Prozessoren kaum erzeugen, ich bin mir nicht sicher wo die liegt, aber selbst hunderte Threads im Programm sollten da noch keien Probleme machen. Allerdings rührt diese Erfahrung nur vom ausführen von Programmen. Beim Programmieren habe ich bisher nur simplen Test-Code entwickelt um die Möglichkeiten auszuloten.

Ich hoffe, das hilft dir etwas weiter...

[King Lo]

Naja, zu man *kann* wohl schon 32.000 erzeugen, aber die Frage ist nur, wann der Overhead zu viel wird

@all: Wie das Thema schon sagt... Die Frage ist eigtl., was die Anwender erwarten, nicht nur die Programmierer. Daher sind gerne Kommentare von nicht-Programmierern erwünscht!

[Maulwurf]

ich frag mich was ein normaler Anwender von Threads verstehen soll. ich frag mich sogar was die frage soll. dieses thema in dieser weise aufziehen zu wollen find ich sinnlos. ein thread kommt da zum einsatz, wenn der rest vom programm geblockt werden würde. fertig. sequentielle abläufe in threads aufzuspalten macht keinen sinn. man hat nur aufwand das zeug zu synchronisieren ohne weiteren nutzen.

[Munk]

Kurz: Es hängt vom konkreten Problem ab.
Es macht kein Sinn mehrere Threads auf verschiedene Probleme loszulassen, wenn jeder Thread auf das Ergebnis des anderen Threads warten muss.

Ich weiß nicht genau was Du machen willst, aber das Suchen nach Signaturen in Paketen würde ich auf jeden Fall in einem Thread parallel zur dessen Verarbeitung machen, es sei denn Du musst das Paket vor der Verarbeitung modifizieren.

[Thomas]

Wollt auch grad mit einer Erörterung anfangen, hab aber dann gesehen, daß Maulwurf das schon getan hat.

Zu Threads hat man keine Meinung. Sie gehören dahin, wo sie Sinn machen und raus, wo sie's eben nicht tun. Keine Ahnung, was es da zu diskutieren gäbe. Außer vielleicht, zu erklären, wann diese Fälle eintreten.

Wenn du mehrere (arbeitslastige) Kerne verwenden willst, dann programmier nicht einfach drauf los, sondern prüf beim Start erst einmal die Affinität. 50 Threads für eine aufwendige Berechnung machen nämlcih tatsächlich Sinn, aber halt nur auf einer Kiste mit mindestens 50 CPUs.

Threads, die auf Ereignisse warten, haben so gut wie keinen Overhead. Es geht wirklich nur ums Blocken.

Ein Server wird immer pro Client mindestens einen oder mehrere Threads (oder neue Prozesse, wie's bei Unix-Software noch üblich ist) aufziehen müssen. Stell dir vor, ein Client geht vom Netz oder irgendwo tritt ein Fehler mit Pause auf. Sollen dann die Anderen derweil 30 Sekunden warten?

Jede Art von I/O kann übrigens blocken, d.h. daß du ohne mindestens zwei Threads einen Bug erzeugst. Solange du kein RAID 3 oder 5 für die Platten hast, steht nämlich dein Server u.U. für 100 ms, wenn du in eine Datei schreibst.

[sattmacher]

Genau das wollte ich auch sagen,"ES ZZZRIEEETTT SO AUS;DAS HIER DAS FALSCHE FORUM FÜR DEN "ZRIEEETTTT IST"

[King Lo]

@Floyd, Checkor, Mauli, sattmacher:
Die Frage war nicht: "Braucht King Lo jemanden, der ihm prohpezeit, dass ihm vielleicht wenige antworten könnten?"... Ich meine, es gibt immer jemand, der einem helfen kann. Wahrscheinlich haben wir nur ein Dutzend Leute, die sich mit D3EDIT richtig gut auskennen, aber es macht Sinn, dass jeder in einem Forum dazu Fragen stellen kann. Außerdem muss man nicht programmieren zu können, um abzuschätzen, wie sich die Hardware entwickelt oder um seine eigene Systemlast zu beobachten.

[Maulwurf]

sequentiell ist bei mir beispielsweise ein Ablauf A->B->C wobei B das Ergebnis von A braucht und C das Ergebnis von B. In deinem ersten post klang das so, als ob so etwas aufgespalten werden soll. A ein Thread, B ein Thread und C ein Thread.

[Munk]

[Pffzzhh]

[Marix]

Ich würde heutzutage prinzipiell alles was nicht sequentiell voneinander abhängt in Threads aufteilen. Das tut performancemäßig auch auf alter Hardware nicht wirklich weh und skaliert dann sauber in die Zukunft.

Die wirklich parallele Hardware wirst du aber nur voll nutzen können indem du innerhalb von Aufgaben parallelisiert (z.B. mit OpenMP). Denn meißt gibt es wenige Aufgaben (Graphik, Physik, AI) die viel Rechenzeit brauchen, und viele Aufgaben (Netzwerk, Sound etc) die eh nur irrelevant wenig Zeit brauchen.

[Do_Checkor]

[Floyd]