Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile with -march=native #27122

Closed
kliem opened this issue Jan 25, 2019 · 193 comments
Closed

Compile with -march=native #27122

kliem opened this issue Jan 25, 2019 · 193 comments

Comments

@kliem
Copy link
Contributor

kliem commented Jan 25, 2019

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

@kliem kliem added this to the sage-8.7 milestone Jan 25, 2019
@jdemeyer
Copy link

comment:1

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

@jdemeyer
Copy link

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

@jdemeyer

This comment has been minimized.

@jdemeyer jdemeyer changed the title Adding -march=native to build/cythonized/setup.py Compile with -march=native Jan 25, 2019
@jdemeyer

This comment has been minimized.

@embray
Copy link
Contributor

embray commented Mar 25, 2019

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 embray modified the milestones: sage-8.7, sage-8.8 Mar 25, 2019
@embray
Copy link
Contributor

embray commented Jun 14, 2019

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).

@embray embray removed this from the sage-8.8 milestone Jun 14, 2019
@kliem
Copy link
Contributor Author

kliem commented Oct 23, 2019

Branch: public/27122

@kliem
Copy link
Contributor Author

kliem commented Oct 23, 2019

New commits:

cdc8656compiling with `-march=native` for GCC from 5.1 and clang from 6.0 if SAGE_FAT_BINARY is not set

@kliem
Copy link
Contributor Author

kliem commented Oct 23, 2019

Commit: cdc8656

@kliem
Copy link
Contributor Author

kliem commented Oct 23, 2019

comment:7

I added a very naive approach of doing it. Wondering if this is remotely ok or going in the right direction.

@dimpase
Copy link
Member

dimpase commented Oct 23, 2019

comment:8

looks OK - not sure whether converting version to float() is normal practice, but that's minor.

I'm also not sure whether this will pass the argument to Cython, or it needs

# distutils: extra_compile_args = -march=native

in *.pxd files.

@kliem
Copy link
Contributor Author

kliem commented Oct 23, 2019

comment:9

I believe it works, but I'm not entirely sure.

This seems to state that sage/stats/distributions/discrete_gaussian_integer.pyx was compiled with -march=native.

I have not set it with CFLAGS, in that case it would have appeared twice on the list.

[sagelib-9.0.beta2] [469/499] gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -fPIC -I./sage/cpython -I/srv/public/kliem/sage/local/lib/python2.7/site-packages/cypari2 -I./sage/libs/ntl -I/srv/public/kliem/sage/local/lib/python2.7/site-packages/
cysignals -I/srv/public/kliem/sage/local/include -I/srv/public/kliem/sage/src -I/srv/public/kliem/sage/src/sage/ext -I/srv/public/kliem/sage/local/include/python2.7 -I/srv/public/kliem/sage/local/lib/python2.7/site-packages/numpy/core/include -Ibuild/cythonized -I/srv/pu
blic/kliem/sage/local/include/python2.7 -c build/cythonized/sage/stats/distributions/discrete_gaussian_integer.c -o build/temp.linux-x86_64-2.7/build/cythonized/sage/stats/distributions/discrete_gaussian_integer.o -fno-strict-aliasing -DCYTHON_CLINE_IN_TRACEBACK=1 -march
=native -D_XOPEN_SOURCE=600 -std=c99                                                                                                                                                                                                                                           
[sagelib-9.0.beta2] build/cythonized/sage/stats/hmm/hmm.c: In function ‘__pyx_pw_4sage_5stats_3hmm_3hmm_25DiscreteHiddenMarkovModel_17_forward’:          

@kliem

This comment has been minimized.

@kliem
Copy link
Contributor Author

kliem commented Oct 25, 2019

comment:10

It works for me. All tests passed. No significant time difference.

  • Operating System: Debian GNU/Linux 10 (buster)
  • Kernel: Linux 4.19.0-6-amd64
  • Architecture: x86-64
  • CPU Model name: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz

@kliem

This comment has been minimized.

@kliem
Copy link
Contributor Author

kliem commented Oct 26, 2019

comment:13

Works on

  • Operating System: Ubuntu 18.04.3 LTS
  • Kernel: Linux 4.15.0-65-generic
  • Architecture: x86-64
  • Model name: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz

@EmmanuelCharpentier
Copy link
Mannequin

EmmanuelCharpentier mannequin commented Oct 26, 2019

comment:14

Success on my notebook running a Python 3-based 9.0.beta2 on top of Debian testing :

  • Operating System: Debian GNU/Linux bullseye/sid
  • Kernel: Linux 5.2.0-3-amd64
  • Architecture: x86-64
  • Nom de modèle : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz

HTH,

@dimpase
Copy link
Member

dimpase commented Oct 27, 2019

comment:15

works on Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz (in 32-bit mode), Ubunty 14.04 LTS

@orlitzky
Copy link
Contributor

comment:16

I don't think we should be reinventing the thirty-year-old standard CFLAGS here. It looks like setup.py will already use CFLAGS if it's set. I'm not arguing against sane defaults, just saying that appending -march=native on top of my CFLAGS is a bit rude if I've set them to what I want.

Instead, why don't we try to set a decent default for CFLAGS if the user does not already have it set? Typically this amounts to something like

CFLAGS ?= -march=native -O2

in a makefile somewhere. For people who don't care, CFLAGS will get set to something nice, and setup.py will use that value. For the people who have set CFLAGS to something special, nothing goes wrong.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 15, 2020

Changed commit from a1ffd9b to ea601ea

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 21, 2020

Changed work issues from Merge latest branch of dependencies to none

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 21, 2020

Changed reviewer from Matthias Koeppe to Matthias Koeppe, https://github.com/mkoeppe/sage/actions/runs/434965861

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 21, 2020

comment:135

Instead of SAGE_MARCH, perhaps something like CFLAGS_MARCH...?!
And I would suggest to not use the prefix CONFIGURED_ here -- because I think this is not a case as for CFLAGS where we want to respect user variable settings?

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 21, 2020

Changed commit from ea601ea to 73ecf70

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 21, 2020

Branch pushed to git repo; I updated commit sha1. New commits:

73ecf70better naming scheme

@kliem
Copy link
Contributor Author

kliem commented Dec 21, 2020

comment:137

Replying to @mkoeppe:

Instead of SAGE_MARCH, perhaps something like CFLAGS_MARCH...?!
And I would suggest to not use the prefix CONFIGURED_ here -- because I think this is not a case as for CFLAGS where we want to respect user variable settings?

Sure.

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 21, 2020

comment:138

And I thought you had found a better solution for that free-form business in #30375?

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 21, 2020

Branch pushed to git repo; I updated commit sha1. New commits:

7bc1f28remove redundant free-form patch

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Dec 21, 2020

Changed commit from 73ecf70 to 7bc1f28

@kliem
Copy link
Contributor Author

kliem commented Dec 21, 2020

comment:140

Replying to @mkoeppe:

And I thought you had found a better solution for that free-form business in #30375?

Right, I forgot to change that.

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 21, 2020

comment:141

Looks good to me. If you have capacity on GH Actions, could you run it one more time? (Ideally with #31064 for the latest version of the cygwin workflow)

@kliem
Copy link
Contributor Author

kliem commented Dec 22, 2020

@kliem
Copy link
Contributor Author

kliem commented Dec 22, 2020

comment:143

Replying to @mkoeppe:

Looks good to me. If you have capacity on GH Actions, could you run it one more time? (Ideally with #31064 for the latest version of the cygwin workflow)

Capacities are fine. Actually, I'm not using it most of the time, so if you ping me, I can run something.

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 25, 2020

Changed reviewer from Matthias Koeppe, https://github.com/mkoeppe/sage/actions/runs/434965861, https://github.com/kliem/sage/pull/30/checks to Matthias Koeppe

@mkoeppe
Copy link
Contributor

mkoeppe commented Dec 25, 2020

comment:144

Looking good. Thanks for your patience with this long review process.

@vbraun
Copy link
Member

vbraun commented Dec 27, 2020

Changed branch from u/gh-kliem/march_native_on_30375 to 7bc1f28

@kliem
Copy link
Contributor Author

kliem commented Dec 28, 2020

comment:146

Replying to @mkoeppe:

Looking good. Thanks for your patience with this long review process.

Thank you. And thank you in particular for creating the github workflow for testing.

@kliem
Copy link
Contributor Author

kliem commented Dec 28, 2020

Changed commit from 7bc1f28 to none

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants