SSE2/3 bringt keine Beschleunigung



  • abc.w schrieb:

    Bist Du sicher, dass es g++ ist, versuche nämlich zu kompilieren und bekomme Fehlermeldungen:

    nimm mal

    #include <pmmintrin.h>
    

    mit rein. Da sind die SSE3 intrinsics so mehr oder weniger compiler unabhängig definiert.

    das -march musst du evt. durch march=pentium4 ersetzten bei dir.
    Die neuen AMDs haben aber SSE3 und mit -msse3 kann man's auch erzwingen. Ich denke auch dass SSE3 Dinge ausgeführt werden denn als ich von SSE2 auf SSE3 gewechselt habe (was ich nur wegen _mm_hadd_pd tun musste) hat das ganze nicht mehr richtig funktioniert und erst durch die -march=k8 -msse3 Kombi bekam ich die richtigen Zahlen raus.

    Das ganze wird so einfach aber nicht kompilieren. Der gepostete Code war nur ein kleines Fragment aus einem recht grossen Projekt. Da fehlt dir zum kompilieren noch eine ganze Menge.

    LG
    Neph



  • Nephelauxetic schrieb:

    Ich hab Autovectorization ausgeschaltet (-fno_tree_vectorize) und hab den selben Speed. Daran kann es also nicht liegen. 😕

    Dann schau dir einfach mal den generierten Assemblercode an. 😕



  • Hallo

    Ich hab mir den generierten Assembler Code angeschaut und es sieht so aus als ob der Loop tatsaechlich bereits vom Compiler mit SSE vektorisiert wurde.
    Das naechste mal tu ich das bevor ich Arbeit ins manuelle Vektorisieren stecke. 🙄

    Die Compiler scheinen ja wirklich gute Arbeit zu leisten 👍

    LG
    Neph



  • was hat dein profiler denn fuer diesen wichtigen loop gesagt, wieviel % der laufzeit geht an dieser stelle drauf (also in beiden versionen). welche stellen im loop sind laut deinem profiler die kritischsten.



  • 🕶
    Dass "-fno_tree_vectorize" nix gebracht hat, liegt vermutlich daran, dass du den Loop bereits manuell expandiert hast. So musste der Compiler ja nichtmal mehr Vektorisieren, er hat nur die "schnellste" Uebersetzung gewaehlt... und wenn da 4 unabhaengige Floating Point Operations nacheinander kommen, bietet sich SSE nunmal an. 🙂



  • rapso schrieb:

    was hat dein profiler denn fuer diesen wichtigen loop gesagt, wieviel % der laufzeit geht an dieser stelle drauf (also in beiden versionen). welche stellen im loop sind laut deinem profiler die kritischsten.

    Welchen Profiler verwendest du, der dir so genaue Infos geben kann? 😮


  • Mod

    Beim Überfliegen fallen ein paar Stellen auf, die wahrscheinlich nicht zu optimalen Code führen. Um das endgültig beurteilen zu können, müssen aber der Assembleroutput bekannt sein. Meine Erfahrung mit diesen Compiler-Intrinsics für SSE&Co. ist eher gemischt - bei hinreichend komplexen Funktionen ist der Compiler schnell überfordert und führt unnötig viele reloads (das äußert sich primär in überflüssigen mov-Befehlen) durch, man kann dabei viel Zeit verlieren - eine handgeschriebene Assemblerroutine kann daher oft noch einmal Einiges herausholen.



  • Blue-Tiger schrieb:

    rapso schrieb:

    was hat dein profiler denn fuer diesen wichtigen loop gesagt, wieviel % der laufzeit geht an dieser stelle drauf (also in beiden versionen). welche stellen im loop sind laut deinem profiler die kritischsten.

    Welchen Profiler verwendest du, der dir so genaue Infos geben kann? 😮

    ich habe noch keinen verwendet der das nicht konnte, welchen verwendest du der das nicht kann?



  • rapso schrieb:

    Blue-Tiger schrieb:

    rapso schrieb:

    was hat dein profiler denn fuer diesen wichtigen loop gesagt, wieviel % der laufzeit geht an dieser stelle drauf (also in beiden versionen). welche stellen im loop sind laut deinem profiler die kritischsten.

    Welchen Profiler verwendest du, der dir so genaue Infos geben kann? 😮

    ich habe noch keinen verwendet der das nicht konnte, welchen verwendest du der das nicht kann?

    um nicht allzu offtopic zu werden: http://www.c-plusplus.net/forum/viewtopic-var-t-is-223162



  • abc.w schrieb:

    [...]
    Und hier meine g++ Version:

    g++ (GCC) 3.4.2 (mingw-special)
    Copyright (C) 2004 Free Software Foundation, Inc.

    Also: würde gerne und aus Neugier kompilieren, aber geht nicht... 😉

    Lol, eine 4 Jahre alte Kompilerversion verwenden und sich dann wundern, wenn was nicht geht 😃

    Übrigens gibt es den GCC inzwischen nicht nur mit der 4 statt der 3 vorne, sondern schon bald wieder mit der 4 an zweiter Stelle, also beeil dich bevor du überrundet wirst 😃 😃



  • rapso schrieb:

    was hat dein profiler denn fuer diesen wichtigen loop gesagt, wieviel % der laufzeit geht an dieser stelle drauf (also in beiden versionen). welche stellen im loop sind laut deinem profiler die kritischsten.

    Ich rufe die Routine (welche Paarweise Interaktionen von SPC Wassermolekülen berechnet) tausende male auf. 42% der Laufzeit fällt auf diesen Teil und dies ändert sich bei meinem SSE loop um ca. 1%.
    Ich habe manuelle Timer für diese Loops die eigentlich recht verlässliche Resultate liefern.
    Mit gprof kann ich die Zeiten nicht so genau aufteilen da viel optimiert und inlined wird. So ist die weitere Aufschlüsselung leider ziemlich nichtssagend.

    Im Loop habe ich gar keine Ahnung und verlasse mich auf mein C++ wissen 🤡 🙄

    camper schrieb:

    Beim Überfliegen fallen ein paar Stellen auf, die wahrscheinlich nicht zu optimalen Code führen. Um das endgültig beurteilen zu können, müssen aber der Assembleroutput bekannt sein. Meine Erfahrung mit diesen Compiler-Intrinsics für SSE&Co. ist eher gemischt - bei hinreichend komplexen Funktionen ist der Compiler schnell überfordert und führt unnötig viele reloads (das äußert sich primär in überflüssigen mov-Befehlen) durch, man kann dabei viel Zeit verlieren - eine handgeschriebene Assemblerroutine kann daher oft noch einmal Einiges herausholen.

    Ja das habe ich auch gesehen. Der Code ist voller mov-s von denen ich auch einige überflüssige gesehen habe. Ich traue es mir aber nicht wirklich zu den Assembler selbst zu schreiben. Die SSE intrinsics waren für mich ein akzeptabler Kompromiss. Bei inline ASM seh ich nicht ganz wie ich das jemals portabel hinkriegen sollte und ehrlich gesagt fehlt mir da schlicht das nötige knowhow.
    Um die mov-s zu verhindern habe ich versucht die Anzahl __m128d "variablen" so klein wie möglich zu halten... aber es braucht halt viele - ich rechne auch viel.

    LG
    Neph



  • Nephelauxetic schrieb:

    Im Loop habe ich gar keine Ahnung und verlasse mich auf mein C++ wissen 🤡 🙄

    naja, das wissen truegt oft. ein profiler wuerde dir die instructions zeigen die am meisten ziehen. wenn du mal die profiling resultate im thread von blue tiger anschaust, siehst du, dass ich so sehen konnte, dass es am speicher lag (in diesem fall), dank profiler. dann konnte ich das optimieren und dieser 'peak' konnte fast vollkommen wegoptimiert werden.

    mein wissen alleine haette mir das nicht sagen koennen 😉


Anmelden zum Antworten