Compile with -march=native

[kliem]

We should compile Sage with the extra compile argument -march=native for extra performance, at least if SAGE_FAT_BINARY is not set.

In gcc/spkg_configure.ac we check, whether the argument -march=native is accepted.

In build/make/Makefile.in we assemble the flags.

We add -march=native to the compiler flags, if not building fat binaries and the compiler and the package accepts it.

During the build of sage there are now the following flags that can be exported in spkg_install.in with one line, instead of checking SAGE_DEBUG etc. for each individual package, e.g. by

• export CFLAGS=$CFLAGS (redundant, use flags as above with -march=native if possible)
• export CFLAGS=$CFLAGS_NON_NATIVE (flags as above without -march=native)
• export CFLAGS=$CFLAGS_O3 (O3 instead of O2, but only if not in debug mode, add -march=native if possible)
• export CFLAGS=$CFLAGS_O3_NON_NATIVE (O3 instead of O2, no -march=native)
• export CFLAGS=$ORIGINAL_CFLAGS (use $CFLAGS as set before configure)

Likewise we do with CXXFLAGS, FCFLAGS, F77FLAGS.

We try to respect the users choice and do not overwrite the flags if already set by the user, but only add compile flags if absolutely necessary for packages to work.

Inidividual packages can still be compiled with specified flags or in debug mode using

make CFLAGS=-O2 some-package

or

make SAGE_DEBUG="yes" some-package

Depends on #30375

CC: @sophiasage @vbraun @embray @kiwifb

Component: build

Keywords: Intrinsics, SIMD

Author: Jonathan Kliem

Branch: 7bc1f28

Reviewer: Matthias Koeppe

Issue created by migration from https://trac.sagemath.org/ticket/27122

[jdemeyer]

comment:1

The topic has nothing to do with polyhedra, many parts of Sage could benefit from it.

[jdemeyer]

Changed keywords from Intrinsics, SIMD, Polyhedra, FindPoly to Intrinsics, SIMD

[jdemeyer]

Description changed:

--- 
+++ 
@@ -1,15 +1,5 @@
-In #26887 we are constructing a class that makes fast computations of combinatorial data of Polyhedra.
+We should compile (parts of) Sage with the extra compile argument `-march=native` for extra performance, at least if `SAGE_FAT_BINARY` is not set.
 
-Can we add the extra compile argument `-march=native` in `build/cythonized/setup.py`?
+The main problem is how to determine whether the toolchain will accept it. Not all compilers accept that option and some compilers use old assemblers that do not understand all those new instructions.
 
-```
-if os.environ.get("SAGE_FAT_BINARY") != "yes":
-    extra_compile_args.append('-march=native')
-```
-
-This would speed up those calculations depending on the architecture:
-
-- `f_vector` of `polytopes.permutahedron(8)` takes 1.6 seconds with intrinsics and 4.8 seconds without.
-- `f_vector` of a 20-dimensional counterexample of the Hirsch-conjecture takes about 3 minutes with intrinsics and 9 minutes without (the polytope contains 353,731,266 faces).
-
-As we are setting up a database `FindPoly`, which shall contain a lot of polytopes, we would like calculations to be done as fast as somehow possible. The project does not depend on this happening, but still it would be nice.
+There is also the question at what level to do this. I'm inclined to do it for Python, such that it affects all Python packages (including the Sage library).

[jdemeyer]

Description changed:

--- 
+++ 
@@ -2,4 +2,4 @@
 
 The main problem is how to determine whether the toolchain will accept it. Not all compilers accept that option and some compilers use old assemblers that do not understand all those new instructions.
 
-There is also the question at what level to do this. I'm inclined to do it for Python, such that it affects all Python packages (including the Sage library).
+There is also the question of where to do this. I'm inclined to do it for Python, such that it affects all Python packages (including the Sage library).

[embray]

comment:3

Ticket retargeted after milestone closed (if you don't believe this ticket is appropriate for the Sage 8.8 release please retarget manually)

[embray]

comment:4

As the Sage-8.8 release milestone is pending, we should delete the sage-8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage-8.9).