Archiv verlassen und diese Seite im Standarddesign anzeigen : Kann man dynamisches uneingeschränktes Multithreading programmieren?
Mastermind
2006-08-12, 16:52:18
Mich nervt diese ständige Hinterherhinkerei der Software. Nicht genug damit, dass heutige Programme und vor allem Spiele meist nicht bugfrei daherkommen, von guter Optimiertung gar nicht zu sprechen, aber sie nutzen die Hardware auch nicht richtig aus.
Nun sind wir auf dem Weg zu immer mehr Cores in den Prozessoren und die Software ist darauf nicht ausgelegt. Das Problem was wir jetzt beim Sprung (eher Kriechen) auf Dualcore erleben, wird vielleicht auch beim Übergang auf Quad-Core wiederkommen. Irgendwann dann beim Okta-Core u.s.w. Also frage ich mich, ob man nicht wenigstens dem Problem für alle Zeiten beikommen könnte, in dem man Software generell so programmiert, dass sie einfach so viele Threads erstellt wie Cores vorhanden sind. Ist das programmiertechnisch möglich/unmöglich/problematisch?
Und warum hat sich eigentlich mal wieder kaum einer vorher Gedanken gemacht? Manchmal frag ich mich, ob die Entwickler überhaupt was im Kopf haben? Dass Dual-Cores kommen werden, das war schon klar, als es noch keine 1GHz-Prozessoren gab.
Lightning
2006-08-12, 17:51:26
Erstmal eine kleine Anmerkung von mir: Ich finde es schon ein wenig dreist, den Entwicklern Unfähigkeit zu unterstellen, wenn man sich selber nicht ausreichend mit Materie auskennt (weil man nämlich kein Entwickler ist!), um derartige Behauptungen anzustellen.
Aber das werden dir einige Programmierer hier im Forum sicherlich besser erklären können.
Davon abgesehen denke ich auch als Laie, dass es alles andere als einfach ist, eine Software für Multicores bzw. Multiprozessorsysteme zu optmieren. Wobei das natürlich auch von der Art der Software abhängt, gerade bei Spielen dürfte es z.B. nicht so einfach sein, da man eben nicht alles beliebig parallelisieren kann.
Vor allem aber ist es quasi verschenkte Zeit, auf eine Sache zu optimieren, aus der 99% der User sowieso keinen Nutzen ziehen können. Und Zeit ist bekanntlich Geld. Das ist auf deine Aussage mit der 1GHz-Zeit bezogen.
Lightning hat das Stichwort bereits gebracht: Parallelisierung!
Möglich ist es theoretisch immer, nur oftmals nicht sinnvoll, weil die beiden Threads dann so voneinander abhängig sind, dass viel Overhead durch den Datenaustausch ensteht (oder sogar gewartet werden muss).
Gerade bei Spielen ist das IMO wirklich schwer.
Aber Leute kommt, die CPU und DC ist für die Zocker doch nicht wirklich eine Technologie die viel bringt, da es einfach zu sehr auf die GPU ankommt.
Undertaker
2006-08-12, 19:33:28
Gerade bei Spielen ist das IMO wirklich schwer.
nun, quake 4 schafft es sehr sehr gut... ;)
EgonOlsen
2006-08-12, 19:36:22
Wenn du Dinge in mehreren Threads ablaufen lassen willst, musst du mehr Aufwand bei der Synchronization der Daten zwischen diesen Threads treiben. Thread 1 darf nicht auf Daten rumhühnern, die Thread 2 gerade rendern will und ähnliches. Ohne mehrere Kerne/CPUs ist das erstmal langsamer und es ist davon abgesehen ein nicht unerheblicher Mehraufwand. Das macht keiner, wenn er nicht muss.
tokugawa
2006-08-12, 21:01:13
Mich nervt diese ständige Hinterherhinkerei der Software. Nicht genug damit, dass heutige Programme und vor allem Spiele meist nicht bugfrei daherkommen, von guter Optimiertung gar nicht zu sprechen, aber sie nutzen die Hardware auch nicht richtig aus.
Nun sind wir auf dem Weg zu immer mehr Cores in den Prozessoren und die Software ist darauf nicht ausgelegt. Das Problem was wir jetzt beim Sprung (eher Kriechen) auf Dualcore erleben, wird vielleicht auch beim Übergang auf Quad-Core wiederkommen. Irgendwann dann beim Okta-Core u.s.w. Also frage ich mich, ob man nicht wenigstens dem Problem für alle Zeiten beikommen könnte, in dem man Software generell so programmiert, dass sie einfach so viele Threads erstellt wie Cores vorhanden sind. Ist das programmiertechnisch möglich/unmöglich/problematisch?
Und warum hat sich eigentlich mal wieder kaum einer vorher Gedanken gemacht? Manchmal frag ich mich, ob die Entwickler überhaupt was im Kopf haben? Dass Dual-Cores kommen werden, das war schon klar, als es noch keine 1GHz-Prozessoren gab.
Find ich ziemlich frech was du da von dir gibst - natürlich machen sich Forscher und Entwickler Gedanken!
Allerdings ist es doch logisch: Bevor es nicht eine installierte Hardwarebasis gibt, gibt es für Spieleentwickler auch keinen Grund, die Mühe und den Aufwand auf sich zu nehmen (sind auch Kosten!).
Sobald es billige DualCores gibt (erst seit ein paar Monaten), macht es Sinn, in Spielen gut verteilt zu programmieren. Nur: logischerweise wird es jetzt nicht gleich so sein dass aktuelle Software es unterstützt (von Ausnahmen abgesehen). Ich gehe davon aus dass die meisten Spieleprojekte die in diesem Jahr begonnen wurden auf die eine oder andere Weise DualCore ausnutzt - bis diese Projekte fertig sind dauert es aber noch Jahre.
Multithreaded-Programmierung ist bisher eher Forschungsgebiet bei den Verteilten Systemen gewesen. Es machte bisher eben noch nicht so viel Sinn in Spielen, und in der Spieleentwicklung hat man immer einen pragmatischen Ansatz (außer eher wissenschaftlich agierende Entwickler wie id Software).
Das mit den Bugs ist ebenfalls eine Konzession an einen schnellen Markt. Wenn du wüsstest wieviele (Menschen-)Resourcen in der Crunchtime verbraten werden, auch um die Bugs auszubügeln, dann hättest du denke ich mehr Respekt davor. Es ist auch das ganze Wirtschaftsmodell in der Spieleindustrie etwas schief - bei diesem Streß den die Crunchtime gegen Projektende liefert finde ich es auch nicht verwunderlich dass Bugs übersehen oder auch zwangsweise drinnen gelassen werden. Wenn ein finaler Mastering-Meilenstein quasi über Tod oder Leben des Gesamtprojektes entscheidet - sprich, wenn man die Deadline verpasst, man 0 Kohle sieht vom Publisher - dann lässt man als Entwicklerstudio logischerweise weniger gravierende Bugs drinnen, um diesen Meilenstein halten zu können, und schickt auch mal eine Mastering-CD/DVD an den Publisher, der noch einige bekannte ungefixte Bugs enthält.
Es ist ganz einfach ein hartes Business (wo IMO wirklich auch arbeitsorganisatorisch einiges getan gehört), aber das kann man halt von der naiven Sicht eines Consumers (wie bei dir scheinbar) wohl nicht wirklich nachvollziehen.
Ähnliches mit Optimierung: Heutige Spiele und Engines sind schon sehr sehr optimiert. Natürlich braucht man immere stärkere Hardware, da ja auch wesentlich mehr gerendert wird als früher. Dass das immer verwechselt wird mit "heute optimieren sie nicht mehr so gut", ist eigentlich ziemlich kurzsichtig.
Mal abgesehen davon dass man es auch von Business-Seite (und auch Software-Engineering-Seite) verkraften kann, ein paar wenige CPU-Zyklen zu vergeuden für Engine-Code der wartbar, erweiterbar, und gut dokumentiert ist. Heutige Engines sind wesentlich wiederverwendbarer als frühere Engines - das kostet vielleicht ein bißchen Performance, ist es aber mehr als wert.
Also: nächstes Mal das ganze vielleicht etwas breiter sehen, und nicht so kurzsichtig!
Neomi
2006-08-12, 21:13:48
Erstmal vorweg: dir fehlt jegliche Kompetenz, über die Fähigkeiten von Programmierern zu urteilen, da du dich in dem Thema offenbar nicht auskennst. Ansonsten würdest du so eine Frage gar nicht erst stellen. Wenn du zu irgendwas Fragen hast, stelle sie einfach, aber verzichte bitte auf unpassende und beleidigende Seitenhiebe.
Und jetzt zur eigentlichen Frage. Natürlich kann man die Zahl der Cores abfragen und entsprechend nutzen. Ist der Umstieg von Singlethreaded auf Multithreaded erstmal vollzogen, ist die der Umstieg auf ein "größeres Multi" einfacher. Es ist auch eher ein Problem, parallelisierbare Aufgaben zu haben, als parallelisierbare Aufgaben zu parallelisieren.
PS: wenn man parallelisierbare Aufgaben hat, heißt das noch lange nicht, daß man auch die für die Parallelisierung nötige Zeit und das nötige Budget zur Verfügung hat.
HellHorse
2006-08-12, 21:21:37
Heutige Spiele und Engines sind schon sehr sehr optimiert.
Ehrlich? Ich meinte BF2 nutzt nicht einmal SSE und oft werden fast gar keine Compileroptimierungen aktiviert. Und so unglaublich langsam ist BF2 ggü anderen Games dann auch nicht.
@Mastermind
Angenommen der einzige Unterschied zwischen Quake 1 und Quake 4 wäre das letzeres vier mal schneller läuft. Würdest du es dir kaufen? Würdest du für ein Game doppelt so viel zahlen, wenn es doppelt so schnell läuft und drei Jahre später erscheint?
ollix
2006-08-12, 21:24:26
Also frage ich mich, ob man nicht wenigstens dem Problem für alle Zeiten beikommen könnte, in dem man Software generell so programmiert, dass sie einfach so viele Threads erstellt wie Cores vorhanden sind. Ist das programmiertechnisch möglich/unmöglich/problematisch? Kinderspiel. Nur ist es mit dem Erstellen von Threads eben nicht getan. :rolleyes:
EgonOlsen
2006-08-12, 21:30:08
Kinderspiel. Nur ist es mit dem Erstellen von Threads eben nicht getan. :rolleyes:Naja...also Kinderspiel...
Ehrlich? Ich meinte BF2 nutzt nicht einmal SSE
Hast du es disassembliert oder wie kommst du zu dem Schluss? AFAIK gab es da mal diesen Bericht in dem den Entwicklern Unfähigkeit vorgeworfen wurde weil sie keine SSE-Compiler-Flags aktivieren (in .NET 2003 das gar keine Autovektorisierung kann!). Das heißt aber noch lange nicht dass keine Intrinsics oder direkt Assembler verwendet wurde.
und oft werden fast gar keine Compileroptimierungen aktiviert.
Ich nehme an BF2 ist nicht auf den P4 optimiert weil es nichts bringt. Vor allem benachteiligt man damit offensichtlich Athlons, weil dem P4 Zeugs nicht schmeckt was jede andere CPU ohne Probleme schnell macht.
Und so unglaublich langsam ist BF2 ggü anderen Games dann auch nicht.
Gute Algorithmen machen auch oft sehr sehr viel mehr aus als solche "Optimierungen".
Soviele Threads erstellen wie CPUs vorhanden sind, ist vielleicht 5 Zeilen Code. Die machen dann aber nix sinnvolles.
HellHorse
2006-08-12, 21:59:08
Hast du es disassembliert oder wie kommst du zu dem Schluss?
Post von Coda. Der ist weg wegen Gästen.
Ich nehme an BF2 ist nicht auf den P4 optimiert weil es nichts bringt. Vor allem benachteiligt man damit offensichtlich Athlons, weil dem P4 Zeugs nicht schmeckt was jede andere CPU ohne Probleme schnell macht.
Ja und? Macht man halt zwei binaries. Das ist ja kein Aufwand (Apple verkauft das als cool, obwohl dort sind es ja mittlerweile vier), muss man ja für 64bit auch machen und eigentlich genau das, was ich von "sehr sehr optimiertem" Code erwarte.
Gute Algorithmen machen auch oft sehr sehr viel mehr aus als solche "Optimierungen".
Sicher, ist aber ein Baustein von "sehr sehr optimiertem" Code.
Monger
2006-08-12, 22:47:54
Wenn du Dinge in mehreren Threads ablaufen lassen willst, musst du mehr Aufwand bei der Synchronization der Daten zwischen diesen Threads treiben. Thread 1 darf nicht auf Daten rumhühnern, die Thread 2 gerade rendern will und ähnliches. Ohne mehrere Kerne/CPUs ist das erstmal langsamer und es ist davon abgesehen ein nicht unerheblicher Mehraufwand. Das macht keiner, wenn er nicht muss.
Das ist wohl das zentrale Problem. Die Theorie hinter Multithreading ist jetzt schon so alt wie der PC selbst (und wird ja vom Betriebssystem auch ausgiebig genutzt), aber die Nebenwirkungen sind halt heftig. Diskrete Zustände und Nebenläufigkeit vertragen sich nicht besonders toll, und ein Computer arbeitet nunmal mit diskreten Zuständen.
Demirug
2006-08-12, 23:52:17
Sehr interesantes Video zu dem Thema: http://channel9.msdn.com/Showpost.aspx?postid=219308
tokugawa
2006-08-13, 00:52:35
Ehrlich? Ich meinte BF2 nutzt nicht einmal SSE und oft werden fast gar keine Compileroptimierungen aktiviert. Und so unglaublich langsam ist BF2 ggü anderen Games dann auch nicht.
Natürlich ist es von Spiel zu Spiel verschieden welche Optimierungen gemacht werden. Mich würd aber interessieren woher du mit Sicherheit sagen kannst dass BF2 keine Compileroptimierungen hat - das kann ich mir nun doch nicht vorstellen (unter Compileroptimierungen fallen sehr viel mehr andere Sachen als nur SSE2 oder erweiterte Befehlssätze, die klassischen Compileroptimierungen sind Befehlsanordnung, diverses Inlining & Loop runrolling, Cache-Optimierungen, die zwar architekturabhängig sind, aber nicht abhängig von erweiterten Befehlssätzen. Die wird BF2 denk ich schon machen.
Und im Prinzip sagst du eh das was ich meinte: letztendlich bringt solche Zyklen-Kackerei ziemlich wenig für eine Grafikanwendung (= Spiel), wenn diese GPU-limitiert sind (was moderne Spiele mit zeitgemäßer Grafik in der Regel sind).
Außerdem gilt immer noch das, was Gast richtigerweise erwähnte:
Gute Algorithmen machen auch oft sehr sehr viel mehr aus als solche "Optimierungen".
Ja und? Macht man halt zwei binaries. Das ist ja kein Aufwand (Apple verkauft das als cool, obwohl dort sind es ja mittlerweile vier), muss man ja für 64bit auch machen und eigentlich genau das, was ich von "sehr sehr optimiertem" Code erwarte.
Das fällt für mich dann wieder unter Optimierungen die oft kaum oder gar nichts bringen (in den erwähnten GPU-limitierten Anwendungen). Und dann stimmt das Verhältnis Aufwand-Gewinn nicht mehr, egal wie niedrig der Aufwand ist.
Bezüglich GPU-Nutzung (die bei den erwähnten GPU-limitierten Anwendungen der Knackpunkt sind) sind die schon sehr sehr optimiert, soweit es vertretbar ist mit dem Aufwand (hier müsste man nämlich für absolute Optimalität für jede GPU separate Renderpfade schreiben, was ein absoluter wartungstechnischer Horror ist meiner Meinung nach - ich bin kein Freund von Renderpfaden).
Sehr interesantes Video zu dem Thema: http://channel9.msdn.com/Showpost.aspx?postid=219308
Sehr interessantes Audio zum Thema: http://www.media01-live.de/CC-Zwei-02.mp3 (..ab etwas über der Hälfte..)
Ähnlich Blumen und Bienen, nur mit Erbsen und anderem Gemüse...Metaphern ohne Bilder, einfach weil die Moderatoren genial sind, und auch technisch pubertären Gemütern die einfachsten Sachen anhand von "Erbsenzählerei" erklären können.
Vom parallelisierung zur Laufzeit möchte...
Erstmal eine kleine Anmerkung von mir: Ich finde es schon ein wenig dreist, den Entwicklern Unfähigkeit zu unterstellen, wenn man sich selber nicht ausreichend mit Materie auskennt (weil man nämlich kein Entwickler ist!), um derartige Behauptungen anzustellen.
Aber das werden dir einige Programmierer hier im Forum sicherlich besser erklären können.
Davon abgesehen denke ich auch als Laie, dass es alles andere als einfach ist, eine Software für Multicores bzw. Multiprozessorsysteme zu optmieren. Wobei das natürlich auch von der Art der Software abhängt, gerade bei Spielen dürfte es z.B. nicht so einfach sein, da man eben nicht alles beliebig parallelisieren kann.
Vor allem aber ist es quasi verschenkte Zeit, auf eine Sache zu optimieren, aus der 99% der User sowieso keinen Nutzen ziehen können. Und Zeit ist bekanntlich Geld. Das ist auf deine Aussage mit der 1GHz-Zeit bezogen.
Ja irgenteiner muss doch daran schuld sein das wir immerwieder hardware haben aber die software erst nach einem jahr mit den neuen features läuft und dann kann man seine hardware wieder in die tonne kloppen.
Dann ist es doch dumm von den hardware herstellern immerwieder irgent eine hardware auf den markt zu bringen die zwar schneller ist als die alte hardware, aber wo trotzdem 50prozent der leistung verloren gehen, oder bei den grafikkarten.
Ist doch schade das man nie seine hardware so richtig ausnutzen kann bei programmen oder spielen und dann nach einem jahr ein game rauskommt wo das feature verwedet wird, aber ruckelt wie sau oder was auch immer.
tokugawa
2006-08-13, 04:00:16
Ja irgenteiner muss doch daran schuld sein das wir immerwieder hardware haben aber die software erst nach einem jahr mit den neuen features läuft und dann kann man seine hardware wieder in die tonne kloppen.
Das nennt man Fortschritt.
Dann ist es doch dumm von den hardware herstellern immerwieder irgent eine hardware auf den markt zu bringen die zwar schneller ist als die alte hardware, aber wo trotzdem 50prozent der leistung verloren gehen, oder bei den grafikkarten.
Nein. Weil ohne Hardware können die Entwickler nicht dafür entwickeln, und dann gibt's erst recht gar keine Software für die Hardware. Das ist auch die Daseinsberechtigung des Shader Models 3.0 der GeForce 6 damals gewesen - zu Recht, wie man heutzutage sieht.
SM3 hat beim NV40-Launch den Gamern nichts gebracht, aber den Entwicklern Tools in die Hand gegeben, mit denen sie SM3-Titel überhaupt realisieren können. Irgendwer muß den Anfang machen, und da Software-Entwickler stark von der Hardware abhängig sind, muß die Hardware den Anfang machen - hätte man damals auf jene Rufe "SM3 ist doch noch sinnlos!" gehört, hätten wir heute noch kein SM3, und Software die dies nutzt wäre auch Jahrzehnte entfernt.
Ist doch schade das man nie seine hardware so richtig ausnutzen kann bei programmen oder spielen und dann nach einem jahr ein game rauskommt wo das feature verwedet wird, aber ruckelt wie sau oder was auch immer.
Man kann die Hardware sehr wohl richtig ausnutzen, nur wirklich neue Hardware-Features haben halt das angesprochene Stigma, dass es wohl nur von Spezialisten (Entwicklern) wirklich genutzt wird und erst nachdem diese etwas daraus gemacht haben (Software), es auch den regulären Consumern etwas bringt (die dann etwa die Zweitgenerations-Hardware mit diesem Feature kaufen können, die auch wirklich ausgereizt wird).
Early Adopters von neuer Technologie zahlen immer drauf, das war schon immer so. Deswegen muß man sich auch überlegen ob man wirklich Early Adopter sein will (ob es einem einen praktischen Nutzen bringt).
Was im Endeffekt wieder auf Selbstverantwortung und Wissen hinausläuft: Consumer haben IMO nicht das Recht, die Hardware und Softwarehersteller für Fortschritt zu bashen, wenn sie nicht wissen, wann es für sie persönlich Sinn macht, diese Hardware zu kaufen.
Das nennt man Fortschritt.
Nein. Weil ohne Hardware können die Entwickler nicht dafür entwickeln, und dann gibt's erst recht gar keine Software für die Hardware. Das ist auch die Daseinsberechtigung des Shader Models 3.0 der GeForce 6 damals gewesen - zu Recht, wie man heutzutage sieht.
SM3 hat beim NV40-Launch den Gamern nichts gebracht, aber den Entwicklern Tools in die Hand gegeben, mit denen sie SM3-Titel überhaupt realisieren können. Irgendwer muß den Anfang machen, und da Software-Entwickler stark von der Hardware abhängig sind, muß die Hardware den Anfang machen - hätte man damals auf jene Rufe "SM3 ist doch noch sinnlos!" gehört, hätten wir heute noch kein SM3, und Software die dies nutzt wäre auch Jahrzehnte entfernt.
Man kann die Hardware sehr wohl richtig ausnutzen, nur wirklich neue Hardware-Features haben halt das angesprochene Stigma, dass es wohl nur von Spezialisten (Entwicklern) wirklich genutzt wird und erst nachdem diese etwas daraus gemacht haben (Software), es auch den regulären Consumern etwas bringt (die dann etwa die Zweitgenerations-Hardware mit diesem Feature kaufen können, die auch wirklich ausgereizt wird).
Early Adopters von neuer Technologie zahlen immer drauf, das war schon immer so. Deswegen muß man sich auch überlegen ob man wirklich Early Adopter sein will (ob es einem einen praktischen Nutzen bringt).
Was im Endeffekt wieder auf Selbstverantwortung und Wissen hinausläuft: Consumer haben IMO nicht das Recht, die Hardware und Softwarehersteller für Fortschritt zu bashen, wenn sie nicht wissen, wann es für sie persönlich Sinn macht, diese Hardware zu kaufen.
Ja was interessiert mich als normalo user, ob die entwickler die hardware ausnutzen können?! Dein vergleich hinkt doch sehr!!
Dann sollen sie so ne hardware nicht für den offenen markt bauen, sondern nur für die die auch was damit anfangen können. Aber was solls ja ne gibt genug hirnies und hardware geile die es eh kaufen, zuaätzlicher gewinn kann net schaden...
ilPatrino
2006-08-13, 07:51:22
Ja was interessiert mich als normalo user, ob die entwickler die hardware ausnutzen können?! Dein vergleich hinkt doch sehr!!
Dann sollen sie so ne hardware nicht für den offenen markt bauen, sondern nur für die die auch was damit anfangen können. Aber was solls ja ne gibt genug hirnies und hardware geile die es eh kaufen, zuaätzlicher gewinn kann net schaden...
klingt so als ob du jeden donnerstag nachmittag von der hardware-entwicklungs-mafia gezwungen wirst, dir die neueste technologie zu kaufen.
mein tip: kauf dir nen p3-s mit board und gf4, dazu win-xp. dann hast du ein system, was von der software vollständig ausgenutzt wird. in 10 jahren kannst du auf den wesentlich schnelleren core duo updaten, wenn der vista-nachfolger und die neuesten spiele dual-threading endlich vollständig ausnutzen.
und du kannst während der ganzen zeit über die anderen lachen, die ihr geld in unnütze - weil gar nicht ausgenutzte - hardware investieren, bloß weil sie die neuesten spiele spielen wollen.
Mastermind
2006-08-13, 15:29:34
OK, ich entschuldige mich. Ich habe beim verfassen meines Postings wohl etwas übertrieben. Wollte eigentlich nur eine kontroverse Diskussion anstoßen. :wink:
@tokugawa:
Bei SM3.0 sehe ich deinen Einwand. Aber wenn mich nicht alles täuscht ist das Programmieren für mehrere Prozessorkerne ein alter Hut. Und du hast sicher die Kaufberatungen der letzten Jahre mitbekommen. Was bekam man da meist zu hören? Dass sich DC nicht lohnt, weil es keine ordentliche Unterstützung erfährt. Wenn dann zu wenige DC kaufen, werden diese nicht im Preis sinken und die Softwareentwickler haben keinen Anreiz für DC zu programmieren. Ein Teufelskreis.
Versteh mich nicht falsch, ich bin nicht gegen Fortschritt, im Gegenteil! Mir kam dieser Fortschritt aber einseitig vor.
Vielleicht wäre es wenigstens möglich Technologien, sobald die Spezifikationen feststehen, an die Entwickler weiterzureichen? Ich meine, was SM3.0 ausmacht dürfte klar gewesen sein bevor die erste GraKa dazu erschienen ist.
Außerdem, wenn ich mir anschaue wieviele Befehlssätze moderne Prozessoren so unterstützen... Welche Spiele nutzen das alles aus?
Aber bevor ich weitere Vorwürfe äußere werde ich mich besser informieren und mir mal die hier geposteten Links reinziehen.
crusader4
2006-08-13, 22:01:18
Nur weil CPU A Befehlssatz B enthält, heißt das doch nicht, das es auch für Spiele nützlich ist. Ganz doofes Beispiel: Was nützen mir hardwarebeschleunigte Gleitkommaberechnungen, wenn meine Anwendung keine Gleitkommazahlen benutzt. Du darfst hier nicht dem Marketing auf den Leim gehen, das mit allem wirbt, wie Shadowxx mal so schön sagte "Was bei drei nicht vom Wafer gehüpft ist." Der Entwickler muß immer noch entscheiden, ob ein bestimmtes Feature überhaupt sinnvoll einsetzbar ist.
Zu Deinem Einwand mit SM3: Sicher gab es vor den ersten Karten Software-Renderer, die SM3 darstellen konnten. Allerdings wohl mit einer Geschwindigkeit, die Entwicklung und Testen zur Warterei macht. Also entwickelt man die Anwendung noch mit SM2 und wartet mit der Implementierung, bis es Hardware gibt, die das (nahezu) in Echtzeit kann. Die Wirtschaftlichkeit kann und darf ein Entwickler in einem Unternehmen nicht aus den Augen verlieren.
Zu dem Gast, der meinte das man die Hardware für Entwickler nur für diese bauen soll: Auch hier kommt wieder die Wirtschaftlichkeit ins Spiel. Zu verschiedener Hardware für einzelne Marktsegmente käme dann noch eine Extra-Reihe für Entwickler. Das würde sämtliche Hardware verteuern. Man kann nur wenige Entwickler-Hardware absetzen (teurere Produktion bei geringen Stückzahlen), so das man die Entwicklungs- und zusätzliche Hardwarekosten auf die Consumer-Karten umlegen muß. Warum nicht gleiche Karten für alle: Weniger Aufwand, geringere Preise für alle.
Grüße, Crusader
tokugawa
2006-08-14, 06:37:54
@tokugawa:
Bei SM3.0 sehe ich deinen Einwand. Aber wenn mich nicht alles täuscht ist das Programmieren für mehrere Prozessorkerne ein alter Hut.
In Anwendungen wie Datenbanksysteme oder Rendering (oder ähnlichem) schon. In Spielen bzw. Echtzeitrendering wurde bisher einfach nicht die Forschung betrieben - das wird jetzt gerade nachgeholt (was man an Computergrafik/Rendering- und Spieleentwickler-Konferenzen der letzten Monate deutlich sieht).
John Carmack war hier eindeutig ein Vorreiter.
Und du hast sicher die Kaufberatungen der letzten Jahre mitbekommen. Was bekam man da meist zu hören? Dass sich DC nicht lohnt, weil es keine ordentliche Unterstützung erfährt. Wenn dann zu wenige DC kaufen, werden diese nicht im Preis sinken und die Softwareentwickler haben keinen Anreiz für DC zu programmieren. Ein Teufelskreis.
Klar ist es ein Henne-Ei-Problem, war ja bei SM3.0 genauso. Nur genau wie bei SM 3.0 (oder auch SM 2.0) haben eben Freaks, "Early Adopters", sowie Entwickler meistens diese Hardware. Irgendwann wird diese Hardware auch billiger (das war bei DualCore erst jetzt vor kurzem der Fall dank des Pentium-D 805, anfänglich war es einfach unerschwinglich für die breite Masse), somit kaufen sich's viele Leute allein wegen des Preises (genau wie Leute etwa GeForce 7300 und 7600 kaufen, wegen des Preises).
Dann baut sich allmählich die installierte Basis auf, und Entwickler kriegen dann auch tatsächlich Mittel (etwa vom Publisher), dahingehend zu entwickeln (vor allem wenn es ein Publisher gut findet, sowas auf die Verpackung zu schreiben).
Auch wurde die Forschung und Entwicklung in der Spieleentwicklung bezüglich Multicore unter anderem auch wegen der aktuellen Konsolengeneration (Xbox360 und PS3) losgetreten. Das prinzipielle Knowhow hier bringt auch was für Dualcore, und viele Entwickler haben sich hiermit überhaupt erstmals mit sowas beschäftigt.
Versteh mich nicht falsch, ich bin nicht gegen Fortschritt, im Gegenteil! Mir kam dieser Fortschritt aber einseitig vor.
Vielleicht wäre es wenigstens möglich Technologien, sobald die Spezifikationen feststehen, an die Entwickler weiterzureichen? Ich meine, was SM3.0 ausmacht dürfte klar gewesen sein bevor die erste GraKa dazu erschienen ist.
Mit Spezifikationen programmieren macht nicht annäherend soviel Spaß wie mit der echten Hardware :)
Außerdem, wenn ich mir anschaue wieviele Befehlssätze moderne Prozessoren so unterstützen... Welche Spiele nutzen das alles aus?
Naja, soweit es Sinn macht, kann man sowas nutzen und tun es auch einige. Oft ist der Gewinn aber nicht so dramatisch dadurch, dass es ohne nicht gehen würde. Gerade in Echtzeitgrafikanwendungen hängt die Gesamtperformance des Systems ja an mehreren Strängen, bzw. ist die CPU meistens nicht der Flaschenhals (bei moderenen Echtzeitgrafikanwendungen/Spielen). Es macht nicht viel Sinn, einen Bereich zu optimieren/beschleunigen, der gar nicht der Flaschenhals ist.
Ja was interessiert mich als normalo user, ob die entwickler die hardware ausnutzen können?! Dein vergleich hinkt doch sehr!!
Nein, tut er nicht. Ich hab geschrieben dass Consumer vermutlich nicht gut beraten sind, "Early Adopters" zu spielen. Early Adopters zahlen immer drauf. Also eh genau das was du meintest, nur weniger unhöflich formuliert.
Trotzdem gibt es eben schon alleine deswegen die Berechtigung dafür, weil die Entwickler diese Spiele dann für die "Normalo-User" entwickeln. Die Spiele fallen ja nicht einfach so vom Himmel. Sei lieber dankbar.
Dann sollen sie so ne hardware nicht für den offenen markt bauen, sondern nur für die die auch was damit anfangen können. Aber was solls ja ne gibt genug hirnies und hardware geile die es eh kaufen, zuaätzlicher gewinn kann net schaden...
Tja, das wären wohl die Freaks und Early Adopters, von denen ich sprach. "Hirnies" würde ich sie nicht nennen - ist auch ein Hobby. Auch wenn es auch für mich privat oft wenig Sinn macht, Early Adopter zu spielen.
"Hardware nicht für den offenen Markt" ist insofern ein Blödsinn, weil der Markt für Entwickler genauso offen ist wie für Consumer. Entwickler bist du sobald du programmierst - etwa Studenten mit Interesse in Echtzeitgrafik kann man ja nicht zumuten dass aus irgendeinem "geschlossenen Markt" (was soll das überhaupt sein?) mit überhöhten Preisen die, ähm, "Lehrmittel" (Jep, eine GeForce 7900 GTX kann man durchaus als Lehrmittel bezeichnen :) ) beziehen.
Außerdem gibt es doch ein gutes Argument dafür, dass Entwickler normale Consumer-Hardware verwenden: was bringt Extrahardware, die sich anders verhält als die Hardware, auf der das Zeug dann laufen soll?
Piffan
2006-08-15, 00:59:38
Der Traum wäre doch ein Programm, das in Echtzeit beliebigen Code nach paralellisierbaren Abschnitten durchforstet und dann die Verteilung effektiv vornimmt.....
Noch besser wäre es, wenn die Entwickler ihre Engines von vornherein so bauen, dass sie mit der Zahl der Cores skalieren......
Was ist aber nun, wenn es tatsächlich Dinge gibt, die von der Natur der Sache her so voneinander abhängen, dass es nix zu parallelisieren gibt?
Bei Bildern oder Videos ist es ja so, dass man die Bildfläche in Bereiche aufteilen kann, die man verschiedenen Cores zuweist. Bei der Verzahnung von Grafik, Physik und KI in einem Spiel ist eine Entflechtung von einander abhängigen Vorgängen nur mit einkalkulierter Ungenauigkeit machbar, wenn die Threads nicht zu lange auf einander warten sollen......
Ob eine Engine von Multicore profitieren kann oder nicht hängt wohl nur von der Art des jeweiligen Flaschenhalses ab. Ich könnte mir vorstellen, dass die Id- Engine so heftigen Nutzen aus Multicore ziehen kann, weil die Grafik den Löwenanteil der Rechenzeit in Anspruch nimmt und Grafik vielleicht problemlos aufgeteilt werden kann.
Monger
2006-08-15, 08:45:34
Die Realität ist wirkungsmäßig voll verzahnt. Ein Schmetterling kann nunmal wirklich einen Wirbelsturm in Venezuela auslösen - unwahrscheinlich, aber möglich.
Deshalb wird imho das Synchronisationsproblem immer schlimmer, je komplexer und dynamischer die Landschaften werden.
Jetzt fangen wir gerade mit den Physikspielereien an. Sobald Kollisionen auftreten, sind die auch nicht wirklich toll zu parallelisieren. Was aber, wenn jetzt die KI verstärkt auf Physik reagiert? Wenn z.B. der Gegner versucht, irgendwelchen herumfliegenden Trümmern selbstständig auszuweichen?
Das hält sich ja noch alles in Grenzen, weil diese Reaktionen auch mal ein paar Zehntel Sekunden dauern dürfen. Aber je mehr Objekte daran beteiligt sind, desto komplexer werden die Beziehungen untereinander. Wenn man die alle parallelisieren wollte, wäre der Synchronisationsaufwand gigantisch.
Piffan
2006-08-15, 08:57:14
Das Problem ist der Abgleich/Synchronisation und die möglichst hohe Aktualität der Daten. Wenn jedes Objekt einen kompletten Datensatz der "Welt" mit sich rumschleppen würde, dann könnte man es losgelöst von allen anderen Objekten für sich als Thread laufen lassen. Was vielleicht noch für die KI so funktionieren könnte, wäre für komplexe Physik völlig absurd...Ergo wird man ziemlich harte Vereinfachungen/Ungenauigkeiten definieren müssen, damit Dinge parallel berechnet werden können, die eigentlich von einander abhängen. Wenn die Vereinfachungen nicht offensichtlich sind, z.B. bei Trümmerwolken und ähnlichen Effekten, fällt es dem Spieler wohl nicht auf, wenn Objekte statt zu kollidieren, berührungslos durcheinander fliegen. Hauptsache der Rumms kommt gut rüber.
Der Traum wäre doch ein Programm, das in Echtzeit beliebigen Code nach paralellisierbaren Abschnitten durchforstet und dann die Verteilung effektiv vornimmt.....
Das ist der heilige Gral der Informatik. Praktisch unmöglich.
HellHorse
2006-08-15, 18:40:04
Das ist der heilige Gral der Informatik. Praktisch unmöglich.
Das kann man zur Compilezeit machen und ist super einfach. Wurde schon gemacht und selbst ich könnte es dir implementieren.
Ja, nur kommt nichts anständiges bei raus. Die Performancegewinne durch Autoparalleisierung sind nicht gerade hoch.
HellHorse
2006-08-16, 17:47:42
Ja, nur kommt nichts anständiges bei raus. Die Performancegewinne durch Autoparalleisierung sind nicht gerade hoch.
Doch sicher. Du musst nur Nebeneffekte aufgeben und dann das ist alles kein Problem.
XtraLarge
2006-08-18, 13:29:15
Mal ´ne frage von jemandem, der davon garkeine Ahnung hat:
Ohne mich jetzt näher damit beschäftigt zu haben, aber es gibt doch PhysX Karten, welche momentan nicht wirklich was bringen. Eben wegen fehlendem Software-Support. Aber die Karte ist doch imEndeffekt nicht anderes, als eine zusätzliche Möglichkeit (Core), die Physikberechnungen eines Spiels zu beschleunigen!? Lässt sich sowas nicht auf ´nem zweiten, dritten, vierten Core erledigen? Und was ich mich vorallem Frage ist, ob man denn nicht z.B. die KI eines Spiels auf den zweiten Core auslagern könnte? Mir ist gerade so, als hätten sich Spielentwickler schon häufiger über die fehlende Rechenleistung diesbezüglich beklagt?
Ich bitte darum, diesen Post als Frage zu verstehen!
Nach Funktionen parallelisieren (Physik ein Thread, KI ein Thread usw.) ist meist ziemlich dumm. Erstens hat man damit eine feste Obergrenze wieviele Cores etwas bringen können, zweitens müssen die Threads dann sehr oft kommunizieren und das ist langsam und fehleranfällig.
Üblicherweise macht man x Threads (mit x=Anzahl Cores) und gibt dann jedem Thread von den n Objekten die zu berechnen sind n/x Objekte. Der Thread berechnet dann alles was für die Objekte zu berechnen ist, also Physik, KI, rendering, usw...
Die PhysX-Karte ist theoretisch bei den für Physik nötigen Berechnungen besonders schnell, schneller als ein Dual-Core 3 GHz Conroe. Bringt aber wenig, vor allem da Physikberechnung nur einen kleinen Anteil der Berechnungen eines Spiels ausmacht und zusätzlich am gleichen Problem krankt wie die Lösung der Parallelisierung nach Funktionen.
hi, hab zwar auch keine ahnung vom thema aber aus den anderen posts komm ich nun etwa zu diesem schluß:
"multithreating" bring erst so ab etwa 4 cores etwas:
ein core filtert, analysiert, berechnet nur heraus (oder macht der geier was), welche aufgaben paraleisiert werden können und verteilt diese auf die anderen 3 cores...
das ist zwar kein richtiges mulithreading aber es ist wohl ein guter weg (anfang) dort hin... oder?
also heist es noch: "abwarten und tee trinken, bis es quadcores gibt..."
Ob eine Engine von Multicore profitieren kann oder nicht hängt wohl nur von der Art des jeweiligen Flaschenhalses ab. Ich könnte mir vorstellen, dass die Id- Engine so heftigen Nutzen aus Multicore ziehen kann, weil die Grafik den Löwenanteil der Rechenzeit in Anspruch nimmt und Grafik vielleicht problemlos aufgeteilt werden kann.
vermutlich liegt es daran dass deren engine in openGL programmiert wurde und bekanntermaßen die multicoreoptimierungen im grafiktreiber in opengl besonders viel bringen.
Blödsinn. Quake 4 hat einfach sehr gute Threading-Optimierungen erhalten u.a. durch Zusammenarbeit mit Intel.
Mit der Grafik-API hat das nichts zu tun. OpenGL ist auch noch nie "automatisch" multithreading-fähig gewesen. Das ist eine Legende.
Mit der Grafik-API hat das nichts zu tun. OpenGL ist auch noch nie "automatisch" multithreading-fähig gewesen. Das ist eine Legende.
fakt ist aber, dass die multithreading-optimierungen in den grafiktreibern unter OGL wesentlich mehr als in D3D bringen.
Piffan
2006-08-18, 21:12:53
Nach Funktionen parallelisieren (Physik ein Thread, KI ein Thread usw.) ist meist ziemlich dumm. Erstens hat man damit eine feste Obergrenze wieviele Cores etwas bringen können, zweitens müssen die Threads dann sehr oft kommunizieren und das ist langsam und fehleranfällig.
Üblicherweise macht man x Threads (mit x=Anzahl Cores) und gibt dann jedem Thread von den n Objekten die zu berechnen sind n/x Objekte. Der Thread berechnet dann alles was für die Objekte zu berechnen ist, also Physik, KI, rendering, usw...
Hört sich plausibel an. Dadurch werden unnütze Wartezeiten vermieden. Solange einem Core die Objekte nicht ausgehen, hat er gut zu tun....
Wie macht man das praktisch? Man muss wohl feste Intervalle für eine "Inventur" machen, damit die Daten für alle Objekte aktuell sind und die Aufgaben gleichmäßig verteilt werden. Praktisch Zyklen von fester Zeit, die gwissermaßen die Granularität der Zeit in der virtuellen Welt darstellen......
Wenn das wirklich funzt, dann skalieren die Spiele dann doch mit der Zahl der Cores....
Allerdings: Dezidierte Physik- Hardware ist eine Totgeburt....Nicht nur aus Gründen die Demirurg beschrieb, nämlich dass die explodierende Zahl von Objekten nicht durch die Grafik geschleust werden kann, sondern auch, weil Multicore die Zukunft gehört....und da ist der Physik- Prozessor eher ein Hemmschuh...
@Trap: Gibts da schon verläßliche Erfahrungen, können komplexe Spiele mit der Zahl der Cores skalieren oder ist das eine "Vision"?
Demirug
2006-08-18, 22:04:24
Mein Ansatz für einen massive Multicore Gameloop sah etwas anders aus da ich sowohl nach Funktionen wie auch nach Objekten innerhalb der Funktionen skalieren wollte.
Im Prinzip gib es zwei Joblisten für Microjobs die von allen Kernen abgearbeitet werden können. Die erste Liste nennt sich Calculate und die zweite Update. Während die Jobs der Calculate Liste abgearbeitet werden ist der Zustand der Welt eingefroren. Die Ergebnisse werden auch nicht direkt zurück geschrieben sondern in Form eines Update Jobs in die zweite Liste eingehängt. Sobald alle Calculate Jobs durch sind wird die Welt durch die Updatejobs auf den neusten Stand gebracht und das ganze beginnt von vorne.
Das ganze skaliert sehr gut mit der Anzahl der Kerne allerdings dürfen die Jobs nicht zu klein werden weil sonst der Overhead den Vorteil wieder auffrißt. Bei zu großen Jobs besteht die Gefahr das wenn eine Liste leer ist ein solcher noch auf einem Kern läuft während die anderen schon nichts mehr zu tun haben. Einer der Tricks dabei ist zu versuchen die langen Jobs an den Anfang der Listen zu bekommen und die kleinen ans Ende.
XtraLarge
2006-08-19, 01:23:16
Also ist und bleibt die PhysX-Karte ein Marketing-Gag?
Denn ich denke, dass es auch in nicht allzu ferner Zukunft (AMD übernimmt ATI) Multicore Grafikkarten geben wird, wodurch heutiges SLI zur Lachnummer degradiert wird. Und ich glaube, dass man dann auf eben dieses PhysX Modell setzen wird!? Nur eben auf einer Karte. So wie damals im Schützengraben mit 2D Karte und 3d-Beschleuniger :wink: Die Zeiten sind ja auch lange vorbei, obwohl damit ja schon eine echte Revolution einher ging! Das scheint mir nach der Meinung in diesem Thread bei PhysX nicht der Fall zu sein. Auch wenn es gerade doch sehr hervorgehoben wird.
Multicore sind GPUs schon seit Ewigkeiten...
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.