20x Slowdown in hypergeom.cdf

[mborland]

See: scipy/scipy#16079

Minimal example with benchmarks

It's interesting that the slowdown is reproduced by C++11 vs C++14. I am hoping this will not evolve into a larger issue as we move to C++14 as the minimum standard.

[mborland]

Here are the values using current develop with different compilers:

Apple Clang 14 w/libc++ using C++11 on M1

./hypergeom1  0.59s user 0.00s system 67% cpu 0.880 total

Apple Clang 14 w/libc++ using C++14 on M1

./hypergeom2  11.84s user 0.02s system 97% cpu 12.108 total

GCC 12 w/libstdc++ using C++11 on M1

./hypergeom3  0.70s user 0.01s system 72% cpu 0.983 total

GCC 12 w/libstdc++ using C++14 on M1

./hypergeom4  12.36s user 0.03s system 97% cpu 12.745 total

GCC 12 w/libstdc++ using C++17 on M1

./hypergeom5  12.44s user 0.03s system 98% cpu 12.660 total

GCC 12 w/libstdc++ using C++20 on M1

./hypergeom6  12.72s user 0.03s system 97% cpu 13.123 total

[mborland]

And here are values on x86-64 (i7-1255U) using Ubuntu 20.04.5:

GCC 10 w/libstdc++ using C++11

real	0m0.619s
user	0m0.618s
sys	0m0.000s

GCC 10 w/libstdc++ using C++14

real	0m6.886s
user	0m6.881s
sys	0m0.004s

GCC 10 w/libstdc++ using C++17

real	0m5.766s
user	0m5.766s
sys	0m0.000s

The x86-64 slowdown is 10x instead of 20x on M1.

Edit: Using Boost 1.77 and 1.75 yield the same results.

[ckormanyos]

Hmmm...

Couple ideas.

• Try to rule out optimization level? Try -Os and maybe try -O2 (which is not so radical)?
• I've seen slowdowns with constexpr previously, but a factor of 20 seems huge.
• the clang++ compiler allows you to actually specify stuff like -fconstexpr-steps=8 or also -fconstexpr-depth=8, which I expect wil lead to compilation errors, but may give you insight into what is or is not all getting a constexpr hit?

[ckormanyos]

Vague recolection about something chrono-esque going on in there.

[jzmaddock]

This is weird (and rather worrying), just stepping through the code I see nothing that would obviously change with std version - there's no constexpr stuff in there either @ckormanyos. It is very computationally intensive though, lot's of table lookup of the prime numbers too. Ah... I wonder if this could be a thread safety thing doing table lookup? Some hidden locking going on maybe?

[jzmaddock]

Cygwin x86:

C++11:

real 0m0.734s
user 0m0.640s
sys 0m0.000s

c++14:

real 0m18.668s
user 0m17.734s
sys 0m0.016s

Wow!

[jzmaddock]

Reproduced with PDF as well as CDF (the former being called by the latter internally).

[jzmaddock]

It looks like it might be related to prime number lookup - which uses std::array internally - were there any changes between c++11 and 14? Also noted that boost::math::prime is NOT expanded inline in C++14 at least even though it's a fairly trivial function.

[ckormanyos]

uses std::array internally - were there any changes between c++11 and 14

There was something seemingly trivial involving the member at() (which may throw). It became constexpr, but that seems irrelevant?

[mborland]

It looks like it might be related to prime number lookup - which uses std::array internally - were there any changes between c++11 and 14? Also noted that boost::math::prime is NOT expanded inline in C++14 at least even though it's a fairly trivial function.

The only thing that would have changed for std::array between C++11 and C++14 would be aggregate initialization rules. I doubt that would be in-play here.

[mborland]

If you remove all of the contextual constexpr-ness from prime and make it all follow the C++11 static const and inline you get:

C++11

./hypergeom1  0.69s user 0.01s system 74% cpu 0.947 total

C++14

./hypergeom1  0.65s user 0.01s system 81% cpu 0.810 total

C++17

./hypergeom1  0.65s user 0.01s system 67% cpu 0.991 total

[jzmaddock]

Yup, just found that too: it's the constexpr std::array's that are totally killing things.

[jzmaddock]

No change by making them C style arrays.