Compile sage with `-march=native` as a default

[Jonathan Kliem]

I was wondering, if it was possible to compile sage (or parts of it) with `-march=native` or something similar (unless SAGE_FAT_BINARIES is set).

Some time ago I created #27122 for this.

Why do I care about it? (I was told that many parts of sage could profit from it, but I personally do not know other examples.)

Starting with the next develop, polyhedra will use a new algorithm to calculate the f_vector (see #28625).

In many instances we can speed up the actual face iterator by a factor of 2, when using intrinsics (subject of #27103).

Among others, this will do subset checks much faster, which is the bottle neck of it all.

Concretely, the class CombinatorialPolyhedron would profit from any of POPCNT, AVX, or SSE4.1.

[Michael Orlitzky]

On 10/22/19 7:00 AM, 'Jonathan Kliem' via sage-devel wrote:
> I was wondering, if it was possible to compile sage (or parts of it)
> with `-march=native` or something similar (unless SAGE_FAT_BINARIES is set).

> Some time ago I created #27122 <https://trac.sagemath.org/ticket/27122>
> for this.

Set CFLAGS="-march=native" in your shell before running "make", and then
pray that the sage packages respect that variable.

[Dima Pasechnik]

many packages would ignore it, and C++ and Fortran modules won't be
affected by this, either.

For sagelib, enabling -march=native is probably doable via its setup.py
(in SAGEROOT/src/setup.py)


>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/fdd81e90-573b-49f3-40ee-50f4ed2ca1fc%40orlitzky.com.

[Michael Orlitzky]

On 10/22/19 7:41 AM, Dima Pasechnik wrote:
>>
>> Set CFLAGS="-march=native" in your shell before running "make", and then
>> pray that the sage packages respect that variable.
>
> many packages would ignore it, and C++ and Fortran modules won't be
> affected by this, either.

Well there's also CXXFLAGS and FCFLAGS for those.

If packages don't respect them, then it's an upstream or sage bug, but
we're all probably better off concentrating on getting sage to use our
distro packages where we've already fixed those bugs.

[Jonathan Kliem]

Thanks for your replies.

I wasn't aware of `CFLAGS` and it works great.

I think it makes sense to enable the SIMD-instructions with #27103 no matter if all of sage is compiled with `-march=native` by default.

All it really takes to get the intrinsics working is to recompile the sources for CombinatorialPolyhedron.

I think one could mention this option in the docstring of those function, which profit from it and hope that users who really want the performance read the docstring.

Is it acceptable to change the setup file to compile with `-march=native` as a default

e.g. if GCC >= 5.1 or clang >= 6.0 (and of course SAGE_FAT_BINARIES is not set)?

(GCC 5.1 fixed a bug, so this is important,

clang 6.0 is a wild guess, I have no clue when clang added march=native and if they ever fixed an important bug).

I added a branch with my very naive approach of doing it in setup.py to #27122.