GCC-Optimierungen bei -ffast-math

[Lukas K. (carrotindustries)]

Hallo Zusammen,

beim optimieren einer Funktion zum Finden von Minimum und Maximum ist 
mir aufgefallen, dass -ffast-math die Geschwindigkeit des Codes um ca. 
Faktor 10 steigert. Der erzeugte Assembler-code wirft jedoch einige 
fragen auf:
http://goo .gl/EhxsaN (Leerzeichen entfernen, sonst spam) so auf den 
ersten Blick schaut das nach partiellem loop unrolling aus, scheint aber 
ein bisschen mehr dabei zu sein. Ohne -ffast-math ist Assembler-Code 
deutlich kürzer aber eben auch um Faktor 10 langsamer. Was für eine 
anscheinend doch sehr effiziente Optimierung hat hier zugeschlagen? Der 
mit -ffast-math erzeugte code schafft es dann auch die 
Speicherbandbreite der CPU vollständig auszulasten.

Lukas

[Rolf M. (rmagnus)]

Nutzt er denn bei der Variante ohne fast-math auch AVX, wie bei dieser?

[Lukas K. (carrotindustries)]

Rolf M. schrieb:
> Nutzt er denn bei der Variante ohne fast-math auch AVX, wie bei dieser?

Jep, kannste bei dem angegebenen Link einfach ausprobieren.

[Oliver S. (oliverso)]

Lukas K. schrieb:
> Jep, kannste bei dem angegebenen Link einfach ausprobieren.

Sicher nicht. Erste Internet-Grundregel: du sollst nicht auf dubiose 
Links klicken.

Oliver

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Lukas K. schrieb:
> Was für eine
> anscheinend doch sehr effiziente Optimierung hat hier zugeschlagen?

An GCC wird seit fast 30 Jahren gearbeitet. Man muss davon ausgehen, 
dass nicht mal die GCC-Maintainer über jedes Detail Bescheid wissen. Bei 
solchen Details ist die einzige Dokumentation häufig der Source-Code.

https://gcc.gnu.org/wiki/FloatingPointMath

enthält ein paar grundlegende Erklärungen, aber nicht die exakten 
Optimierungs-Algorithmen die verwendet werden. Wenn ich es richtig 
verstehe sind nicht nur der Compiler, sondern auch die Libraries an 
fast-math beteiligt. Was bedeutet, man müsste nicht nur im 
Compiler-Sourcecode, sondern noch in den Libraries nach den 
Optimierungen suchen.

Dann kommt hinzu, dass alle Optimierungen von der Target-Architektur 
abhängen. Wie du aus dem Link ersehen kannst, hängen die Optimierungen 
auch noch gegenseitig voneinander ab.

[(prx) A. K. (prx)]

Lukas K. schrieb:
> Was für eine
> anscheinend doch sehr effiziente Optimierung hat hier zugeschlagen?

Der Kern bei grossem <n> ist nicht in klassischem Sinn unrolled, sondern 
über AVX vektorisiert.

Langsame Version, 32 Bits am Stück:

.L6:
  vmovss  xmm0, DWORD PTR [rax]
  add     rax, 4
  vmaxss  xmm2, xmm0, xmm2
  vminss  xmm1, xmm0, xmm1
  cmp     rsi, rax
  jne     .L6

Schnelle Version: 256 Bits am Stück:

.L9:
  vmovaps  ymm2, YMMWORD PTR [r11]
  add      eax, 1
  add      r11, 32
  vmaxps   ymm1, ymm1, ymm2
  vminps   ymm0, ymm0, ymm2
  cmp      r9d, eax
  ja       .L9

[Lukas K. (carrotindustries)]

A. K. schrieb:
> Lukas K. schrieb:
>> Was für eine
>> anscheinend doch sehr effiziente Optimierung hat hier zugeschlagen?
>
> Der Kern bei grossem <n> ist nicht in klassischem Sinn unrolled, sondern
> über AVX vektorisiert.
> [...]

Danke, klingt einleuchtend. Allerdings bleibt die frage, weshalb GCC das 
erst mit -ffast-math macht, müssen dazu Umformungen gemacht werden, die 
zu Ungenauigkeiten führen können. Aber schon beeindruckend, was ein 
moderner Compiler da schafft. Hätte ich in ASM niemals hinbekommen.

Oliver S. schrieb:
> Lukas K. schrieb:
>> Jep, kannste bei dem angegebenen Link einfach ausprobieren.
>
> Sicher nicht. Erste Internet-Grundregel: du sollst nicht auf dubiose
> Links klicken.
>
> Oliver

Der Link zeigt auf http://gcc.godbolt.org/ In der URL selbst ist 
allerdings noch der gesamte Sourcecode enthalten:
http://gcc.godbolt.org/#{%22version%22%3A3%2C%22filterAsm%22%3A{%22labels%22%3Atrue%2C%22directives%22%3Atrue%2C%22commentOnly%22%3Atrue}%2C%22compilers%22%3A[{%22sourcez%22%3A%22G4ewlgJgBAtghgDwIICcVwJ4AoBmAbEOAFwCooEAaKAVwDsBnMAc1oFNoxaipar9DuJEPD4FiUITDABKKAG8AUFCgBIfuKlQAvOQDaABgC6AbiVR13eNr1HTy5ThAooWTtzDX9xqB4A8PbzAAaiDZRXsInxwXBF0wQwA%2BeFl4LVj4u0iomLjDXykUsDTczOUAXzNJOGt4TMkPHSlTMqAAA%3D%3D%22%2C%22compiler%22%3A%22g520%22%2C%22options%22%3A%22-O3%20-march%3Dbroadwell%20-ffast-math%22}]} 
(war doch kürzer als erwartet)

[(prx) A. K. (prx)]

Lukas K. schrieb:
> Aber schon beeindruckend, was ein
> moderner Compiler da schafft. Hätte ich in ASM niemals hinbekommen.

Wird einfacher wenn du davon ausgehen darfst, dass die Daten auf 32 
Bytes aligned sind und n durch 8 teilbar ist. Ein erheblicher Teil des 
Codes hat damit zu tun, dass dies hier nicht garantiert ist.

Mit AVX-512 ändert sich das dann freilich wieder. Sowas überlässt man 
auch deshalb lieber dem Compiler.

[(prx) A. K. (prx)]

Lukas K. schrieb:
> erst mit -ffast-math macht, müssen dazu Umformungen gemacht werden, die
> zu Ungenauigkeiten führen können.

Möglicherweise ist das Schema dieser Vektorisierung nicht speziell an 
die Eigenschaften von min/max angepasst, sondern wird auch auf andere 
Vektoroperationen analoger Bauweise angewandt, bei denen das exakte 
Ergebnis von der Reihenfolge der Rechnungen abhängt, wie etwa bei einer 
Summe.