PC-Update: Entscheidungshilfen
-
rapso schrieb:
die meisten spiele benutzen ein paar threads, einfach weil die programmierer zu lazy sind um die verwaltung von z.b. netzwerk und sound selber richtig zu sheudlen
Und ich dachte, daß sei einer ger großen Gründe für Threads, daß man die Sachen nämlich nicht "richtig handeln" muß, sondern parallele Abläufe auch einfach parallel beschreiben kann.
rapso schrieb:
, aus diesem grund laufen die spiele ein wenig fixer, aber aufgrund dessen, dass sie die threads meist nicht an die cpus binden, haben sie dann verlust an leistung, aber mit den aufkommenden patches hollen die das nach.
Eigentlich ist es doch gut, das nicht an ne CPU zu binden. Ist schließlich Aufgabe des OS und nicht der Programme selbst.
-
Jester schrieb:
rapso schrieb:
die meisten spiele benutzen ein paar threads, einfach weil die programmierer zu lazy sind um die verwaltung von z.b. netzwerk und sound selber richtig zu sheudlen
Und ich dachte, daß sei einer ger großen Gründe für Threads, daß man die Sachen nämlich nicht "richtig handeln" muß, sondern parallele Abläufe auch einfach parallel beschreiben kann.
auf singlecores läuft das nicht parallel und trotzdem haben viele leute threads verwendet, was relativ sinnlos ist/war. daten die per netzwerk ankommen und von einem thread empfangen werden, werden irgendwo in eine queue geschoben bis der hauptthread soweit ist sie zu verarbeiten, diese daten werden also aus der queue vom OS in eine eigene verschoben anstatt sie vom MainThread gleich von dort abzuhollen -> unnützer overhead.
IBM hat darüber irgendwo paper bei dem sie beide vorgehensweisen anhand eines sql-servers gegeneinander getestet hatten und die doppelte queue mit unnützen threads war unterlegen.aber wie gesagt, das ist sehr viel einfacher zu realisieren.
und ja, für den sound gilt das selbe, die hardware IRQs laden sich die buffer schon zur richtigen zeit, es ist unnütz dafür noch einen extra thread zu haben.
Jester schrieb:
rapso schrieb:
, aus diesem grund laufen die spiele ein wenig fixer, aber aufgrund dessen, dass sie die threads meist nicht an die cpus binden, haben sie dann verlust an leistung, aber mit den aufkommenden patches hollen die das nach.
Eigentlich ist es doch gut, das nicht an ne CPU zu binden. Ist schließlich Aufgabe des OS und nicht der Programme selbst.
afaik ist das problem ist, dass das os versucht beide cpus gleichmässig auszulasten, dadurch wird wird der hauptprozess hin und her geschoben, das resultat davon ist dann auch, dass der ganze cache dauernt umgelagert werden muss (zwischen den cpus). dieser overhead ist wohl ziemlich hoch, auf jedenfall gibt es patches bei denen die processe dann an cpus gebunden werden und man dann sagen hafte 20% leistung dazubekommt *lol*
ich such ma ob ich ne patchbeschreibung dazu finde
rapso->greets();
[edit]
so eine patchbeschreibung find ich nicht auf anhieb, aber ne probembeschreibung von anderen die praktische erfahrungen damit haben
-
-
Cpp_Junky schrieb:
Sgt. Nukem schrieb:
Achja, was bei ASUS geil ist: Das easy anpassbare BIOS Startbild!
...Die Dinger kann man ändern ?
Wie haste das gemacht ? Wird wohl kaum auf der Festplatte liegen oder ?Nö. Wird ins BIOS "einkompiliert".
Das lustige ist, daß bei den neueren Updates wohl mehr Funktionen zur Verfügung stehen, und daher weniger Speicher für das Bild. Daher mußt Du das dann noch kleiner machen.Das Tool heißt glaub' ich ASUS MyLogo! oder so...
-
rapso schrieb:
auf singlecores läuft das nicht parallel und trotzdem haben viele leute threads verwendet, was relativ sinnlos ist/war.
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.
rapso schrieb:
afaik ist das problem ist, dass das os versucht beide cpus gleichmässig auszulasten, dadurch wird wird der hauptprozess hin und her geschoben, das resultat davon ist dann auch, dass der ganze cache dauernt umgelagert werden muss (zwischen den cpus). dieser overhead ist wohl ziemlich hoch, auf jedenfall gibt es patches bei denen die processe dann an cpus gebunden werden und man dann sagen hafte 20% leistung dazubekommt *lol*
Dann ist das scheduling vom OS scheiße. Die Cache-Umlagerung sollte man natürlich beim Entwurf der Scheduling-Strategie beachten. Das wird sich aber hoffentlich auch bald ändern, sodaß solche Anpassungen vermutlich bald Geschichte sind.
-
Jester schrieb:
Dann ist das scheduling vom OS scheiße. Die Cache-Umlagerung sollte man natürlich beim Entwurf der Scheduling-Strategie beachten. Das wird sich aber hoffentlich auch bald ändern, sodaß solche Anpassungen vermutlich bald Geschichte sind.
Ja, vermutlich schon in der übernächsten Version von Windows. So 2010 schätze ich...
-
grad keine zeit den thread ganz durchzulesen aber hier findet ihr viele Noiseless bauteile und optische schmanckerl:
www.case-king.de
-
"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();