Compiler build-in float Optimierung

Siassei

Hallo,

ich schreibe derzeit an einem kleine RayTracing-Programm (Hobby Projekt). Der GCC und auch einige andere Compiler unterstützen eine Aktivierung von SSE und AVX. Jetzt frage ich mich, wie gut float bzw. double Operationen der verschiedenen Klassen "optimiert" werden. Besonders in Bezug auf Vektorisierung.

Aus diesem Grund überlege ich jetzt gerade, ob ich mich in SSE und AVX einarbeiten sollte.

Kann mir hier jemand ein paar gute Dokumente zu diesem Thema geben?
Oder sind die Optimierungen des Compilers bereits sehr gut, so dass nur ein "Profi" akzeptable Verbesserungen machen kann.

Gruß, Thomas

Shade Of Mine

Prinzipiell optimiert der Compiler gut und kann auch SSE und vectorization.

Deshalb macht es Sinn die erste Version ohne low-level Optimierungen zu implementieren und dann zu Profilen. Die meisten Stellen wird der Compiler vermutlich ziemlich ideal lösen und der Profiler hilft dir dann die Stellen zu finden wo der Compiler mist baut.

rapso

Siassei schrieb:

ich schreibe derzeit an einem kleine RayTracing-Programm (Hobby Projekt). Der GCC und auch einige andere Compiler unterstützen eine Aktivierung von SSE und AVX. Jetzt frage ich mich, wie gut float bzw. double Operationen der verschiedenen Klassen "optimiert" werden. Besonders in Bezug auf Vektorisierung.

der intel compiler kann das wohl am besten, wenn du also probieren willst, benutz deren ICC (kostenlos fuer linux,kostenfreie evaluierungsversion fuer windows).
aber wunder kann man da nicht erwarten, meistens sind es simple schleifen die vektorisiert werden, der compiler wird dir eher nicht sowas wie dot products etc. einbauen, da sowas high-level wissen benoetigt, z.b. ob variablen aligned sind.

Kann mir hier jemand ein paar gute Dokumente zu diesem Thema geben?

da du scheinbar anfaenger bist, wird jedes SSE tutorial fuer den anfang recht sein, es gibt welche z.b. bei msdn, auch bei intel und ich glaube selbst wikipedia hat ein paar beispiele.

Oder sind die Optimierungen des Compilers bereits sehr gut, so dass nur ein "Profi" akzeptable Verbesserungen machen kann.

wie beim ganzen raytracer themengebiet, wirst du ohne viel fleiss nicht ueber das einfach anfangsstadium hinauskommen. (sprich: deine ersten raytracing versuche sehen vermutlich nicht sonderlich beeindruckend aus und dein erster SSE/AVX code wird vermutlich +-30% gegenueber dem compiler leisten).

daybyter

Schau mal hier:

http://inferno.hildebrand.cz/log.html

Raytracer auf der Grafikkarte. Da hast Du eh gleich die Typen wie Vektoren und Matrizen drin und kannst damit Hardware-Unterstützt rechnen.

otze

rapso schrieb:

aber wunder kann man da nicht erwarten, meistens sind es simple schleifen die vektorisiert werden, der compiler wird dir eher nicht sowas wie dot products etc. einbauen, da sowas high-level wissen benoetigt, z.b. ob variablen aligned sind.

Der GCC kann inzwischen echt viel. Wenn er das alignment nicht weiß, muss er allerdings _mm_loadu_pd verwenden, und das frisst unter Umständen wieder eine Menge des Gewinns auf. Aber optimieren tun die Compiler schon richtig gut mit SSE(wie in meinem anderen Thread erwähnt, habe ich es mit recht wenig Aufwand ohne explizite Verwendung von SSE geschafft, mit dem GCC besseren code zu produzieren, als das ATLAS matrix-vektor produkt). Natürlich können Compiler keine Wunder vollbringen. Wenn du deinen Code nicht so aufbaust, dass du linear durch den Speicher rennst, wird dir der GCC da auch kein SSE hinbasteln können.

rapso

otze schrieb:

rapso schrieb:

aber wunder kann man da nicht erwarten, meistens sind es simple schleifen die vektorisiert werden, der compiler wird dir eher nicht sowas wie dot products etc. einbauen, da sowas high-level wissen benoetigt, z.b. ob variablen aligned sind.

Der GCC kann inzwischen echt viel.

im vergleich zu ICC ist es dennoch bescheiden, sowas wie auto parallelization etc. ist seit kurzem in einer sehr limitierten version drinnen, waehrend intel schon beim ersten Pentium 4 HT im ICC dummy-threads compiliert hatte die nur vorauslaufen um den cache zu fuellen usw.
benchmarks sind natuerlich mit vorsicht zu geniessen, aber ich glaube das sieht objektiv aus (wenn auch auto-vectorize und parallization nicht an sind) http://www.global.phoronix-test-suite.com/index.php?k=profile&u=staalmannen-29262-30794-24108

Wenn er das alignment nicht weiß, muss er allerdings _mm_loadu_pd verwenden, und das frisst unter Umständen wieder eine Menge des Gewinns auf. ...Natürlich können Compiler keine Wunder vollbringen. Wenn du deinen Code nicht so aufbaust, dass du linear durch den Speicher rennst, wird dir der GCC da auch kein SSE hinbasteln können.

ich glaube das sagte ich

Aber optimieren tun die Compiler schon richtig gut mit SSE(wie in meinem anderen Thread erwähnt, habe ich es mit recht wenig Aufwand ohne explizite Verwendung von SSE geschafft, mit dem GCC besseren code zu produzieren, als das ATLAS matrix-vektor produkt).

das hoere ich nur zu oft wenn man mich zum optimieren anheuert ;), wenn ich dann ueberschlage wieviel GB/s und GFlops/s da rauskommen, ist es meistens 10%-20% von dem was die CPU/GPU zu leisten vermag. (das ist nichts gegen dich, ich mein nur, jeder glaubt sein bestes getan zu haben und, hoffentlich, ist jeder andere gute programmierer herausgefordert das auf die probe zu stellen und am ende gibt es dennoch mehr performance). ich schreibe hier lieber keine anektoten sonst quiekt wieder ein gewisser annonymer

Compiler leisten einen guten job auf unterer ebene, aber sie koennen nicht verstehen was du machen willst, deswegen muessen sie fressen wie du sie fuetterst, da koennen leichte aenderungen, die das selbe resultat erbringen, dem compiler einen stock zwischen die beine hauen oder aber auch die freiheit zum optimieren geben. aber dessen ist man sich meist nicht bewust.

als beispiel kann man sich http://www.nvidia.com/content/GTC-2010/pdfs/2260_GTC2010.pdf anschauen (ja, ist fuer gpu, aber gute cpu-SIMD paper findet man seltener), ab p23, im gegensatz zu c++, sieht der compiler hier die complete translation unit, er muss also keine seiteneffekte befuerchten wie pointer aliasing, er muss sich nicht um alignment kuemmern und microsoft/nvidia haben leute die nichts anderes den ganzen tag ueber machen als optimierungen in den compiler einzubauen (zudem kann die compilierung richtig komplexer programme mehrer minuten dauern, was man sich bei der menge an c++ code den man normalerweise hat, nicht leisten kann).
und dennoch ist die erste version groessenordnungen schlechter als es sein koennte, entsprechend sieht das mit c++ compilierten programmen aus.

[edit:kannst du mir den link zu deinem atlas thread geben? hab gerade mittagspause und wuerde gerne die resultate sehen/analysieren /]