[C++] Schnellster Test POINT ggn RECT

[Jörg]

Bezueglich inlining und Parameteruebergabe...das ist wirklich noch immer ein Compilerproblem. War es schon auf der 360 , da haben sie es fuer einige Datentypen im Griff, wie auch fuer den PC. Schau mal in den header der xnamath-Bibliothek...was da an Macros verwurstet wird, um die passende Calling-Convention zu bauen....brrrr. Ich denke, andere Compiler (icc, pgicc) haben das weitaus besser im Griff, mir fehlt im Moment aber die Moeglichkeit zum testen.

[Krishty]

Ich muss aber der Fairness halber sagen, dass das anscheinend nur unter 32-Bit-Builds der Fall ist – ich habe eben unter x86-64 getestet und da macht die Parameterübergabe keinen Unterschied mehr; auch ist deine Version dann genauso schnell wie die Lesbare.

Was die Entscheidung pass-by-reference und pass-by-value angeht, ist das wirklich eine unschöne Problematik, wenn man sich nicht auf den Optimizer verlassen kann … statt Makros à la xnamath habe ich auch mal probiert, mit Templates zu arbeiten, aber das bläht den Quellcode ungemein … nicht gut, das :/

Edit: Da wir das Ursprungsproblem abgehakt haben, markiere ich den Thread als gelöst.

[Jörg]

Nachdem ich noch 2 SSE2-Varianten erstellt habe, hier mal die Ergebnisse eines anderen (vernuenftigeren? ;) ) Compilers. Alle Werte als Zeiten, um eine bestimmte Menge an Punkt-Rechteck-Tests durchzufuehren, nicht der absolute Wert sondern die Relationen zueinander sind ausschlaggebend. Das Verhaeltnis von positiven zu negativen Testresultaten ist 869791:19130209, so dass der Standardfall mit Spruengen davon sogar profitieren sollte.

Core2 Duo
gcc -O3 -mtune=native -march=native -msse2 -m64

Time1: 23705 (0) (Boolean C)
Time2: 18357 (0) (Bitwise C)
Time3: 12819 (0) (Arithmetik)
Time4: 12668 (0) (SSE2 64bit rshift)
Time5: 13151 (0) (SSE2 shuffle)

Nun das gleiche mit -m32, gleiche Maschine:
Time1: 24379 (0) (Boolean C)
Time2: 21817 (0) (Bitwise C)
Time3: 13800 (0) (Arithmetik)
Time4: 12375 (0) (SSE2 64bit rshift)
Time5: 12824 (0) (SSE2 shuffle)

Schwankungen: 3. Stelle -+1

Bei Gelegenheit nehme ich noch den aktuellen 4.4.2 zum Vergleich, der sollte die Schwaeche bei Variante2 hoffentlich ausmerzen...

Fazit: Leider ist alles merklich besser als die Standard-Variante (Time1) :(
VS2010 optimiert die bitweise Verknuepfung sehr gut, 13 Instruktionen (spart 2 gegenueber meiner Tabelle, da nicht die Rechteckbegrenzungen sondern die Punktkoordinaten in die Register geladen werden), bei der arithmetischen Variante hat er leichte Probleme (ein unbenoetigtes reg-reg move wird eingefuegt, 14 Instruktionen), aber das Ergebnis ist nicht wesentlich langsamer. SSE2 via Intrinsics erzeugt den laengsten Code (byte count fast doppelt so gross), benoetigt ebenfalls 13 Instruktionen (mag sein, dass jemand hier noch was sparen kann) und ist nicht wirklich schneller. Und wenn man einen anderen Compiler nimmt, sehen die Ergebnisse merklich anders aus. Vielleicht laesst es mal jemand auf nem PPC laufen (PS3)? AMD CPU waere auch nicht schlecht mal im Vergleich zu haben.
Den Code schicke ich bei Bedarf mal rum (Linux & Windows).
Edit:
gcc 4.4.2 auf Core2Duo wie oben:
Time1: 21890 (0) Standard C
Time2: 18631 (0) Bitwise C
Time3: 11256 (0) Arithmetik C
Time4: 10839 (0) SSE2 SHR64
Time5: 11731 (0) SSE2 shuffle

gcc 4.2.1 auf AMD Opteron 2.6GHz

Time1: 22776 (0) Standard C
Time2: 19315 (0) Bitwise C
Time3: 19648 (0) Arithmetik C
Time4: 20311 (0) SSE2 SHR64
Time5: 20826 (0) SSE2 shuffle


icc 9.1 auf AMD Opteron 2.6GHz
Time1: 23365 (0) Standard C
Time2: 19626 (0) Bitwise C
Time3: 19724 (0) Arithmetik C
Time4: 20304 (0) SSE2 SHR64
Time5: 20331 (0) SSE2 shuffle


Nun kann jeder selbst abschaetzen, wie weit man C-Code 'optimieren' moechte....Consoleros haben es da natuerlich einfacher, die HW ist ziemlich fix.

[Bergmon]

welche varianten sind jetzt welche programmcode umsetzungen?

kann nicht alles zuordnen, deswegen rate ich mal:

Boolean C == Vergleich des Punktes mit Rect durch &&
Bitwise C == Vergleich des Punktes mit Rect durch &
Arithmetic C == Funktion von Jörg?

der rest bezieht sich auf optimierungen der Arithmetic C - Funktion mittels SSE2?

gruß bergmon

[Jörg]

Ja, genau so war es gemeint. Entschuldigung, der Post ist wirklich alleinstehend nicht sehr aussagekraeftig. Er soll nur zeigen, dass man sich auf nichts verlassen kann ;) Weder auf den Compiler, dass der alles gut hinbekommt, noch darauf, dass was selbstgestricktes immer viel besser funktioniert...
Jedenfalls lohnt es sich erst ueber soetwas nachzudenken, wenn man solch eine Stelle wirklich als Problem und kritisch identifiziert hat...alles andere kann was bringen, muss es aber nicht.

[Krishty]

hier mal die Ergebnisse eines anderen (vernuenftigeren? ;) ) Compilers.

A propos vernünftigerer Compiler – kannst du die Ergebnisse von VCpp auch noch posten? Ist VC immernoch überall 5 bis 10% schneller als GCC?

[Jörg]

Ich könnte, aber da ich den Code nicht auf der gleichen Maschine habe laufen lassen, ist ein Vergleich g++ vs. VC nicht ratsam, sorry.

[Krishty]

Achso, das wusste ich nicht. Dann habe ich nichts gesagt :)

[Jörg]

PS3 & 32bit, gcc 4.4.1 -mcpu=cell -mtune=cell -O3:

Time1: 75941 (0) Standard C
Time2: 101532 (0) Bitwise C
Time3: 49607 (0) Arithmetik C

PS3 & 32bit, gcc 4.4.1 -O3:
Time1: 79376 (0) Standard C
Time2: 87733 (0) Bitwise C
Time3: 51963 (0) Arithmetik C

PPU only. Ohne VMX. XBox 360 duerfte aehnlich aussehen.
Leider verliert Loesung 2 extrem an Boden, wenn man speziell fuer Cell optimiert (optimieren lassen will waere wohl besser formuliert).