Investigate link time optimizations (-flto) and inlining

[valassi]

This is a spinoff of the Power9 issue #223.

I realised that adding -flto there (gcc link time optimizations) gains almost a factor 4 for scalar C++ code (and more than a factor 2 for simd code). I am using gcc8 there. Compare:

• no lto: ad4f39f
• lto: 86b7c15

Amongst the things to be understood:

• what does lto really involve in our case
• does it also provide a benefit for x86 (or is it only on power9)
• disadvantages? keep in mind the LHC experiments have their own linking ways, eg fpic etc
• try out a newer gcc compiler (eg is the lto-dump tool only available with gcc10?)
• how to interpret objdump when -flto is switcehed on

[valassi]

In PR #230 I checked -flto also on Intel processors: again I get large throughput increases

Compare

• no lto 370ce41
• lto 9293ea8

Double:

No LTO
FP precision                = DOUBLE (NaN/abnormal=0, zero=0)
Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
  EvtsPerSec[MECalcOnly] (3a) = ( 1.315891e+06                 )  sec^-1
Internal loops fptype_sv    = VECTOR[4] ('512y': AVX512, 256bit) [cxtype_ref=YES]
  EvtsPerSec[MECalcOnly] (3a) = ( 4.960773e+06                 )  sec^-1

LTO
FP precision                = DOUBLE (NaN/abnormal=0, zero=0)
Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
  EvtsPerSec[MECalcOnly] (3a) = ( 4.377819e+06                 )  sec^-1
Internal loops fptype_sv    = VECTOR[4] ('512y': AVX512, 256bit) [cxtype_ref=YES]
  EvtsPerSec[MECalcOnly] (3a) = ( 1.070241e+07                 )  sec^-1

Float:

No LTO 
FP precision                = FLOAT (NaN/abnormal=6, zero=0)
Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
  EvtsPerSec[MECalcOnly] (3a) = ( 1.207104e+06                 )  sec^-1
Internal loops fptype_sv    = VECTOR[8] ('512y': AVX512, 256bit) [cxtype_ref=YES]
  EvtsPerSec[MECalcOnly] (3a) = ( 8.852403e+06                 )  sec^-1

LTO
FP precision                = FLOAT (NaN/abnormal=6, zero=0)
Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
  EvtsPerSec[MECalcOnly] (3a) = ( 4.575539e+06                 )  sec^-1
Internal loops fptype_sv    = VECTOR[8] ('512y': AVX512, 256bit) [cxtype_ref=YES]
  EvtsPerSec[MECalcOnly] (3a) = ( 2.353434e+07                 )  sec^-1

In summary:

• -flto gives a factor ~3-4 speedup for scalar code
• -flto gives a factor ~2-2.5 spedup for AVX512y
• Note that this decreases the speedup of AVX512y over scalar code (not surprisingly? the overhead of scalar code is more important?)

Note also that again my objdump disassembly fails to give useful results when -flto is used

[valassi]

I tried to build in -flto also with clang12, but it requires the Gold linker, not yet installed.
I opened https://sft.its.cern.ch/jira/browse/SPI-1933

[valassi]

Using gcc10, I get similar speedups as in gcc9.
In the gcc10, the lto-dump tool is present: try to have look...

[valassi]

I changed the title and added inlining. I created a WIP PR #231

It turns out that large speedups, similar to those of LTO, are possibly by inlining. This makes sense: for such a small code as ours, -flto was giving all its benefits just on check.cc and CPPProcess.cc, so it is enough to study those two. Actually, looks like all happens inside CPPPProcess.cc? This is very similar to RDC optimizations in CUDA (issue #51).

Not all benefits of LTO are yet recovered.

And for instance SSE is slower than scalar after inlining?... Looks very strange. Does inlining actually use some vectorization without asking?...

[valassi]

One first hint, inline does not completely inline.

[avalassi@itscrd70 gcc9.2/cvmfs] ~/GPU2020/madgraph4gpuBis/epoch1/cuda/ee_mumu/SubProcesses/P1_Sigma_sm_epem_mupmum> ls -l _*/build.*/check.exe.objdump
-rw-r--r--. 1 avalassi zg 2122023 Jul  9 16:24 _INLINE/build.512y_d/check.exe.objdump
-rw-r--r--. 1 avalassi zg 2044850 Jul  9 16:24 _INLINE/build.none_d/check.exe.objdump
-rw-r--r--. 1 avalassi zg 2076861 Jul  9 16:27 ____LTO/build.512y_d/check.exe.objdump
-rw-r--r--. 1 avalassi zg 2044750 Jul  9 16:27 ____LTO/build.none_d/check.exe.objdump
-rw-r--r--. 1 avalassi zg 2241115 Jul  9 16:25 _NO_LTO/build.512y_d/check.exe.objdump
-rw-r--r--. 1 avalassi zg 2214849 Jul  9 16:25 _NO_LTO/build.none_d/check.exe.objdump
[avalassi@itscrd70 gcc9.2/cvmfs] ~/GPU2020/madgraph4gpuBis/epoch1/cuda/ee_mumu/SubProcesses/P1_Sigma_sm_epem_mupmum> egrep '^+[[:xdigit:]]+ <M.*FFV1P0' _*/build.*/check.exe.objdump
_INLINE/build.512y_d/check.exe.objdump:0000000000413d30 <MG5_sm::FFV1P0_3(mgOnGpu::cxtype_v const*, mgOnGpu::cxtype_v const*, std::complex<double>, double, double, mgOnGpu::cxtype_v*)>:
_NO_LTO/build.512y_d/check.exe.objdump:0000000000415200 <MG5_sm::FFV1P0_3(mgOnGpu::cxtype_v const*, mgOnGpu::cxtype_v const*, std::complex<double>, double, double, mgOnGpu::cxtype_v*)>:
_NO_LTO/build.none_d/check.exe.objdump:0000000000414060 <MG5_sm::FFV1P0_3(std::complex<double> const*, std::complex<double> const*, std::complex<double>, double, double, std::complex<double>*)>:

Try with 'always inline'?
https://stackoverflow.com/a/22767621
https://gcc.gnu.org/onlinedocs/gcc/Inline.html

[valassi]

And I now confirm that adding always_inline recovers all advantages of LTO (within 3-5%), see PR #233

I still keep this disabled for the moment.

There are advantages from inlining also in clang (a bit less than gcc, but still a factor 2 or much more)

The benefits of SIMD over scalar code are now obvious also after inlining (even if the speedup due to SIMD is lower after inlining than it was before inlining - some Amdahl at play here?)

[valassi]

Compare

• inlining (emulate LTO) 7a9000a
• baseline (no inlining, no LTO) f49006c

Double:

Baseline (no inlinining, no LTO)
  Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
    EvtsPerSec[MECalcOnly] (3a) = ( 1.315659e+06                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[2] ('sse4': SSE4.2, 128bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 2.542390e+06                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[4] ('512y': AVX512, 256bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 4.926921e+06                 )  sec^-1

Inlining (no LTO)
  Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
    EvtsPerSec[MECalcOnly] (3a) = ( 4.583564e+06                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[2] ('sse4': SSE4.2, 128bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 6.069095e+06                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[4] ('512y': AVX512, 256bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 1.110668e+07                 )  sec^-1

Float

Baseline (no inlinining, no LTO)
  Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
    EvtsPerSec[MECalcOnly] (3a) = ( 1.209677e+06                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[4] ('sse4': SSE4.2, 128bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 4.534024e+06                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[8] ('512y': AVX512, 256bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 8.871476e+06                 )  sec^-1

Inlining (no LTO)
  Internal loops fptype_sv    = SCALAR ('none': ~vector[1], no SIMD)
    EvtsPerSec[MECalcOnly] (3a) = ( 4.897949e+06                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[4] ('sse4': SSE4.2, 128bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 1.233099e+07                 )  sec^-1
  Internal loops fptype_sv    = VECTOR[8] ('512y': AVX512, 256bit) [cxtype_ref=YES]
    EvtsPerSec[MECalcOnly] (3a) = ( 2.381717e+07                 )  sec^-1

[valassi]

I think we should switch, eventually, in production.
This gives a factor ~2.5 speedup for the best SIMD on gcc.

However

• better wait to check also ggttgg
• better wait to check what happens when we integrate with Fortran MadEvent
• in any case, better keep this configurable

This completes the investigation for the moment... all of the advantages I had seen in LTO were essentially recovered in a different way.

(Ah ok, should test clang Gold anyway, just to see if it makes a difference)

[valassi]

PS By the way, note also that the objdump categorizations also make perfect sense now. As without LTO/inlining, after adding inlining the AVX512y is better than AVX2 because of a few symbols from AVX512VL