PC-Update: Entscheidungshilfen
-
"optische Schmankerl" Wollte hier aber niemand haben...
-
Jester schrieb:
Das Argument verstehe ich nicht. Wenn man objektorientiert programmiert sind nachher, wenn man kompiliert hat die OO-Strukturen auch weg. Trotzdem denke ich, wir sind uns einig, daß OOP was nützliches und sinnvolles ist. Genauso ist es mit Threads. Abgesehen davon, daß Dinge die auf irgendwelche Hardware warten müssen mit Threads durchaus schneller sein können als ohne.
nein, da sind wir uns nicht einig. nur weil etwas existent ist, heißt es nicht dass dessen verwendung automatisch sinnvoll ist. ich würde nicht für jede einzelne variable eine boostlist anlegen nur um danach for_each aufrufen zu können, ich kenne das argument der leute die das machen "am ende dürfte ein guter compiler daraus genau das selbe machen wie wenn ich die variable normal anlege"... imho ist das genau so unsinnig wie für alle member immer this-> davor zu schreiben.
genauso wenig hat es sinn mehrere threads zu haben die daten umlagern für die sequentielle abarbeitung im hauptthread, so wie das viele spiele machen.ich würde mir keinen dualcore kaufen wenn ich nicht überzeugt wäre, dass threads bzw parallelisierung sehr sinnvoll ist, aber es gibt halt nen großen unterschied zwischen nützlich und sinnvoll.
aber vielleicht versteh ich deine seite auch nicht, was wäre denn daran sinnvoller folgendes zu tun
im extra thread: aus dem OS-tcp buffer daten in den lokalen tcp-buffer kopieren
im main thread: daten aus dem lokalen tcp-buffer auswerten und weiter verarbeiten...statt:
im main thread: daten aus dem OS-tcp buffer in den lokalen tcp-buffer kopieren, auswerten und weiter zu verarbeiten...
nehmen wir mal an das spiel hat als zielsystem ne singlecore cpu wie es die meisten spiele haben bis jetzt noch hatten.
rapso->greets();
-
Die Abläufe sind größtenteils unabhängig voneinander. Nur an wenigsten Stellen müssen die Aufgaben synchronisiert werden. Also ist es doch eigentlich natürlicher das als Thread zu strukturieren, als es künstlich in einen festen Ablauf reinzudrücken, der rein künstlich ist.
Sachen auf Threads aufzuteilen ist eine weitere Entwurfsfreiheit. Ich kann damit Abläufe modellieren.
Selbstverständlich halte ich es nicht sinnvoll etwas nur zu benutzen weil es das gibt. Daß Du davon ausgehst... naja... is mir auch egal.
edit: oh, falsch gelesen, Dein "wir sind uns nicht einig" steht ja früher im Text... Wir sind uns also nicht einig, daß OOP was Sinnvolles ist. Damit können wir uns das natürlich alles sparen.. mein Argument geht natürlich in die gleiche Richtung der Abstraktion, die auch OOP mit sich bringt. Wenn das für Dich kein Argument ist, dann bei der Sache mit den Threads natürlich auch nicht.
-
Jester schrieb:
Die Abläufe sind größtenteils unabhängig voneinander. Nur an wenigsten Stellen müssen die Aufgaben synchronisiert werden. Also ist es doch eigentlich natürlicher das als Thread zu strukturieren, als es künstlich in einen festen Ablauf reinzudrücken, der rein künstlich ist.
Sachen auf Threads aufzuteilen ist eine weitere Entwurfsfreiheit. Ich kann damit Abläufe modellieren.
daten eingabe->verarbeitung->ausgabe ist sequentiell, wenn man die daten eingabe bzw ausgabe in einen anderen thread stellt, der dann eine "virtuelle" dateneingabe für den hauptthread erstellt, sind es keine voneinander unabhängige abläufe, sondern ein ablauf der auf viele threads aufgeteilt wird, die sich sequentiell verhalten und auf singlecores absolut kein performance+ bringen, eher sogar das gegenteil.
edit: oh, falsch gelesen, Dein "wir sind uns nicht einig" steht ja früher im Text... Wir sind uns also nicht einig, daß OOP was Sinnvolles ist. Damit können wir uns das natürlich alles sparen.. mein Argument geht natürlich in die gleiche Richtung der Abstraktion, die auch OOP mit sich bringt. Wenn das für Dich kein Argument ist, dann bei der Sache mit den Threads natürlich auch nicht.
jup, so ist das leider. ich würde kein OOP benutzen, auch wenn es abstrahierter ist, wenn es anderen lösungen gegenüber soviele nachteile hat, dass es nicht sinnvoll ist.
rapso->greets();