STL ungeeignet für Spieleprogrammierung?
-
otze schrieb:
muss mich auch mal einklinken
Was hat der Cache mit einer effizienz des algorithmus zu tun? oder mit der implementierung? waren algorithmen nicht sprachen/computerunabhängig? Und selbst wenn der Algorithmus jetzt an der limitierung des Caches scheitert, heisst das nicht, dass er bei anderen systemen, deren cache größere dimensionen hat, nicht abgeht wie schmitz Katze ;). Genau das gleiche seh ich auch in der implementierung. Eine langsame implementierung ist systemabhängig, es kommt wie immer darauf an, worauf das system optimiert wurde. Deshalb halte ich von der Diskussion relativ wenig, da das ganze stark situationsabhängig ist. Wenn das system eine extrem effektive bitblast funktion hat, dann kann unter umständen ein algorithmus, der viel kopiert effektiver sein, als ein algorithmus, der wenig kopiert. Dass etwas jetzt nicht gut funktioniert, heisst nicht, dass es niemals gut funktioniert.Der Meister hat gesprochen.
-
Wenn man die STL nimmt, erübrigt sich Fehlerfreiheit und komplizierte Implementierung sowieso. Und darum ging es hier.
Bye, TGGC Deine Unterstützung wird gebraucht!
-
Optimizer schrieb:
Jetzt geht es auf einmal um "komplizierter und fehleranfälliger".
irgendjemand hat das thema ja auch auf premature optimization gelenkt und DA spielt fehleranfälligkeit und komplizierte implementierung wohl durchaus eine rolle, oder? in der phase ist ein theoretisch super-effizenter aber komplizierter alg. ja sogar noch uninteressanter und wenn es wirklich ans optimieren geht, dann zählt die in der realen welt schnellste methode mehr als die schnellste methode auf dem papier. und wenn dabei rauskommt, daß log n unmöglich so implementiert werden kann, daß es schneller ist als n, dann.. pfeif ich gediegen auf die theorie und benutze das, was auch funktioniert.
wir hatten mittlerweile ein paar beispiele, damit bewiesen, daß die notation oft, aber nicht immer weiterhilft. eine methode, von der ich erst hinterher wissen kann, ob sie für meinen speziellen fall anwendbar ist oder nicht betrachte ich als sehr eingeschränkt nützlich.
ergo ist mein gedankengang "hmm, drei verschachtelte schleifen sind nicht gut, aber der kern läßt sich gut optimieren und mehr als x objekte werdens wohl nicht.. oder nur eine schleife, aber dafür viel rumkopieren, schreibende zugriffe und ein ineffizenter kern".. und eben nicht "ok o(n^3), o(n), ich nehm den zweiten".
-
rgendjemand hat das thema ja auch auf premature optimization gelenkt
Richtig, nämlich du. Lies nochmal ein bisschen zurück, dann wirst du feststellen, dass du angefangen hast nach dem Motto "wenn man das [caching] im vornherein schon berücksichtigt..."
dann zählt die in der realen welt schnellste methode mehr als die schnellste methode auf dem papier.
seufz.
eine methode, von der ich erst hinterher wissen kann, ob sie für meinen speziellen fall anwendbar ist oder nicht betrachte ich als sehr eingeschränkt nützlich.
Krass, du tust ja jetzt gerade so, als wäre das ein Ausnahmefall, wo ein Algorithmus, der effizienter ist, sich implementieren lässt. Das ist fast immer der Fall, man.
Naja ich klink mich jetzt dann mal aus. Wie du das interpretierst, ist mir relativ egal, jetzt haben dir wirklich genug Leute gesagt, dass der Algorithmus mit der besseren Ordnung fast immer vorzuzuiehen ist (wohlgemerkt, wir reden von Hotspots im Programm). Und wenn man vielleicht auch noch den einen oder anderen Algo in der STL findet, sowieso.
