kann man einen thread splitten?

[saaya]

ist es, wenn auch noch so theoretisch, vorstellbar einen thread zu splitten so dass zwei cores oder ein dual core prozessor an einem einzigen thread arbeitet?

zumindestens vom pentium4 weiss ich dass in der pipeline 32bit aufgaben in zwei 16bit aufgaben geteilt werden, ist das nicht eventuell auch mit einem kompletten thread moeglich?

szusagen umgekehrtes hyper threadding :D

[saaya]

und wenn nein bitte erklaeren wieso nicht ^^ danke! :D

[Gast]

ist es, wenn auch noch so theoretisch, vorstellbar einen thread zu splitten so dass zwei cores oder ein dual core prozessor an einem einzigen thread arbeitet?Wenn nur ein Thread vorhanden ist, dann kann man daraus nicht einfach zwei machen.

Ein Thread ist ein Programm, also eine Folge von Befehlen, die von der CPU nacheinander ausgeführt wird. Zwei Threads sind eben zwei Folgen von Befehlen, die parallel ausgeführt werden (können). Diese beiden Ströme müssen extra programmiert werden. Ohne dass der Programmierer sich hier Arbeit macht und die Abarbeitung seines Programms auf mehrere Threads verteilt, ist es schwer möglich das im Nachhinein noch automatisiert zu verändern.
Der Aufwand dafür stände in keinem Verhältnis zu der erwartenden Beschleunigung.
zumindestens vom pentium4 weiss ich dass in der pipeline 32bit aufgaben in zwei 16bit aufgaben geteilt werdenDas sind einzelne Arithmetik-Berechnungen, keine Threads.

[GloomY]

Obiges stammt von mir... :)

[Lyf]

ist es, wenn auch noch so theoretisch, vorstellbar einen thread zu splitten so dass zwei cores oder ein dual core prozessor an einem einzigen thread arbeitet?

zumindestens vom pentium4 weiss ich dass in der pipeline 32bit aufgaben in zwei 16bit aufgaben geteilt werden, ist das nicht eventuell auch mit einem kompletten thread moeglich?

szusagen umgekehrtes hyper threadding :D

Wie Gloomy schon sagte, nein.

Aber zu einem kleinen Teil passiert das ja in vielen modernen CPUs. Die berechnen parallel mehrere Befehle aus dem aktuellen Thread gleichzeitig, die eigentlich aufeinander folgen, um die verschiedenen Funktionseinheiten voll auszulasten. Das ganze nennt sich out of order execution, ist aber wahnsinnig komplex, da die CPU die ganzen Abhängigkeiten beachten muss, und Sachen spekulativ berechnet und sie dann verwirft etc. Klappt aber im besten Falle (manchmal kann man auch gar nicht parallelisieren) nur einer bei einer Tiefe von vielleicht einigen Dutzend Befehlen (kenne die aktuellen Zahlen nicht).
Eine Aufspaltung dessen auf mehrere Cores geht da einfach nicht, weil der Kommunikationsaufwand (Pipelinezustand, Register) viel zu gross ist und kleine Verzoegerung hier total wichtig sind um einen Performancevorteil zu haben.

Lyf

[saaya]

es ist also nicht moeglich die verschiedenen schritte die eine cpu abarbeiten muss um einen thread zu berechnen auf zwei cpus oder zwei cores verteilt werden?

danke fuer die antworten bis jetzt! :D

[nino]

es ist wahrscheinlich unmöglich, weil du den "geteilten" thread ja auch zwischen den beiden cores synchronisieren musst, was wohl n bissel umständlich ist

[Stone2001]

hmm, ich glaube kaum, das sowas implemtierbar ist, da z.b. ein Core auf die Register des anderen Cores zugreifen können müßte. Das Ganze über Busse zu erledigen, dürfte wohl Verschwendung von Chipfläche sein. Da sind superskalare Prozessoren wesentlich effektiver (die ja im Prinzip das Gleiche machen).

[saaya]

also kann man aus einem komplexen thread nicht zwei weniger komplexe threads machen? hmmm schade :D

[HellHorse]

Wenn nur ein Thread vorhanden ist, dann kann man daraus nicht einfach zwei machen.
Also zumindest theoretisch sollte es zum Teil je nach Programmiersprache gehen.
Beispiel (Scheme)

(let (
(a (....))
(b (....))
(c (....)))
(etwas a b c))

Hier liessen sich die Berechnung von a, b und c parallelisieren. Es wäre also theoretisch möglich, einen neuen Thread aufzumachen dort b zu berechnen und im aktuellen a. Wer zuerst fertig ist, berechnet dann c. Wie schon gesagt: in der Theorie.
Das Dumme ist natürlich wenn es ahead-of-time in nativen Code übersetzt fallen solche Strategien von Anfang an flach.

Und so wie ich es verstanden habe, sollten sich actor-based Programmiersprachen parallelisieren lassen, aber da kann ich mich auch täuschen.

[saaya]

jetzt machen dual cores auf einmal viel mehr sinn :D

und wie gut ist es moeglich einen compiler zu schreiben der threads so wie du es erwaehnst in verschiedene threads splittet? dass das nicht mit allen threads geht ist ja nicht so wichtig, auch wenns nur bei jedem 3ten geht bringt es ja einen performence zuwachs.

bei wie vielen threads (prozentual ,im schnitt) laesst sich oben beschriebenes anwenden?

[GloomY]

Ich glaube, das bringt nichts. Auf OS-Ebene kommt noch so mancher Aufwand hinzu, welcher mit dem Thread-Erzeugen, -Verwalten und -Beenden zu tun hat. Wenn du nicht wirklich große Code-Abschnitte parallelisierst, wirst du keinen Geschwindigkeitsgewinn sondern eher einen -Verlust bekommen.

Ansonsten wäre das ja die Lösung und wäre schon längst implementiert. ;)

[Stone2001]

Ich glaube, das bringt nichts. Auf OS-Ebene kommt noch so mancher Aufwand hinzu, welcher mit dem Thread-Erzeugen, -Verwalten und -Beenden zu tun hat. Wenn du nicht wirklich große Code-Abschnitte parallelisierst, wirst du keinen Geschwindigkeitsgewinn sondern eher einen -Verlust bekommen.

Ansonsten wäre das ja die Lösung und wäre schon längst implementiert. ;)
Den Gedanken hatte ich auch gerade!
Wenn die Blöcke zu klein sind, das überwiegt der Overhead der Threaderverwaltung (einen Thread zu erstellen, dauert bei WinNT 4.0 ca. 1200 Zyklen). Was eventuell noch dazukommt, ist das man den Zugriff auf gemeinsame Variablen verwalten muß.
Wenn die recht groß sind, ..., naja, dann kann man sie ja auch gleich selber parallelisieren.

Das Konzept von HellHorse erinnert mich ziehmlich stark an die parallele Programmierung mittels OpenMP. ;)

[saaya]

hmmm ich dachte nur dass dies vieleicht der fehlende stein im puzzle der dual core desktop cpus ist, denn was bringen einem dual core cpus in einem desktop universum welches hauptsaechlich auf single thread applikationen basiert?

ich hatte gehofft dass man gleich sli oder amr eventuell einen neuen weg gefunden haben koennte die cpu last sinnvoller auf zwei cpus zu verteilen.

aber die derzeiten betriebsysteme und der ausgefuehrte code lassen das momentan nicht zu?

aber frueher oder spaeter muss es doch in diese richtung gehen, oder? parallelisierung ist doch der begriff der unser derzeitiges rechenzeitalter am besten beschreibt.

die wichtigsten letzen evolutions schritte der rechner

double data rate speicher
hyper threadding
dual channel memory
quad data rate speicher (ddr2 und qdr/qdr2)
double/multi display technologie
sli
amr
dual core cpus


also ist schon abzusehen wann und wie in zukunft threads organisiert werden? ist schon geplant und absehbar wie in zukunft threads gesplittet werden? oder wird in zukunft wahrscheinlich einfach immer mehr multithread code den singlethread code verdraengen?

[Demirug]

Ich habe das schon in einem anderen Thread gepostet aber hier passt es wohl noch besser:

http://www-hydra.stanford.edu/

[Stone2001]

hmmm ich dachte nur dass dies vieleicht der fehlende stein im puzzle der dual core desktop cpus ist, denn was bringen einem dual core cpus in einem desktop universum welches hauptsaechlich auf single thread applikationen basiert?
hmm, ich glaube in 2 bis 3 Jahren, wird sich diese Frage nicht mehr stellen. ;)Dual-Core-CPUs haben ihre daseinsberechtigung in dem Bereich, in dem eine CPU nicht mehr ausreicht. Wenn man z.b. Videos aufnimmt, kann man eine zweite CPU gut gebrauchen (die erste nimmt das Bild auf, die zweite den Ton). Oder die erste nimmt das Video auf und die zweite steht für sonstige Tasks zu Verfügung.

ich hatte gehofft dass man gleich sli oder amr eventuell einen neuen weg gefunden haben koennte die cpu last sinnvoller auf zwei cpus zu verteilen.

aber die derzeiten betriebsysteme und der ausgefuehrte code lassen das momentan nicht zu?
hmm, das Betriebssystem würde sowas schon zulassen, die meisten modernen Betriebsyssteme können mit mehreren CPUs umgehen. Am Code könnte es vielleicht scheitern, da die meisten Programme sich leider nur sehr schlecht parallelisieren lassen.

die wichtigsten letzen evolutions schritte der rechner in chronologischer reihenfolge

double data rate speicher
hyper threadding
dual channel memory
quad data rate speicher (ddr2 und qdr/qdr2)
double/multi display technologie
sli
amr
dual core cpus

Ich würde das "chronologisch" sehr schnell wieder streichen! ;) Dual Channel Memory kam lange von DDR-Speicher. Multidisplay ist auch schon uralt. Und SLI gab es schon, da hat man an DDR-Speicher noch geforscht.

oder wird in zukunft wahrscheinlich einfach immer mehr multithread code den singlethread code verdraengen?
Naja, die meisten Programme werden Singlethreaded bleiben, das es sich für diese Programme nicht lohnt mehrere Threads zu benutzen. Aber rechenintensive Programme (z.b. Spiele) werden über kurz oder lang sicherlich von Dual-Cores profitieren.

[Gast]

ja, z.b. in dem der eine core die physik und KI berechnet und der andere die engine, also den teil den nicht die grafikkarte berechnet

[saaya]

Ich habe das schon in einem anderen Thread gepostet aber hier passt es wohl noch besser:

http://www-hydra.stanford.edu/

hmmm interessant :)

was ist eigentlich mit der ps3 und der xbox2? beide basieren auf mind 2 cpus, wahrscheinlich sogar 4! beides sind spiele konsolen! also muss es doch einen weg geben spiele eindeutig multithreadded zu schreiben.

da die xbox2 auch auf einem windows os basiert darf es doch eigentlich nicht oder wenn ja dann nicht grundlegend am os liegen. und da die xbox2 dem pc sehr sehr aehnlich ist muesste es doch moeglich sein eine multi core optimierung fuer spiele, also single threaded applikationen, worin auch immer sie besteht, auf den pc zu uebertragen. oder?



hmm, ich glaube in 2 bis 3 Jahren, wird sich diese Frage nicht mehr stellen. ;)Dual-Core-CPUs haben ihre daseinsberechtigung in dem Bereich, in dem eine CPU nicht mehr ausreicht. Wenn man z.b. Videos aufnimmt, kann man eine zweite CPU gut gebrauchen (die erste nimmt das Bild auf, die zweite den Ton). Oder die erste nimmt das Video auf und die zweite steht für sonstige Tasks zu Verfügung.
naja! ueberleg mal genauer! ein intel x30 wird ein dual core prescott mit 3.2ghz takt sein, also wird er in spielen kaum schneller als ein derzeitiger 3.2ghz prescott sein! es wird bis zu dessen einfuehrung einen prescott mit 2mb L2 cache und mind 3.8ghz takt geben, also bedeutet ein dual core prozessor hier doch einen rueckschritt! und es ist nunmal fakt dass desktop prozessoren vorallem eins koennen muessen, spiele gut spielen zu koennen!

ich wage stark zu bezweifeln dass sich leute fuer eine dual core cpu entscheiden die zu dessen einfuehrung beinahe das doppelte kosten wird wie eine single core cpu die in ca. der haelfte der applikationen, und besonders in spielen, genauso schnell wenn nicht sogar schneller ist! und dazu kommt noch dass ein dual core prozessor eine neue plattform benoetigt, eventuell sogar ein neues netzteil! dieser drang einen desktop dual core prozessor herauszubringen ist deshalb ein raetsel fuer mich was sich erklaeren liesse wenn man auch single thread applikationen mit zwei prozessoren irgendiwe schneller ausfuehren koennte. eine 50%tige performence steigerung mit zwei prozessoren anstelle von einem in single thread applikationen wuerde ja locker reichen um dual core desktop cpus attraktiv genug zu machen dass sich niemand mehr fuer single core cpus interessiert.

und bei amd siehts schlimmer aus!

die dual core desktop cpus werden so weit ich weiss mit 1.4 1.6 und 1.8ghz starten! das heisst doch dass selbst ein athlon64 3000+ in single thread applikationen genausoschnell oder sogar schneller (!) als ein 1.8ghz dual core prozessor sein wird! im fazit heisst das doch dass dual core cpus fuer ueber 90% der desktop anwender keine oder kaum performence steigerungen bringen, denn alle welt spielt, video encoden ist schoen und gut, aber holt man sich dafuer eine neue cpu? 90% der desktop user sicherlich nicht!

aber eine alternative zu den dual core cpus von intel und amd gibt es nicht! und ich kann mir einfach nicht vorstellen dass die cpu performence in spielen und anderen single thread applikationen fuer ein jahr oder laenger praktisch stehen bleiben wird. das waere doch fatal!



Ich würde das "chronologisch" sehr schnell wieder streichen! ;) Dual Channel Memory kam lange von DDR-Speicher. Multidisplay ist auch schon uralt. Und SLI gab es schon, da hat man an DDR-Speicher noch geforscht. schon geschehen :D

Naja, die meisten Programme werden Singlethreaded bleiben, das es sich für diese Programme nicht lohnt mehrere Threads zu benutzen. Aber rechenintensive Programme (z.b. Spiele) werden über kurz oder lang sicherlich von Dual-Cores profitieren.
aber wie? werden die spiele dann mit mehreren threads laufen?

es muss doch moeglich sein beide prozessoren zu nutzen, auch wenn man nur einen thread hat... hmmmmm *gruebel*

[Muh-sagt-die-Kuh]

da die xbox2 auch auf einem windows os basiert darf es doch eigentlich nicht oder wenn ja dann nicht grundlegend am os liegen. und da die xbox2 dem pc sehr sehr aehnlich ist muesste es doch moeglich sein eine multi core optimierung fuer spiele, also single threaded applikationen, worin auch immer sie besteht, auf den pc zu uebertragen. oder?Wieso sollte es am OS liegen? Die Aufteilung von Thread ist einzig und allein Sache des Anwendungsprogrammierers.aber eine alternative zu den dual core cpus von intel und amd gibt es nicht! und ich kann mir einfach nicht vorstellen dass die cpu performence in spielen und anderen single thread applikationen fuer ein jahr oder laenger praktisch stehen bleiben wird. das waere doch fatal!Wo steht, dass beide keine Single-Core CPUs mehr fertigen / entwickeln werden?es muss doch moeglich sein beide prozessoren zu nutzen, auch wenn man nur einen thread hat... hmmmmm *gruebel*Nein, das ist prinzipiell nicht möglich. Der Entwickler muss Multithreading explizit bei der Entwicklung berücksichtigen damit wirklich etwas dabei herauskommt....

Der Intel C++ Compiler als Beispiel bietet zwar eine Option /Qparallel die bei Single-Threaded Anwendungen versucht große Schleifen automatisch in Threads aufzuspalten.....das ganze funktioniert nach eigenen Tests ganz passabel, viel gewinnt man aber nicht. Wenn ihr wollt kann ich die Zahlen gerne hier posten.

[GloomY]

ja, z.b. in dem der eine core die physik und KI berechnet und der andere die engine, also den teil den nicht die grafikkarte berechnetDas muss man dann aber von vorne herein so programmieren. Im Nachhinein das noch (zur Laufzeit?) zu ändern, ist sehr viel schwieriger, wenn nicht sogar unmöglich.
Ich habe das schon in einem anderen Thread gepostet aber hier passt es wohl noch besser:

http://www-hydra.stanford.edu/Ich weiss, dass du das auch schon mal anderswo erwähnt hast hast, aber imho ist das doch nur ein Projekt, oder gibt es schon ein Tape-Out?

[saaya]

Das muss man dann aber von vorne herein so programmieren. Im Nachhinein das noch (zur Laufzeit?) zu ändern, ist sehr viel schwieriger, wenn nicht sogar unmöglich.
Ich weiss, dass du das auch schon mal anderswo erwähnt hast hast, aber imho ist das doch nur ein Projekt, oder gibt es schon ein Tape-Out?

wuerd mich auch interessieren, immerhin haben die doch schon 96 oder 97 angefangen und das ist schon fast 8 jahre her... und grossartig woanders was darueber gehoert hab ich bis jetzt noch nicht :/

[Stone2001]

hmmm interessant :)
naja! ueberleg mal genauer! ein intel x30 wird ein dual core prescott mit 3.2ghz takt sein, also wird er in spielen kaum schneller als ein derzeitiger 3.2ghz prescott sein! es wird bis zu dessen einfuehrung einen prescott mit 2mb L2 cache und mind 3.8ghz takt geben, also bedeutet ein dual core prozessor hier doch einen rueckschritt! und es ist nunmal fakt dass desktop prozessoren vorallem eins koennen muessen, spiele gut spielen zu koennen!

ich wage stark zu bezweifeln dass sich leute fuer eine dual core cpu entscheiden die zu dessen einfuehrung beinahe das doppelte kosten wird wie eine single core cpu die in ca. der haelfte der applikationen, und besonders in spielen, genauso schnell wenn nicht sogar schneller ist! und dazu kommt noch dass ein dual core prozessor eine neue plattform benoetigt, eventuell sogar ein neues netzteil! dieser drang einen desktop dual core prozessor herauszubringen ist deshalb ein raetsel fuer mich was sich erklaeren liesse wenn man auch single thread applikationen mit zwei prozessoren irgendiwe schneller ausfuehren koennte. eine 50%tige performence steigerung mit zwei prozessoren anstelle von einem in single thread applikationen wuerde ja locker reichen um dual core desktop cpus attraktiv genug zu machen dass sich niemand mehr fuer single core cpus interessiert.

und bei amd siehts schlimmer aus!

die dual core desktop cpus werden so weit ich weiss mit 1.4 1.6 und 1.8ghz starten! das heisst doch dass selbst ein athlon64 3000+ in single thread applikationen genausoschnell oder sogar schneller (!) als ein 1.8ghz dual core prozessor sein wird! im fazit heisst das doch dass dual core cpus fuer ueber 90% der desktop anwender keine oder kaum performence steigerungen bringen, denn alle welt spielt, video encoden ist schoen und gut, aber holt man sich dafuer eine neue cpu? 90% der desktop user sicherlich nicht!

aber eine alternative zu den dual core cpus von intel und amd gibt es nicht! und ich kann mir einfach nicht vorstellen dass die cpu performence in spielen und anderen single thread applikationen fuer ein jahr oder laenger praktisch stehen bleiben wird. das waere doch fatal!

Ich persönliche gehe davon aus, das Dual-Core-CPU in den nächsten 2 Jahren nur etwas für High-Performance Workstations und Leute mit zu viel Geld sind.
Und ja, ich gehe auch davon aus, das normale CPUs bis dahin in den meisten Anwendungen wesentlich schneller sein werden als Dual-Cores.
AMD wollte ja ursprünglich die Dual-Cores nur für den Servermarkt oder für Höchstleistungsrechner herausbringen. Dort machen sie auch wirklich Sinn. Dort profiitert man davon. Auf den Desktopmarkt wollte AMD so schnell nicht, weil sie dort kein Bedürftnis dafür gesehen haben. Warum Intel jetzt mit dem Smithfield dort hineindrückt, bleibt mir ein Rätsel!
Und BTW wenn die Preise, die gereade im Gespräch für die Dual-Cores sind, stimmen, werden sich die Dual-Core CPUs so schnell sowieso nicht durchsetzen.

aber wie? werden die spiele dann mit mehreren threads laufen?

Yup, ich denke, das es durchaus möglich ist, ein Spiel in mehrere Threads zu zerlegen.

es muss doch moeglich sein beide prozessoren zu nutzen, auch wenn man nur einen thread hat... hmmmmm *gruebel*
Ich habe mir gerade mal das Hydra-Projekt angeschaut. Interessant, das muß ich zugeben. Das ganze hört sich für mich an, wie ein multiskalarer Prozessor, ein Ansatz, den es schon von ca. 10 Jahren gab, sich aber nie wirklich durchgesetzt hat. Da war Multithreading effektiver.
Aber wenn sie wirklich einen Compiler entwickeln, der es ermöglicht, einzelne Codeblöcke (eventuell Basisblöcke) auf verschiedene CPUs zu verteilen, dann hast du das, was du eigentlich willst. Ob es dann allerdings sinnvoll ist, sowas auf Dual-Cores loszulassen, ist eine andere Frage!

[saaya]

Wo steht, dass beide keine Single-Core CPUs mehr fertigen / entwickeln werden?

hmmm also meinst due die dual cores werden nur einen neues high end bilden so wie die fx und ee cpus heute? hmmm so hab ichs noch garnicht geshen.

es wird so viel von den dual cores berichtet und nichts von anderen single core designs... ausserdem hat zumindestens amd gesagt dass sie dual cores fuer die breite masse anstreben...

naja aber auch da ist dann halt die frage in welchem zeitraum...
und bei intel hab ich nur geshen dass das lakeport chipset mitte 05 eingefuehrt wird und 915 und 925 von der roadmap verschwindet. bisher hab ich nur davon gehoert dass lakeport ein dual core chipset ist, aber es kann bestimmt auch mit single core chips laufen... hmmm

hab mich wohl gedanklich ein bisschen vom dual core hype mitreissen lassen ^^

aber wie gesagt, man hoert ja auch nichts anderes mehr von intel udn amd... alle zukuenftigen designs von denen ich gehoert habe sind dual core cpus...


Das ganze hört sich für mich an, wie ein multiskalarer Prozessor, ein Ansatz, den es schon von ca. 10 Jahren gab das projekt ist ja auch fast 10 jahre alt ^^

[HellHorse]

Ich glaube, das bringt nichts. Auf OS-Ebene kommt noch so mancher Aufwand hinzu, welcher mit dem Thread-Erzeugen, -Verwalten und -Beenden zu tun hat.
Da sehe ich eher weniger das Problem. Der Compiler könnte ja eine globale Variable mit einen Arbeitsthread machen und dem die Aufgabe übergeben, statt bei jedem let einen aufzutun. Wie schon gesagt, in der Theorie. Und da sehe ich das wirkliche Problem, das ist alles bloss ein Gedankenexperiment. Mal abgesehen davon, all die Leute dazu zu bringen, von C++ auf LISP umzusteigen.

Braucht noch jemand ein Thema für eine Masterarbeit? :D

[Demirug]

Da sehe ich eher weniger das Problem. Der Compiler könnte ja eine globale Variable mit einen Arbeitsthread machen und dem die Aufgabe übergeben, statt bei jedem let einen aufzutun. Wie schon gesagt, in der Theorie. Und da sehe ich das wirkliche Problem, das ist alles bloss ein Gedankenexperiment. Mal abgesehen davon, all die Leute dazu zu bringen, von C++ auf LISP umzusteigen.

Braucht noch jemand ein Thema für eine Masterarbeit? :D

Wieso Theorie? In .Net ist ein sogenannter ThreadPool eingebaut der genau für sowas da ist. Auch der Job Dispatcher in der Engine an der ich arbeite nutzt ein solches Konzept.

[saaya]

heisst dass es werden also alle aufgaben die erledigt werden muessen immer wieder in inetwa gleich grosse "thread buendel" geschnuert oder wie darf ich mir das (als laie) vorstellen? ^^

also werden aufgaben gesammelt und dann wird darau ein thread gemacht der dann laeufft, und dann wird wieder gesammelt bis eine bestimmte menge arbeit von verschiedenen teilen der engine kommen und daraus wird dann wieder ein einziger thread gemacht?

das keonnte man doch dann auch so schrieben dass halt immer zwei threads daraus gemacht werden bzw dass die arbeit so verteilt wird dass immer beide cpus gerade noch an einem thread arbeiten...

und jetzt bitte die antwort, wie wenig hab ich verstanden und wie wenig sinn macht das was ich mir gerade zusammengebastelt habe ;D

[Gast]

heisst dass es werden also alle aufgaben die erledigt werden muessen immer wieder in inetwa gleich grosse "thread buendel" geschnuert oder wie darf ich mir das (als laie) vorstellen? ^^

also werden aufgaben gesammelt und dann wird darau ein thread gemacht der dann laeufft, und dann wird wieder gesammelt bis eine bestimmte menge arbeit von verschiedenen teilen der engine kommen und daraus wird dann wieder ein einziger thread gemacht?

das keonnte man doch dann auch so schrieben dass halt immer zwei threads daraus gemacht werden bzw dass die arbeit so verteilt wird dass immer beide cpus gerade noch an einem thread arbeiten...

und jetzt bitte die antwort, wie wenig hab ich verstanden und wie wenig sinn macht das was ich mir gerade zusammengebastelt habe ;D
Die Threads werden in Multitasking verfahren verteilt, ähnlich den Programmen.
So groß ist der Vorteil nicht. Bei Beos wurde zu Anfang Threading großgeschrieben: der ganze Kernel/OS soll komplett multithreaded geschrieben sein und Intel hat es hochgepusht. In der Realität gab es kein Geschwindigkeitsvorteil, aber das System läuft flüssiger.
Wie es heute ausschaut mit BeOs und P4 mit HTT weiss ich nicht so genau.

[Demirug]

heisst dass es werden also alle aufgaben die erledigt werden muessen immer wieder in inetwa gleich grosse "thread buendel" geschnuert oder wie darf ich mir das (als laie) vorstellen? ^^

also werden aufgaben gesammelt und dann wird darau ein thread gemacht der dann laeufft, und dann wird wieder gesammelt bis eine bestimmte menge arbeit von verschiedenen teilen der engine kommen und daraus wird dann wieder ein einziger thread gemacht?

das keonnte man doch dann auch so schrieben dass halt immer zwei threads daraus gemacht werden bzw dass die arbeit so verteilt wird dass immer beide cpus gerade noch an einem thread arbeiten...

und jetzt bitte die antwort, wie wenig hab ich verstanden und wie wenig sinn macht das was ich mir gerade zusammengebastelt habe ;D

Das ganze läuft so ab das man alle Aufgaben die erledigt werden müssen in eine Liste einträgt. Diese Liste wird dann von einem oder mehren Threads (deswegen Pool) abgearbeitet. Dadurch kann solange genügend Jobs in der Liste immer jede CPU mit Arbeit versorgt werden. Man muss jedoch aufpassen das man die Jobs nicht zu klein macht weil sonst der Verwaltungsoverhead im Verhältniss dazu zu gross wird. Automatisch geht das ganze natürlich auch nicht sondern erfordert ein Umdenken bei der Programmentwicklung.

[Jesus]

hmmm interessant :)

was ist eigentlich mit der ps3 und der xbox2? beide basieren auf mind 2 cpus, wahrscheinlich sogar 4! beides sind spiele konsolen! also muss es doch einen weg geben spiele eindeutig multithreadded zu schreiben.*

http://www.bringyou.to/games/PS2.htm

Hier ist mal ein recht intressanter (wie ich finde) Artikel zur PS2 Architektur. Weiter unten wird auch anhand des Spiels State of Emergency ein bischen was über die Parallisierung und die VUs (Vector Units) geschrieben, sowie die Schwierigkeiten das Game dann hinterher auf die Xbox zu konvertieren...

[HellHorse]

Wieso Theorie? In .Net ist ein sogenannter ThreadPool eingebaut der genau für sowas da ist. Auch der Job Dispatcher in der Engine an der ich arbeite nutzt ein solches Konzept.
Theorie bezog sich auf das concurrent-let.

[Demirug]

Theorie bezog sich auf das concurrent-let.

Achso. Ja sowas gibt es AFAIK wirklich noch nicht.

[saaya]

danke fuer die antworten! :)

also ist die engine an der du arbeitest in der lage auf ht oder dual core cpus die volle cpu leistung auszunutzen, oder zumindestens dem nahe zu kommen?

ist es denn SEHR umsteandlich ein spiel so zu programmieren? was wuerdest du sagen wie lange es dauert bis alle neuen spiele multithreadded sind? koennen wir damit demnaechst rechnen oder dauert das noch ein paar jahre?

danke fuer den ps2 link :up:
aber ich meinte doch ps3 die auf cell architektur und damit mehreren cpus basieren wird, deswegen multithreadding...

btw, ms will ja auch pcs die auf der xbox2 architektur basieren rausbringen, plant sony da aehnliches? von cell basierten servern hab ich sony schon sprechen gelesen (lol :D) aber was ist mit desktop rechnern? hast du was davon gehoert?