spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ok, wenn Performance eine Rolle spielt willst du da wohl sowieso mit SSE ansetzen, womit das alles hinfällig wird. Ansonsten wohl einfach mit unsigned char Arrays und memcpy() arbeiten. Für etwas mehr Performance ist memcpy() in einen int vermutlich eine ganz gute und recht portable Lösung über deren Wohldefiniertheit man von mir aus sogar diskutieren kann. Vom union-Hack würde ich mich auf jeden Fall fern halten, der ist definitiv UB...

Zitat von »dot«

Vom union-Hack würde ich mich auf jeden Fall fern halten, der ist definitiv UB...

Gleichzeitig aber auch so bekannt, dass die meisten Compiler gut damit klar kommen, soweit ich das in den Diskussionen auf SO sehe.

Das ist schon richtig; ich persönlich bin halt kein Fan davon, mich von so Features abhängig zu machen, die lediglich supported werden, weil zuviel kaputter Code existiert, der zu funktionieren aufhören würde, wenn man es nicht mehr supported. Ein anderes Beispiel für sowas wären wohl all die magischen Garantien, die einige Compiler zu volatile Objekten machen...

memcpy wird halt meiner Erfahrung nach gelegentlich nicht wegoptimiert was in den Fällen einem Weltuntergang in Hinsicht auf Performance gleichkommt.

Die Frage ist, was sind dann die Alternativen? Und nicht immer möchte oder kann man SSE Intrinsics verwenden, die die Portabilität übrigens noch deutlich verschlechtern.

Das Verletzen von Strict Aliasing ist mit may_alias explixit erlaubt.

Zitat von »Spiele Programmierer«

memcpy wird halt meiner Erfahrung nach gelegentlich nicht wegoptimiert was in den Fällen einem Weltuntergang in Hinsicht auf Performance gleichkommt.

Nun, ich brauch das fast nie, aber alle Compilern, die ich getestet hab (MSVC, gcc, clang, icc), haben mir mein memcpy() zu einem move optimiert und, zumindest so lange Quelle und Ziel sich im lokalen Scope befinden, wäre ich wirklich schwer überrascht, wenn ein Compiler das plötzlich nicht mehr machen würde...

Zitat von »Spiele Programmierer«

Die Frage ist, was sind dann die Alternativen? Und nicht immer möchte oder kann man SSE Intrinsics verwenden, die die Portabilität übrigens noch deutlich verschlechtern.

Naja, wenn man Portabilität will, ist memcpy() imo die einzig akzeptable Lösung. Da es im konkreten Fall um das – vermutlich möglichst flotte – Bearbeiten eines Bitstream sowie Konvertieren zwischen half und single precision float geht, ist SSE imo schwer zu empfehlen, da das mehr Daten schaufeln kann und entsprechende Instructions hat. Zwar ist SSE natürlich Architekturspezifisch, die Intrinsics an sich aber zwischen Compilern/Plattformen portabel...

Zitat von »Spiele Programmierer«

Das Verletzen von Strict Aliasing ist mit may_alias explixit erlaubt.

Naja, das ist aber sogar noch weniger portabel als so manche Intrinsics...

Es geht schon noch um's Lesen von Streams, ja? Ich glaube kaum, dass das *die* Stelle ist, die unbedingt hohe Performance erfordert. Egal wozu memcpy optimiert oder nicht.

Anstatt einfach mal die paar Zeilen zu implementieren, sollten wir aber lieber noch ein paar Seiten hier diskutieren!

Na ja, ich finde ich durchaus sinnvoll mal drüber zu reden, ob man irgendwo undefined behaviour verbaut, speziell wenn es portabel sein soll und durch verschiedene Compiler gejagt wird. Da kommen am Ende sonst komische Dinge bei raus.

Zitat von »BlueCobold«

Na ja, ich finde ich durchaus sinnvoll mal drüber zu reden, ob man irgendwo undefined behaviour verbaut, speziell wenn es portabel sein soll und durch verschiedene Compiler gejagt wird. Da kommen am Ende sonst komische Dinge bei raus.

Ja, darauf hatten wir uns ja wohl schon geeinigt. Jetzt sind wir an der Stelle, ob wir es standardkonform probieren oder nicht, weil sonst evtl. vlt. ja die Performance leiden koennte.