Abo
  1. Foren
  2. Kommentare
  3. Games
  4. Alle Kommentare zum Artikel
  5. › Valve will Source-Engine für Multicore…

Primitivlösung

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Primitivlösung

    Autor: programmierer 07.11.06 - 12:52

    Der Ansatz von Valve ist eine Primitivlösung. Natürlich ist es einfach z.B. den Sound komplett auf einen Kern zu legen. Da aber der Sound eine relativ einfache Aufgabe ist wird die Core damit nicht ansatzweise ausgenutzt. Viel Portential geht so verloren. Ähnlich sieht es mit der weiteren starren Aufteilung der Aufgaben aus wie Valve es geplant hat. Die einzig effektive Lösung ist eine variable thread Programmierung. Das so etwas möglich ist zeigen wissenschaftliche Simulationen oder Datenbanken wie MSSQL oder DB2. Das Problem dabei ist allerdings dass eine solche Programmierung kompliziert ist und eine gute koordination im Entwicklungsteam voraussetzt. Hier scheint es bei den Spieleprogrammierern am meisten zu hapern. Sie haben 1. keinerlei Erfahrung mit diesen Techniken und 2. sind die Teams meist nicht lange genug zusammen um ein wirklich effektives System zu schaffen. Bei den Spielefirmen bei denen ich bisher war herrschte ein Hire und Fire Prinzip, mit ständig anderen Leuten wird es schwer ein solches System zu entwickeln. An Datenbanken entwickeln einige Teams in fast unveränderter Zusammensetzung bereits 15 Jahre und mehr das sich dort eine bessere Programmierkultur entwickelt hat dürfte klar sein.

  2. Re: Primitivlösung

    Autor: Bytebeisser 07.11.06 - 12:58

    programmierer schrieb:
    -------------------------------------------------------
    > Der Ansatz von Valve ist eine Primitivlösung.
    > Natürlich ist es einfach z.B. den Sound komplett
    > auf einen Kern zu legen. Da aber der Sound eine
    > relativ einfache Aufgabe ist wird die Core damit
    > nicht ansatzweise ausgenutzt. Viel Portential geht
    > so verloren. Ähnlich sieht es mit der weiteren
    > starren Aufteilung der Aufgaben aus wie Valve es
    > geplant hat. Die einzig effektive Lösung ist eine
    > variable thread Programmierung. Das so etwas
    > möglich ist zeigen wissenschaftliche Simulationen
    > oder Datenbanken wie MSSQL oder DB2. Das Problem
    > dabei ist allerdings dass eine solche
    > Programmierung kompliziert ist und eine gute
    > koordination im Entwicklungsteam voraussetzt. Hier
    > scheint es bei den Spieleprogrammierern am meisten
    > zu hapern. Sie haben 1. keinerlei Erfahrung mit
    > diesen Techniken und 2. sind die Teams meist nicht
    > lange genug zusammen um ein wirklich effektives
    > System zu schaffen. Bei den Spielefirmen bei denen
    > ich bisher war herrschte ein Hire und Fire
    > Prinzip, mit ständig anderen Leuten wird es schwer
    > ein solches System zu entwickeln. An Datenbanken
    > entwickeln einige Teams in fast unveränderter
    > Zusammensetzung bereits 15 Jahre und mehr das sich
    > dort eine bessere Programmierkultur entwickelt hat
    > dürfte klar sein.

    Ich habe den Artikel garade unserem Informatik Prof gezeigt. Der hat nur die Hände über dme Kopf zusammengeschlagen. Der Ansatz von Valve ist total trivial und unflexibel. Da wundert es auch nicht dass andere Spielfimen mit dem gleichen Ansatz nur 20-30% Geschwindigkeit herausgeholt haben. Der einzige Weg um das Potential der Hardware voll zu nutzen ist richtigen Multithreading wie es in professionellen Programmen schon lange Standard ist.

  3. Re: Primitivlösung

    Autor: matze 81 07.11.06 - 13:03

    Bytebeisser schrieb:
    -------------------------------------------------------
    > programmierer schrieb:
    > --------------------------------------------------
    > -----
    > > Der Ansatz von Valve ist eine
    > Primitivlösung.
    > Natürlich ist es einfach z.B.
    > den Sound komplett
    > auf einen Kern zu legen.
    > Da aber der Sound eine
    > relativ einfache
    > Aufgabe ist wird die Core damit
    > nicht
    > ansatzweise ausgenutzt. Viel Portential geht
    >
    > so verloren. Ähnlich sieht es mit der
    > weiteren
    > starren Aufteilung der Aufgaben aus
    > wie Valve es
    > geplant hat. Die einzig
    > effektive Lösung ist eine
    > variable thread
    > Programmierung. Das so etwas
    > möglich ist
    > zeigen wissenschaftliche Simulationen
    > oder
    > Datenbanken wie MSSQL oder DB2. Das Problem
    >
    > dabei ist allerdings dass eine solche
    >
    > Programmierung kompliziert ist und eine gute
    >
    > koordination im Entwicklungsteam voraussetzt.
    > Hier
    > scheint es bei den Spieleprogrammierern
    > am meisten
    > zu hapern. Sie haben 1. keinerlei
    > Erfahrung mit
    > diesen Techniken und 2. sind
    > die Teams meist nicht
    > lange genug zusammen um
    > ein wirklich effektives
    > System zu schaffen.
    > Bei den Spielefirmen bei denen
    > ich bisher war
    > herrschte ein Hire und Fire
    > Prinzip, mit
    > ständig anderen Leuten wird es schwer
    > ein
    > solches System zu entwickeln. An Datenbanken
    >
    > entwickeln einige Teams in fast unveränderter
    >
    > Zusammensetzung bereits 15 Jahre und mehr das
    > sich
    > dort eine bessere Programmierkultur
    > entwickelt hat
    > dürfte klar sein.
    >
    > Ich habe den Artikel garade unserem Informatik
    > Prof gezeigt. Der hat nur die Hände über dme Kopf
    > zusammengeschlagen. Der Ansatz von Valve ist total
    > trivial und unflexibel. Da wundert es auch nicht
    > dass andere Spielfimen mit dem gleichen Ansatz nur
    > 20-30% Geschwindigkeit herausgeholt haben. Der
    > einzige Weg um das Potential der Hardware voll zu
    > nutzen ist richtigen Multithreading wie es in
    > professionellen Programmen schon lange Standard
    > ist.

    Full Ack. Das bekommt man schon im 2. Semester eingehämmert das solche starren Lösungn nichts bringen. Sie sind zwar einfach zu realisieren aber viel zu unflexibel. Ich frage mich wo die Leute bei Valve studiert haben.

  4. Re: Primitivlösung

    Autor: adba 07.11.06 - 13:11

    programmierer schrieb:
    -------------------------------------------------------
    > Der Ansatz von Valve ist eine Primitivlösung.
    > Natürlich ist es einfach z.B. den Sound komplett
    > auf einen Kern zu legen. Da aber der Sound eine
    > relativ einfache Aufgabe ist wird die Core damit
    > nicht ansatzweise ausgenutzt. Viel Portential geht
    > so verloren. Ähnlich sieht es mit der weiteren
    > starren Aufteilung der Aufgaben aus wie Valve es
    > geplant hat. Die einzig effektive Lösung ist eine
    > variable thread Programmierung. Das so etwas
    > möglich ist zeigen wissenschaftliche Simulationen
    > oder Datenbanken wie MSSQL oder DB2. Das Problem
    > dabei ist allerdings dass eine solche
    > Programmierung kompliziert ist und eine gute
    > koordination im Entwicklungsteam voraussetzt. Hier
    > scheint es bei den Spieleprogrammierern am meisten
    > zu hapern. Sie haben 1. keinerlei Erfahrung mit
    > diesen Techniken und 2. sind die Teams meist nicht
    > lange genug zusammen um ein wirklich effektives
    > System zu schaffen. Bei den Spielefirmen bei denen
    > ich bisher war herrschte ein Hire und Fire
    > Prinzip, mit ständig anderen Leuten wird es schwer
    > ein solches System zu entwickeln. An Datenbanken
    > entwickeln einige Teams in fast unveränderter
    > Zusammensetzung bereits 15 Jahre und mehr das sich
    > dort eine bessere Programmierkultur entwickelt hat
    > dürfte klar sein.

    Also ich habe das anders verstanden:
    Zwar wird der Sound nur mit einem Core berechnet aber das heisst nicht, dass dieser Core nicht auch noch andere Berechnungen durchführen kann!
    Es macht doch durchaus Sinn, ein Thread der wenig Leistung braucht in nur einem Core zu berechnen. Hingegen die Prozesse die viel Leistung brauchen aufzuteilen. Somit gibt es weniger Overhead für die Synchronisation der Prozosse.

    Oder seh ich das falsch?

    mfg

  5. Re: Primitivlösung

    Autor: Nouse4livE 07.11.06 - 13:18

    adba schrieb:
    -------------------------------------------------------
    > programmierer schrieb:
    > --------------------------------------------------
    > -----
    > > Der Ansatz von Valve ist eine
    > Primitivlösung.
    > Natürlich ist es einfach z.B.
    > den Sound komplett
    > auf einen Kern zu legen.
    > Da aber der Sound eine
    > relativ einfache
    > Aufgabe ist wird die Core damit
    > nicht
    > ansatzweise ausgenutzt. Viel Portential geht
    >
    > so verloren. Ähnlich sieht es mit der
    > weiteren
    > starren Aufteilung der Aufgaben aus
    > wie Valve es
    > geplant hat. Die einzig
    > effektive Lösung ist eine
    > variable thread
    > Programmierung. Das so etwas
    > möglich ist
    > zeigen wissenschaftliche Simulationen
    > oder
    > Datenbanken wie MSSQL oder DB2. Das Problem
    >
    > dabei ist allerdings dass eine solche
    >
    > Programmierung kompliziert ist und eine gute
    >
    > koordination im Entwicklungsteam voraussetzt.
    > Hier
    > scheint es bei den Spieleprogrammierern
    > am meisten
    > zu hapern. Sie haben 1. keinerlei
    > Erfahrung mit
    > diesen Techniken und 2. sind
    > die Teams meist nicht
    > lange genug zusammen um
    > ein wirklich effektives
    > System zu schaffen.
    > Bei den Spielefirmen bei denen
    > ich bisher war
    > herrschte ein Hire und Fire
    > Prinzip, mit
    > ständig anderen Leuten wird es schwer
    > ein
    > solches System zu entwickeln. An Datenbanken
    >
    > entwickeln einige Teams in fast unveränderter
    >
    > Zusammensetzung bereits 15 Jahre und mehr das
    > sich
    > dort eine bessere Programmierkultur
    > entwickelt hat
    > dürfte klar sein.
    >
    > Also ich habe das anders verstanden:
    > Zwar wird der Sound nur mit einem Core berechnet
    > aber das heisst nicht, dass dieser Core nicht auch
    > noch andere Berechnungen durchführen kann!
    > Es macht doch durchaus Sinn, ein Thread der wenig
    > Leistung braucht in nur einem Core zu berechnen.
    > Hingegen die Prozesse die viel Leistung brauchen
    > aufzuteilen. Somit gibt es weniger Overhead für
    > die Synchronisation der Prozosse.
    >
    > Oder seh ich das falsch?
    >
    > mfg
    >
    >
    so hab ichs auch verstanden... bin aber auch kein informatiker...
    am ende wird man eh sehen obs nun soviel bringt wie valve behauptet
    oder halt weniger...
    aber iss eh egal für cs-müll kauf ich mir ja keinen Quad-Core....

  6. Re: Primitivlösung

    Autor: boogey 07.11.06 - 13:19

    > ...Ich frage mich wo die Leute
    > bei Valve studiert haben.

    Falsche Frage! Nicht WO haben sie studiert, sondern WAS!

    Und was ist das nun? Richtig! Ihre Budgetplanung haben sie eingehend studiert und da ist nunmal kein Platz für flexible Lösungen, weil, wie vorher schon von jemanden gesagt, dass viel zu lange dauert und entsprechend zu viel Geld kostet.
    Glaubt ja nicht, dass Valve so dermassen reich ist.

    > An Datenbanken entwickeln einige Teams in fast unveränderter
    > Zusammensetzung bereits 15 Jahre und mehr

    Richtig erfasst! Datenbanken!
    Die laufen aber auch meist auf Servern und Server haben bekanntermassen schon seit etlichen Multiprozessormaschinen, was natürlich auch bedeutet, dass schon seit vielen Jahren echtes Multithreading möglichen ist, entsprechend können DBs das auch.

    Clientseitige Spiele hingegen waren mit diesem Problem nie konfrontiert, da Multicore und Multi-CPU erst seit relativ kurzer Zeit dabei sind, sich im Desktopbereich durchzusetzen.

    Aber ansonsten stimmt das natürlich. Die Hire&Fire Politik in der Computerspieleindustrie ist unfassbar.

    gruss
    boogey

  7. Re: Primitivlösung

    Autor: nurso 07.11.06 - 13:25

    programmierer schrieb:
    -------------------------------------------------------
    > [...]
    > Bei den Spielefirmen bei denen
    > ich bisher war herrschte ein Hire und Fire
    > Prinzip, mit ständig anderen Leuten wird es schwer
    > ein solches System zu entwickeln.

    hast du ein paar anekdoten auf lager?

    mfg


  8. nicht ganz

    Autor: @ 07.11.06 - 13:30

    Video und Sound können einen Kern sehr wohl auslasten - allerdings trifft das auf heutige CPU-Kerne mit 1.6 GHz von der reinen Rechenleistung her nicht mehr ganz zu. Das Bottleneck ist da eher der Speicher.

    Dennoch kann es jedoch Sinn machen, die Aufteilung eher im negativen Sinne dennoch pro Kern zu machen:

    Die entsprechende Bedingung wäre dann einfach, Audio und Video eben nicht auf *demselben* Kern dekodieren zu lassen (mutually exclusive core binding).

    siehe auch:
    https://forum.golem.de/read.php?14278,772610,772610#msg-772610

    programmierer schrieb:
    -------------------------------------------------------
    > Der Ansatz von Valve ist eine Primitivlösung.
    > Natürlich ist es einfach z.B. den Sound komplett
    > auf einen Kern zu legen. Da aber der Sound eine
    > relativ einfache Aufgabe ist wird die Core damit
    > nicht ansatzweise ausgenutzt. Viel Portential geht
    > so verloren. Ähnlich sieht es mit der weiteren
    > starren Aufteilung der Aufgaben aus wie Valve es
    > geplant hat. Die einzig effektive Lösung ist eine
    > variable thread Programmierung. Das so etwas
    > möglich ist zeigen wissenschaftliche Simulationen
    > oder Datenbanken wie MSSQL oder DB2. Das Problem
    > dabei ist allerdings dass eine solche
    > Programmierung kompliziert ist und eine gute
    > koordination im Entwicklungsteam voraussetzt. Hier
    > scheint es bei den Spieleprogrammierern am meisten
    > zu hapern. Sie haben 1. keinerlei Erfahrung mit
    > diesen Techniken und 2. sind die Teams meist nicht
    > lange genug zusammen um ein wirklich effektives
    > System zu schaffen. Bei den Spielefirmen bei denen
    > ich bisher war herrschte ein Hire und Fire
    > Prinzip, mit ständig anderen Leuten wird es schwer
    > ein solches System zu entwickeln. An Datenbanken
    > entwickeln einige Teams in fast unveränderter
    > Zusammensetzung bereits 15 Jahre und mehr das sich
    > dort eine bessere Programmierkultur entwickelt hat
    > dürfte klar sein.


  9. Re: Primitivlösung

    Autor: nie (Golem.de) 07.11.06 - 13:32

    Valves Ansatz ist es, nur bestimmte Aufgaben, etwa den Sound, fest an einen Kern zu binden.

    Der Rest wird dynamisch verteilt, um eben Thread-Abhängigkeiten zu minimieren und die Cores immer gut auszulasten.

    Dass dabei der Sound-Core vielleicht noch Kapazität frei hat, und andere Dinge tun kann, hat Valve so nicht gesagt, erscheint aber wahrscheinlich.

  10. ergänzung

    Autor: @ 07.11.06 - 13:37

    Hier liegst Du zwar nicht falsch, machst aber dennoch einen Denkfehler: bei Spielen entfällt die Hauptlast auf Dinge wie Grafikdarstellung, Animationsdekodierung, Audioausgabe und Rendering sowie Szenenberechnungen.

    Die richtige Verzahnung von Video und Audio ist kritisch, da Fehler sehr schnell bemerkt werden und Irritationen hervorrufen - ähnlich wie Ruckeln bei einem Software-DVD-Player.

    Das macht jede entsprechende Thread-Lösung stark asynchron, da die Threads sehr unterschiedlich zu priorisieren sind.

    Ich denke nicht, dass das mit einem System mit mySQL zu vergleichen ist: hier kommt vielleicht eine (weitere) Anfrage eines Users an die DB über das WWW rein. Sie wird dann von einem Thread auf einem Core angenommen und abgearbeitet, der "gerade" nicht so ausgelastet ist. Würde aber dieser Core plötzlich anfangen, nebenbei mit hoher Priorität in einem anderen Thread Audio zu dekodieren, müsste der Web-User plötzlich "ewig" warten - das verschieben seines Threads auf eine andere CPU wäre möglicherweise ebenfalls kontraproduktiv (erstens ist die Logik dafür noch komplexer und zweitens könnte das im Worst Case bedeuten, dass die meiste Rechenzeit auf solche Wechsel entfällt).

    programmierer:
    > Die einzig effektive Lösung ist eine
    > variable thread Programmierung. Das so etwas
    > möglich ist zeigen wissenschaftliche Simulationen
    > oder Datenbanken wie MSSQL oder DB2. Das Problem

  11. Re: Primitivlösung

    Autor: probemensch 07.11.06 - 13:39

    programmierer schrieb:
    -------------------------------------------------------
    > Der Ansatz von Valve ist eine Primitivlösung.
    > Natürlich ist es einfach z.B. den Sound komplett
    > auf einen Kern zu legen. Da aber der Sound eine
    > relativ einfache Aufgabe ist wird die Core damit
    > nicht ansatzweise ausgenutzt. Viel Portential geht
    > so verloren. Ähnlich sieht es mit der weiteren
    > starren Aufteilung der Aufgaben aus wie Valve es
    > geplant hat. Die einzig effektive Lösung ist eine
    > variable thread Programmierung. Das so etwas
    > möglich ist zeigen wissenschaftliche Simulationen
    > oder Datenbanken wie MSSQL oder DB2. Das Problem
    > dabei ist allerdings dass eine solche
    > Programmierung kompliziert ist und eine gute
    > koordination im Entwicklungsteam voraussetzt. Hier
    > scheint es bei den Spieleprogrammierern am meisten
    > zu hapern. Sie haben 1. keinerlei Erfahrung mit
    > diesen Techniken und 2. sind die Teams meist nicht
    > lange genug zusammen um ein wirklich effektives
    > System zu schaffen. Bei den Spielefirmen bei denen
    > ich bisher war herrschte ein Hire und Fire
    > Prinzip, mit ständig anderen Leuten wird es schwer
    > ein solches System zu entwickeln. An Datenbanken
    > entwickeln einige Teams in fast unveränderter
    > Zusammensetzung bereits 15 Jahre und mehr das sich
    > dort eine bessere Programmierkultur entwickelt hat
    > dürfte klar sein.

    Ich finds dennoch schon mal löblich das überhaupt mal einer den ersten Schritt macht und versucht seine Software auf neue Technologien anzupassen. Und der der den Ersten Schritt macht is doch bekanntlich häufig auch der der in den saueren Apfel beisst. Ich kenne aber keinen anderen Spielehersteller der schon etwas vergleichbares in diese Richtung auch nur im Sinn hat. In sofern sollte man es vielleicht nicht verachten sondern begrüßen, auf das nun endlich auch andere Software (hier in diesem fall Spiele) auf die neue Technologie getrimmt wird. :-)

  12. Re: Primitivlösung

    Autor: noquarter 07.11.06 - 13:42

    hmm ich glaube ich habe den Artikel etwas anders verstanden. Es wird immer nur der Kern für Sound oder Effekte verwendet, der gerade am wenigsten zu tun hat. Es macht durchaus Sinn, vorallem heißt das ja nicht das dieser Kern nicht mehr zu rechnen hat.

    Manchmal sind Aufgaben die komplett von einem Kern erledigt werden viel schneller als Aufgaben die in Threads aufgeteilt werden.

  13. Re: Primitivlösung

    Autor: @ 07.11.06 - 13:42

    Ich verstehe das eher so, dass Threads, die bei der Ausgabe (Output) voneinander abhängen, bei der Verarbeitung (Processing) per CPU-Core getrennt sein sollten, da das System dann so gut wie gar nicht mehr von cpuzeit-bedingten Latenzen gestört werden kann, es sei denn, der Eingabestrom (Input) hat ein Problem.

    MPEG2 (Audio & Video)

    => Audio Core #1
    => Video Core #2
    => Rest dynamisch verteilt

    adba schrieb:
    -------------------------------------------------------

    > Also ich habe das anders verstanden:
    > Zwar wird der Sound nur mit einem Core berechnet
    > aber das heisst nicht, dass dieser Core nicht auch
    > noch andere Berechnungen durchführen kann!
    > Es macht doch durchaus Sinn, ein Thread der wenig
    > Leistung braucht in nur einem Core zu berechnen.
    > Hingegen die Prozesse die viel Leistung brauchen
    > aufzuteilen. Somit gibt es weniger Overhead für
    > die Synchronisation der Prozosse.
    >
    > Oder seh ich das falsch?
    >
    > mfg
    >
    >


  14. Re: Primitivlösung

    Autor: Herr von Plaubitz 07.11.06 - 13:56

    Bytebeisser schrieb:
    -------------------------------------------------------

    > Ich habe den Artikel garade unserem Informatik
    > Prof gezeigt. Der hat nur die Hände über dme Kopf
    > zusammengeschlagen.

    Ich habe den Artikel meiner Putzfrau gezeigt. Die war ganz zufrieden. Letzte Woche war sie mit ihrem Adoptivsohn im Zoo, bei den Pavianen. Die Fütterung hat ihr gefallen, sagte sie.

  15. Re: Primitivlösung

    Autor: ~jaja~ 07.11.06 - 14:20

    matze 81 schrieb:
    -------------------------------------------------------
    > Ich frage mich wo die Leute
    > bei Valve studiert haben.

    Gabe Newell, Valves Chef war vorher bei Microsoft. Was glaubst du wo die blöde Sau die Idee für Steam her hat? ~g~


    "Let us hear the suspicions. I will look after the proofs." Sherlock Holmes - The Adventure of the Three Students

  16. Re: Primitivlösung

    Autor: blacky 07.11.06 - 14:24

    probemensch schrieb:
    -------------------------------------------------------
    >
    > Ich finds dennoch schon mal löblich das überhaupt
    > mal einer den ersten Schritt macht und versucht
    > seine Software auf neue Technologien anzupassen.
    > Und der der den Ersten Schritt macht is doch
    > bekanntlich häufig auch der der in den saueren
    > Apfel beisst. Ich kenne aber keinen anderen
    > Spielehersteller der schon etwas vergleichbares in
    > diese Richtung auch nur im Sinn hat. In sofern
    > sollte man es vielleicht nicht verachten sondern
    > begrüßen, auf das nun endlich auch andere Software
    > (hier in diesem fall Spiele) auf die neue
    > Technologie getrimmt wird. :-)


    Ah Danke :)
    Endlich mal jemand der Valve lobt..
    Ich kanns nur immer wieder sagen.. Ich hab CSS 1x bezahlt das ist nun 2 Jahre her und was macht Valve dauernd? CSS wird laufend ausgebaut, den neuen Technologien angepasst und und und.. und was zahlen wir dafuer? Jup.. schon lange nichts mehr.. So muss das sein, das ist Kundensupport..

    Hier wird ja eigentlich nicht gepatcht.. Valve entwickelt weiter und ist fuer mich alleine daher schon vorbildlich und EA sollte das auch so machen :)

  17. Re: Primitivlösung

    Autor: adba 07.11.06 - 14:38

    @ schrieb:
    -------------------------------------------------------
    > Ich verstehe das eher so, dass Threads, die bei
    > der Ausgabe (Output) voneinander abhängen, bei der
    > Verarbeitung (Processing) per CPU-Core getrennt
    > sein sollten, da das System dann so gut wie gar
    > nicht mehr von cpuzeit-bedingten Latenzen gestört
    > werden kann, es sei denn, der Eingabestrom (Input)
    > hat ein Problem.
    >
    > MPEG2 (Audio & Video)
    >
    > => Audio Core #1
    > => Video Core #2
    > => Rest dynamisch verteilt
    >


    Das macht Sinn...
    Was allerdings das Problem ist, dass die Frameraten "nur" 35% gesteigert werden, ist doch, dass für die Berechung der Grafik vor allem die Grafikkarte benötigt wird und nicht die CPU.
    Aber ich freue mich auf besser KI und Physik!

  18. Re: Primitivlösung

    Autor: Tropper 07.11.06 - 14:53

    adba schrieb:
    > Das macht Sinn...
    > Was allerdings das Problem ist, dass die
    > Frameraten "nur" 35% gesteigert werden, ist doch,
    > dass für die Berechung der Grafik vor allem die
    > Grafikkarte benötigt wird und nicht die CPU.
    > Aber ich freue mich auf besser KI und Physik!

    Dafür muss der Rest aber nicht warten bis alle Geometriedaten an die GPU Geschickt sind - geht allerdings auf dem Speicher da immer mindestens 2 Komplette Szenen im Speicher gehalten werden müssen (wobei das bei heutigen Speicherpreisen wohl zu vernachlässigen ist). Quake3 konnte das übrigens auch schon (da waren es allerdings 3 Szenen).

    Tropper


  19. Re: Primitivlösung

    Autor: rotfuxx 07.11.06 - 15:11

    es mag ja noch so primitiv sein, einen wirtschaftlichen kosten-/nutzen-faktor erzielen zu wollen ;) - aber wo bitte ist das problem daran, wenn eine firma eine (!)bestehende(!) engine soweit aufbohren will, dass sie mehr leistung generiert?

    ich sehe das so: theoretisch wären 180% der aktuellen leistung möglich (die verbleibenden 20% möchte ich mal für hintergrundprozesse sowie synchronisation zwischen den zwei / vier kernen draufgehen lassen). praktisch werden 30 - 50% mehr leistung erzielt. natürlich ist damit das optimum überhaupt nicht einmal angekratzt, aber ist es verkehrt, wenn immerhin dieser weg gegangen wird?
    ist es nicht sowieso so, dass selbst bei optimaler lastenverteilung auf die diversen cores niemals eine vervielfachung der leistung um den faktor (anzahl-kerne) erreichen kann, weil z.b. das perfekteste multithreading nichts bringt, wenn die graka aus dem letzten loch pfeifft?
    und unter diesem gesichtspunkt finde ich einen leistungsschub von 40% im DURCHSCHNITT ziemlich erstaunlich, da diese 40% ja nicht die tatsächliche optimierung zeigen, sondern nur den faktor, der sich aus den unterschiedlichen leistungen aller systemkomponenten ergibt.
    und nochmal: valve redet hier immer noch von der anpassung einer bereits bestehenden engine, die von release zu release bisher nie neu entwickelt, sondern immer nur um neue features bereichert wurde...


    programmierer schrieb:
    -------------------------------------------------------
    > Der Ansatz von Valve ist eine Primitivlösung.
    > Natürlich ist es einfach z.B. den Sound komplett
    > auf einen Kern zu legen. Da aber der Sound eine
    > relativ einfache Aufgabe ist wird die Core damit
    > nicht ansatzweise ausgenutzt. Viel Portential geht
    > so verloren. Ähnlich sieht es mit der weiteren
    > starren Aufteilung der Aufgaben aus wie Valve es
    > geplant hat. Die einzig effektive Lösung ist eine
    > variable thread Programmierung. Das so etwas
    > möglich ist zeigen wissenschaftliche Simulationen
    > oder Datenbanken wie MSSQL oder DB2. Das Problem
    > dabei ist allerdings dass eine solche
    > Programmierung kompliziert ist und eine gute
    > koordination im Entwicklungsteam voraussetzt. Hier
    > scheint es bei den Spieleprogrammierern am meisten
    > zu hapern. Sie haben 1. keinerlei Erfahrung mit
    > diesen Techniken und 2. sind die Teams meist nicht
    > lange genug zusammen um ein wirklich effektives
    > System zu schaffen. Bei den Spielefirmen bei denen
    > ich bisher war herrschte ein Hire und Fire
    > Prinzip, mit ständig anderen Leuten wird es schwer
    > ein solches System zu entwickeln. An Datenbanken
    > entwickeln einige Teams in fast unveränderter
    > Zusammensetzung bereits 15 Jahre und mehr das sich
    > dort eine bessere Programmierkultur entwickelt hat
    > dürfte klar sein.


  20. Re: Primitivlösung

    Autor: Cespenar 07.11.06 - 15:19

    Herr von Plaubitz schrieb:
    -------------------------------------------------------
    > Bytebeisser schrieb:
    > --------------------------------------------------
    > -----
    >
    > > Ich habe den Artikel garade unserem
    > Informatik
    > Prof gezeigt. Der hat nur die
    > Hände über dme Kopf
    > zusammengeschlagen.
    >
    > Ich habe den Artikel meiner Putzfrau gezeigt. Die
    > war ganz zufrieden. Letzte Woche war sie mit ihrem
    > Adoptivsohn im Zoo, bei den Pavianen. Die
    > Fütterung hat ihr gefallen, sagte sie.


    ++

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Amprion GmbH, Dortmund
  2. Horváth & Partners Management Consultants, Berlin, Düsseldorf, Frankfurt am Main, Hamburg, München, Stuttgart
  3. EnBW Energie Baden-Württemberg AG Holding, Köln
  4. CureVac AG, Tübingen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-77%) 13,99€
  2. (-71%) 11,50€


Haben wir etwas übersehen?

E-Mail an news@golem.de


5G-Report: Nicht jedes Land braucht zur Frequenzvergabe Auktionen
5G-Report
Nicht jedes Land braucht zur Frequenzvergabe Auktionen

Die umstrittene Versteigerung von 5G-Frequenzen durch die Bundesnetzagentur ist zu Ende. Die Debatte darüber, wie Funkspektrum verteilt werden soll, geht weiter. Wir haben uns die Praxis in anderen Ländern angeschaut.
Ein Bericht von Stefan Krempl

  1. Vodafone 5G-Technik funkt im Werk des Elektroautoherstellers e.Go
  2. Testlabor-Leiter 5G bringt durch "mehr Antennen weniger Strahlung"
  3. Sindelfingen Mercedes und Telefónica Deutschland errichten 5G-Netz

Wolfenstein Youngblood angespielt: Warum wurden diese dämlichen Mädchen nicht aufgehalten!?
Wolfenstein Youngblood angespielt
"Warum wurden diese dämlichen Mädchen nicht aufgehalten!?"

E3 2019 Der erste Kill ist der schwerste: In Wolfenstein Youngblood kämpfen die beiden Töchter von B.J. Blazkowicz gegen Nazis. Golem.de hat sich mit Jess und Soph durch einen Zeppelin über dem belagerten Paris gekämpft.
Von Peter Steinlechner


    Autonomes Fahren: Per Fernsteuerung durch die Baustelle
    Autonomes Fahren
    Per Fernsteuerung durch die Baustelle

    Was passiert, wenn autonome Autos in einer Verkehrssituation nicht mehr weiterwissen? Ein Berliner Fraunhofer-Institut hat dazu eine sehr datensparsame Fernsteuerung entwickelt. Doch es wird auch vor der Technik gewarnt.
    Ein Bericht von Friedhelm Greis

    1. Neues Geschäftsfeld Huawei soll an autonomen Autos arbeiten
    2. Taxifahrzeug Volvo baut für Uber Basis eines autonomen Autos
    3. Autonomes Fahren Halter sollen bei Hackerangriffen auf Autos haften

    1. iPhone: Apple warnt Trump vor Einfuhrzöllen auf China-Produktion
      iPhone
      Apple warnt Trump vor Einfuhrzöllen auf China-Produktion

      Apple wehrt sich gegen Einfuhrzölle für seine Produkte, die zum großen Teil von Foxconn in China montiert werden. Zugleich arbeitet Apple an einer Verlagerung nach Südostasien. Foxconn beginnt zeitgleich die Vorbereitungen für die Fertigung neuer iPhones in China

    2. Dunkle Energie: Deutsches Röntgenteleskop Erosita ist startklar
      Dunkle Energie
      Deutsches Röntgenteleskop Erosita ist startklar

      Das Universum dehnt sich immer schneller aus. Der Motor dafür wird - mangels besseren Wissens - als Dunkle Energie bezeichnet. Ein deutsch-russischer Satellit mit einem in Deutschland entwickelten Röntgenteleskop an Bord soll Erkenntnisse über die Dunkle Materie liefern.

    3. Smartphones: Huawei will Android Q für 17 Smartphones bringen
      Smartphones
      Huawei will Android Q für 17 Smartphones bringen

      Der US-Boykott dauert weiter an, Huawei verspricht aber auch künftig Android-Updates für seine Smartphones anbieten zu wollen. Auch das neue Android Q soll für eine Reihe von Geräten erscheinen - Huaweis aktuelle Mitteilung bleibt an einigen Stellen aber vage.


    1. 19:16

    2. 19:02

    3. 17:35

    4. 15:52

    5. 15:41

    6. 15:08

    7. 15:01

    8. 15:00