spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"FalkT"«

	C-/C++-Quelltext
1 2 3	int a = x / 2; // sehr nett :D int a = x * 0.5; // definitiv schneller int a = x >> 1; // auch schnell

Wobei jeder halbwegs gescheite Compiler das so weg optimiert, dass alles genau gleich schnell ist. Wenn der Faktor natürlich nicht konstant ist, also in einer Variable stehen, dann stimmt es natürlich.

Zitat von »"Nexus"«

1-Bit-Fliesskommazahlen wären recht ungenau. Ich denke auch nicht, dass viele Prozessoren Befehle für 1-Bit-Fliesskommaarithmetik kennen.

In der Tat, schließlich könnte man mit 1 Bit genau 2 Zahlen darstellen!

Zitat von »"FalkT"«

	C-/C++-Quelltext
1 2	int a = x / 2; // sehr nett :D int a = x * 0.5; // definitiv schneller

Nein, das wäre langsamer, wenn er es so machen würde - denn er müsste zwischen int und double hin und her rechnen!

Zitat von »"David Scherfgen"«

Zitat von »"Nexus"«

1-Bit-Fliesskommazahlen wären recht ungenau. Ich denke auch nicht, dass viele Prozessoren Befehle für 1-Bit-Fliesskommaarithmetik kennen.

In der Tat, schließlich könnte man mit 1 Bit genau 2 Zahlen darstellen!

ich denke er meint einen byte

Zitat von »"FalkT"«

	C-/C++-Quelltext
1 2	int a = x / 2; // sehr nett :D int a = x * 0.5; // definitiv schneller

meines wissens macht der compiler letztendlich den gleichen maschinencode draus.

wäre bei so ein einfachen Robo mit schwachen Bauteilen nicht besser mit C oder noch besser mit assemblern zu programmieren..

Ist der aufwand zwar größer aber das ergebnis vl besser..
Die Kollegen hier wissen das aber sicher besser.

Zitat von »"David Scherfgen"«

In der Tat, schließlich könnte man mit 1 Bit genau 2 Zahlen darstellen!

Gibt doch ein paar sinnvolle Operationen, die man mit 1 Bit durchführen kann. Invertieren zum Beispiel. :lol:
Ich meinte natürlich Byte...

Zitat von »"fred2507"«

meines wissens macht der compiler letztendlich den gleichen maschinencode draus.

Das kommt sehr auf den Compiler an. Aber ohne Optimierungen - rein von C++ her - entstehen unterschiedliche Codes. Die erste Anweisung erzeugt eine Integer-Division durch zwei, die zweite eine Fliesskomma-Multiplikation (double) und Umwandlung. Und ich habe das Gefühl, dass / 2 viel viel leichter zu einem Shift wegoptimiert werden kann als * 0.5.

Zitat von »"Sizzla"«

wäre bei so ein einfachen Robo mit schwachen Bauteilen nicht besser mit C oder noch besser mit assemblern zu programmieren..

Ist der aufwand zwar größer aber das ergebnis vl besser..

Naja, grundsätzlich kann man fast alles, was in C möglich ist, auch in C++ hinbringen. Zudem hat Abstraktion keinen direkten Einfluss auf die Laufzeit - objektorientierter Code ist nicht langsamer. Allerdings können gewisse konkrete Implementierungen wie die STL auf auf die allgemeine Verwendung optimiert sein, was bei Mikrokontrollern unter Umständen einen Nachteil mit sich bringt (zum Beispiel seitens Code-Bloat und Speicherverbrauch).

Ich kann mich nur wiederholen: Bevor man voreilige Schlüsse zieht und dann möglicherweise einen Weg wählt, der viel mühsamer ist, aber kaum Performancegewinne bringt, sollte man sich genau informieren und Zeiten messen. Dann können die wirklichen Flaschenhälse genauer betrachtet werden. Üblicherweise sind das nicht Divisionen (kann natürlich trotzdem sein).

Zitat von »"Nexus"«

Naja, grundsätzlich kann man fast alles, was in C möglich ist, auch in C++ hinbringen. Zudem hat Abstraktion keinen direkten Einfluss auf die Laufzeit - objektorientierter Code ist nicht langsamer.

Oooch, er kann durchaus langsamer sein. Vielleicht weil einiges Private ist und man einen Funktionsaufruf braucht, um an den Wert zu kommen (der dumemrweise gerade nciht inline war), oder wenn man virtuelle Funktionen benutzt, wo die arme CPU dann erst die Funktionsadresse raussuchen muss.
Ich will damit nur sagen, dass im extremen LowLevel Bereich eine komplexe Objekthierarchie schon ein wenig was ausmachen kann. (In allen anderen Fällen ist OOP natürlich toll, weil man schneller ist und weniger Fehler macht).

Zitat von »"Jonathan_Klein"«

Oooch, er kann durchaus langsamer sein.

Klar, aber objektorientierter Code ist nicht per se langsamer. Genauso kann er schneller sein. Schönes Beispiel, wo C++ gegenüber C einen Vorteil hat, ist bei std::sort() vs. qsort(), weil der übergebene Funktor direkt geinlinet werden kann, während bei C nur ein typenloser Funktionszeiger vorhanden ist. Natürlich kann es sein, dass man durch einzelne Low-Level-Algorithmen besser optimieren kann, weil man sich direkt an die Hardware anpasst. Dazu muss man sich allerdings recht gut auskennen; es braucht nicht viel, bis man trotzdem schlechtere Resulate erzielt. Von daher sollte man sich an solche Möglichkeiten erst heranwagen, wenn es keine anderen Auswege mehr gibt und am betreffenden Ort ein tatsächliches Performanceproblem besteht. Zudem ist zu bedenken, dass heutige Compiler sehr gut optimieren können - teilweise besser als der Mensch.

Was mich stört, ist der verbreitete Irrglaube, dass Objektorientierung und Abstraktion schlechtere Laufzeitverhältnisse implizieren. Virtuelle Funktionen sind zum Beispiel ein weiteres Schlagwort für Langsamkeit. Sehr selten denkt dabei jemand daran, dass auch auf tieferer Abstraktionsebene eine Auswahl zwischen verschiedenen Ablaufpfaden realisiert werden muss - ob das schlussendlich if, switch, selbst gebaute Funktionszeiger-Sprungtabellen oder gleich "richtige" virtuelle Funktionen sind, spielt im Allgemeinen keine grosser Rolle mehr.