spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Solange dieser aber nicht auf die Frage antwortet, wie er das denn bisher genau macht, kann man ihm allerdings nicht sonderlich gut helfen.

Was bei Performance noch hilft.

Addition mit negativen Zahlen soll angeblich schneller sein als Subtraktion.

"int" wird schneller verarbeitet als andere typen.
"double" wird schneller verabeitet als "float".

Das war wass ich so bisher weis. Jedoch wenn eine Prozedur mir zu lahm war dann habe ich einfach mit dem Profiler geschaut wo es hakt

Zitat von »Techie«

Addition mit negativen Zahlen soll angeblich schneller sein als Subtraktion.

Nicht die Maschinenbefehle auf x86/x64, die sind exakt gleich schnell.

Zitat von »Techie«

"int" wird schneller verarbeitet als andere typen.

Ne, das ist so gesagt nicht richtig. Jedenfalls nicht auf x86 oder gar x64. Inbesondere ist int heutzutage nicht mehr der Typ der Arichtekturbreite. Siehe x64.
Dort werden alle Integertypen prinzipiell gleich schnell verarbeitet. Auf x64 sogar ja auch noch 64 Bit Integer.
Die typischen Operationen, alles Bitweise, Addition, Subtraktion Multiplikation ist dort ~ gleich schnell in allen Breiten. Einzig und allein bei der Division sind in der Regel bei kleineren Typen deutlich schneller.

Zitat von »Techie«

"double" wird schneller verabeitet als "float".

Das "double" schneller ist als "float" stimmt auch nicht. Tatsächlich ist hier der theoretische Unterschied wenn man die Befehle auch in der Regel sehr gering und in der Regel nicht beachtenswert. Auf der veralteten x87 FPU gibt es sogar intern nur einen einzigen 80 Bit breiten Typ mit dem gerechnet werden kann. Zu einem größeren Unterschied kommt es dagegen zum Beispiel dann, wenn die Auto-Vektorisierung einspringt. "double" ist wie der Name sagt doppelt so groß und nimmt daher doppelt soviel Platz in den 128 Bit SSE Registern weg. Das heißt dort ist der Durchsatz bei "double" prinzipiell halbiert weil dort nur 2 Operationen anstatt 4 gleichzeitig ausgeführt werden können.

Außerdem ist je nach Anwendung außerhalb von Mikrobenchmarks aber noch etwas anderes viel limitierender: Der Cache. Große Typen also zum Beispiel "double" nehmen, wenn sie dauerhaft in einer Datenstruktur gespeichert werden dauerhaft Cache weg. Und das doppelt so viel und das wird in den aller meisten Fällen viel schwerer wiegen als alles andere. Das Gleiche trifft natürlich auch bei 64 Bit Integer vs extrem Beispiel 8 Bit zu.

Prinzipiell meine zusätzlichen Optimierungstipps für x86/x64 in extremer Kürze:
Datenstruktur, Parallelisierung, Cacheoptimierungen(Allokationen, Datenorientierung, passende Typen...), Funktionszeiger("virtual")/Verzweigungen vermeiden("Conditional Move"), ggf. manuelle Vektorisierung(SIMD), ...
Daneben natürlich profilen und beim Testen wirklich gewissenhaft sein. Da gibt es extrem viele Dinge die man falsch machen kann und das Ergebnis verfälschen oder nicht vergleichbar machen. Das habe ich selbst sehr häufig erfahren müssen.

Und ja, das geht langsam richtig Offtopic weil ich immer noch nicht glaube, dass es hier um so ein Problem handelt. Wenn hier so Unwissen verbreitet wird, kann ich das schwer ignorieren.

Zitat von »Techie«

Bei 35 FPS würde das nicht ruckeln....

Darauf möchte ich kurz damit eingehen...

MfG
Check

Wozu willst du das tun?
Dafür gibt's doch Transformationsmatrizen.

Und dann willst du für 1000 Objekte jeweils eine eigene Kopie ihres Meshes erzeugen, in der die Position schon fest in den Eckpunkten drin ist, oder wie?
Wenn ja: Damit machst du alles nur schlimmer. Die paar Multiplikationen/Additionen sind für die Grafikkarte ein Witz - viel wichtiger ist, dass du möglichst große Batches renderst, d.h. möglichst wenige Draw Calls hast (natürlich dabei auch nicht übermäßig viel rendern, was eh nicht sichtbar ist).

Generelle Empfehlung: Erst optimieren, wenn es sein muss, und dann an der richtigen Stelle und nicht im Vorhinein auf Verdacht. Benutze Profiler, um die heißen Stellen im Code zu finden. Gerade wenn man wenig Erfahrung hat, liegt man mit dem Bauchgefühl, was schnell und was langsam ist, sehr häufig falsch. Dann "optimiert" man an auf falsche Weise und an der falschen Stelle, und am Ende wird's langsamer statt schneller.

Und natürlich die üblichen Punkte:

• Release- statt Debug-Build
  
• nicht aus Visual Studio heraus starten sondern die exe einzeln feuern
  
• I/O (Festplatte, Konsole, Datenbanken) möglichst Vermeiden
  
• etc.p.p.
  

Faustformel Optimierung:
Don't do it!
Faustformel Optimierung für Profis:
Don't do it now!

So Far...
Laguna

Mein Post beruht auf einen Artikel der anscheinend gelöscht wurde, mittlerweile verstehe ich auch warum

Hier ist noch ein interessanter Artikel dazu:
http://www.codeproject.com/Articles/6154…de-Optimization