jdemeyer
commented
5 years ago comment:1
The topic has nothing to do with polyhedra, many parts of Sage could benefit from it.
Closed kliem closed 3 years ago
jdemeyer
commented
5 years ago The topic has nothing to do with polyhedra, many parts of Sage could benefit from it.
jdemeyer
commented
5 years ago Changed keywords from Intrinsics, SIMD, Polyhedra, FindPoly to Intrinsics, SIMD
jdemeyer
commented
5 years ago 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).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
commented
5 years ago Ticket retargeted after milestone closed (if you don't believe this ticket is appropriate for the Sage 8.8 release please retarget manually)
embray
commented
5 years ago 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).
kliem
commented
4 years ago Branch: public/27122
kliem
commented
4 years ago New commits:
cdc8656 | compiling with `-march=native` for GCC from 5.1 and clang from 6.0 if SAGE_FAT_BINARY is not set |
kliem
commented
4 years ago I added a very naive approach of doing it. Wondering if this is remotely ok or going in the right direction.
dimpase
commented
4 years ago 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
commented
4 years ago 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’: Description changed:
---
+++
@@ -3,3 +3,50 @@
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 of where to do this. I'm inclined to do it for Python, such that it affects all Python packages (including the Sage library).
+
+** Please help testing this ticket:**
+
+- Pull the latest develop (for help, see [http://doc.sagemath.org/html/en/developer/manual_git.html](http://doc.sagemath.org/html/en/developer/manual_git.html))
+- Test the current sage, e.g. with
+
+```
+sage -t --long --all -p #
+```
+ where # denotes the number of threads you want to use.
+- Note which tests failed and the cpu time.
+- Checkout a new branch and pull this ticket, e.g.
+
+```
+git checkout -b test_march_native
+git pull trac public/27122
+```
+- Make sage.
+- Repeat the doctests:
+
+```
+sage -t --long --all -p #
+```
+
+The ticket works if:
+- sage builds
+- no new tests fail
+- the overall test time is somewhat similar
+
+Please report success or any failure (with log of the failure) as a comment to this ticket along with
+- operating system,
+- kernel,
+- architecture,
+- cpu model,
+- which of the following flags are set `sse4_1 avx avx2 popcnt`.
+One way to obtain those information is to run the following commands:
+- Linux:
+ - `hostnamectl` (for the first three items)
+ - `lscpu | grep -i "Model name"`
+ - `lscpu | grep -o sse4_1; lscpu | grep -o "avx "; lscpu | grep -o avx2; lscpu | grep -o popcnt`
+- OS X:
+ - `sysctl -n machdep.cpu.brand_string`
+ - `sw_vers`
+ - `uname -a`
+ - `sysctl -a | grep -o SSE4.1; sysctl -a | grep -o "AVX "; sysctl -a | grep -o AVX2; sysctl -a | grep -o POPCNT`
+
+Thank you. If you went through those steps, you can also quickly check #27103.It works for me. All tests passed. No significant time difference.
kliem
commented
4 years ago Description changed:
---
+++
@@ -36,17 +36,14 @@
- operating system,
- kernel,
- architecture,
-- cpu model,
-- which of the following flags are set `sse4_1 avx avx2 popcnt`.
+- cpu model.
One way to obtain those information is to run the following commands:
- Linux:
- `hostnamectl` (for the first three items)
- `lscpu | grep -i "Model name"`
- - `lscpu | grep -o sse4_1; lscpu | grep -o "avx "; lscpu | grep -o avx2; lscpu | grep -o popcnt`
- OS X:
- `sysctl -n machdep.cpu.brand_string`
- `sw_vers`
- `uname -a`
- - `sysctl -a | grep -o SSE4.1; sysctl -a | grep -o "AVX "; sysctl -a | grep -o AVX2; sysctl -a | grep -o POPCNT`
Thank you. If you went through those steps, you can also quickly check #27103.Works on
7822f248-ba56-45f1-ab3d-4de7482bdf9f
commented
4 years ago Success on my notebook running a Python 3-based 9.0.beta2 on top of Debian testing :
HTH,
dimpase
commented
4 years ago works on Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz (in 32-bit mode), Ubunty 14.04 LTS
orlitzky
commented
4 years ago 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 -O2in 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.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
4 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
4 years ago Branch pushed to git repo; I updated commit sha1. New commits:
9aabee1 | respect CFLAGS |
kliem
commented
4 years ago Ok, this should respect CFLAGS now.
I need to check yet, that the compiler can handle march=native. This is why I did it in the setup file.
orlitzky
commented
4 years ago Replying to @kliem:
Ok, this should respect CFLAGS now.
I need to check yet, that the compiler can handle
march=native. This is why I did it in the setup file.
I'd bet that our ./configure script is capable of doing that in a more reliable way, since it's something that C programs need to do often and python programs basically never. For example, I think we already check for a suitable version of gcc to see if we need to build our own. And we include an autoconf macro (m4/ax_c_check_flag.m4) that will try to compile a file using -march=native, and then report back if it worked or not.
Ideally, CFLAGS set in the environment will work everywhere, subject to upstream/spkg cooperation. But they definitely work in setup.py, so if we're able to detect these features at a higher level and then (by default) set CFLAGS/CXXFLAGS to include them, more code would be able to benefit from it. The setup.py script would still pick them up from the environment, but anything else that respects the environment variables would benefit, too.
(I don't know off the top of my head that setup.py doesn't affect spkgs, but I would guess not.)
kliem
commented
4 years ago Thanks for the comment by the way. It makes sense to me.
I'm just very busy at the moment and didn't have time to see how that could be handled by the configure script.
Replying to @orlitzky:
Replying to @kliem:
Ok, this should respect CFLAGS now.
I need to check yet, that the compiler can handle
march=native. This is why I did it in the setup file.I'd bet that our ./configure script is capable of doing that in a more reliable way, since it's something that C programs need to do often and python programs basically never. For example, I think we already check for a suitable version of gcc to see if we need to build our own. And we include an autoconf macro (m4/ax_c_check_flag.m4) that will try to compile a file using
-march=native, and then report back if it worked or not.Ideally, CFLAGS set in the environment will work everywhere, subject to upstream/spkg cooperation. But they definitely work in setup.py, so if we're able to detect these features at a higher level and then (by default) set CFLAGS/CXXFLAGS to include them, more code would be able to benefit from it. The setup.py script would still pick them up from the environment, but anything else that respects the environment variables would benefit, too.
(I don't know off the top of my head that setup.py doesn't affect spkgs, but I would guess not.)
orlitzky
commented
4 years ago This does the trick, but might be a bit blunt:
diff --git a/build/make/Makefile.in b/build/make/Makefile.in
index eea7ceb7dc..a5966b8011 100644
--- a/build/make/Makefile.in
+++ b/build/make/Makefile.in
@@ -17,6 +17,13 @@
# Always use bash for make rules
SHELL = @SHELL@
+# Use safe-but-efficient optimization flags, if the user does not
+# provide his own.
+CFLAGS ?= -O2 -march=native
+CXXFLAGS ?= -O2 -march=native
+export CFLAGS
+export CXXFLAGS
+
ifndef SAGE_SPKG_INST
ifndef DEBUG_RULES
$(error This Makefile needs to be invoked by build/make/install)In any case, it would make sense at that point to go through every spkg-install and strip out any "-O2" and "-march=native" additions.
kliem
commented
4 years ago Changed branch from public/27122 to public/27122-new
kliem
commented
4 years ago kliem
commented
4 years ago Thanks. I basically did it like this.
I also added -O0, -O2 and -g according to SAGE_DEBUG. This helps clean up a lot of code (basically every package sets those flags manually).
Finally, I used src/bin/testcflags.sh to remove unsupported flags.
The package ecm still adds -march=native on top of CFLAGS unless a similar flag is present.
Some packages prefer -O3 over -O2, so I left the flag -O3 as it is.
With this branch all tests passed on my end (ran distclean and installed all packages I touched).
Replying to @orlitzky:
This does the trick, but might be a bit blunt:
diff --git a/build/make/Makefile.in b/build/make/Makefile.in index eea7ceb7dc..a5966b8011 100644 --- a/build/make/Makefile.in +++ b/build/make/Makefile.in @@ -17,6 +17,13 @@ # Always use bash for make rules SHELL = @SHELL@ +# Use safe-but-efficient optimization flags, if the user does not +# provide his own. +CFLAGS ?= -O2 -march=native +CXXFLAGS ?= -O2 -march=native +export CFLAGS +export CXXFLAGS + ifndef SAGE_SPKG_INST ifndef DEBUG_RULES $(error This Makefile needs to be invoked by build/make/install)In any case, it would make sense at that point to go through every spkg-install and strip out any "-O2" and "-march=native" additions.
kliem
commented
4 years ago Is the new code acceptable?
orlitzky
commented
4 years ago LGTM at first glance. Good job figuring out what to do with SAGE_DEBUG and SAGE_FAT_BINARY, I missed those entirely.
I've never tried passing -march=native to gfortran, but it looks like it should work. I've added it to my local config for future builds.
The use of testcflags.sh only attempts to compile a C program with those flags, but then appends them to the compiler flags for C++ and fortran as well. That's not 100% correct, but I think we're already making the assumption that every compiler is from the same version of the same gcc suite? (Anyone?) So long as it works, I'd be happy with a comment about that. In the future, we could always change it to use the AX_CHECK_COMPILE_FLAG repeatedly, but that's overkill until we can actually swap out compilers.
kliem
commented
4 years ago Changed branch from public/27122-new to public/27122-reb
kliem
commented
4 years ago Ok, I added a comment about that assumption.
Is this at a point where people can/should test it again?
New commits:
0045dba | compile with '-O2 -march=native' if the user does not provide own flags |
4241dfe | added '-g' as standard compile flag; '-O0' is standard in case of debugging now |
ea3c0df | much simpler by using testcflags.sh |
60e3c36 | removed redundant flags -O2, -O0, -g |
bec54cc | remove flag -Wall by default |
e420546 | adding comment about assuming compilers from same suite |
kliem
commented
4 years ago Author: Jonathan Kliem
orlitzky
commented
4 years ago Yeah, now it just needs testing on a few different platforms. I've been using -march=native in my exported CFLAGS for years without problems, and your implementation looks OK to me, but I'm on a boring amd64/linux system and these days I'm doing my best to not build any spkgs.
While testing, you should be sure that the spkg really gets used (otherwise, the CFLAGS are irrelevant). The ./configure script nowadays will do its best to use packages from the system instead of an spkg. You can disable that using e.g. --without-system-foo, but there are a lot of flags you have to pass. Something like
$ ./configure --help | grep -oP '\-\-with-system[^ =]+' | sort | uniq | sed 's/with/without/'
--without-system-arb
--without-system-atlas
--without-system-bzip2
...can be used to get the full list for your branch.
kliem
commented
4 years ago Ok. Took a while, but it seems to work now. The test sage -t --long src/sage/interfaces/psage.py only worked on retry, but I guess this is fine.
What I did was basically the following:
$ make distclean
$ ./configure $(./configure --help | grep -oP '\-\-with-system[^ =]+' | sort | uniq | sed 's/with/without/' | grep -v gfortran | past -sd " ")
$ make build; ./sage -i openssl; ./sage -f python3; ./sage -i pyopenssl; make build
$ ./sage -i $(./sage --optional | awk -F\. '{print $1}' | grep -v warnings | grep -v package | grep -v gfort | grep -v buckygen |grep -v database | grep -v polymake | grep -v jupymake | paste -sd " ")
$ sage -i sage_numerical_backends_coin
$ make
$ sage -t --long --all(install gcc)
$ make distclean
$ ./configure $(./configure --help | grep -oP '\-\-with-system[^ =]+' | sort | uniq | sed 's/with/without/' | grep -v gfortran | grep -v gcc | past -sd " ")
$ make build; ./sage -i openssl; ./sage -f python3; ./sage -i pyopenssl; make build
$ ./sage -i $(./sage --optional | awk -F\. '{print $1}' | grep -v warnings | grep -v package | grep -v gfort | grep -v buckygen |grep -v database | grep -v polymake | grep -v jupymake | paste -sd " ")
$ sage -i sage_numerical_backends_coin; make; sage -t --long --all(use system gcc)
I'm often having trouble with openssl and I don't exactly understand the problem (but the workaround seems to work), so I guess you can ignore that part.
I would suggest the following for others to test it:
CFLAGS etc.make distclean$ ./configure --help | grep -oP '\-\-with-system[^ =]+' | sort | uniq | sed 's/with/without/' | grep -v gfortran | grep -v gcc | past -sd " "so e.g. one would configure to compile with clang as follows:
$ CC=clang CXX=clang++ FC=flang ./configure $(./configure --help | grep -oP '\-\-with-system[^ =]+' | sort | uniq | sed 's/with/without/' | grep -v gfortran | grep -v gcc | past -sd " ")$ ./sage -i $(./sage --optional | awk -F\. '{print $1}' | grep -v warnings | grep -v package | grep -v gfort | grep -v buckygen |grep -v database | grep -v polymake | grep -v jupymake | paste -sd " ") sage_numerical_backends_coinsage -t --all --longReport any (unusual) trouble you are having.
mkoeppe
commented
4 years ago To test build changes like this systematically, I recommend to use #29053 / #29087.
kliem
commented
4 years ago https://github.com/kliem/sage-test-27122/runs/422709282
I pulled the newest develop and #29087 to run those tests.
It's really hard to see the difference to your run: https://github.com/mkoeppe/sage/runs/422167181. I'm reducing my attention here to those tests that suceeded for you:
Problems with gsl for
Problems with gsl and libatomic_ops for
Never ran the following:
From this I gather that maybe one shouldn't use -march=native for those two packages. Does this make any sense?
Replying to @mkoeppe:
To test build changes like this systematically, I recommend to use #29053 / #29087.
kliem
commented
4 years ago New commits:
dc0e744 | compile with '-O2 -march=native' if the user does not provide own flags |
f8ce3b3 | added '-g' as standard compile flag; '-O0' is standard in case of debugging now |
f645f71 | much simpler by using testcflags.sh |
69b6d35 | removed redundant flags -O2, -O0, -g |
81a6ea5 | remove flag -Wall by default |
301bd2c | adding comment about assuming compilers from same suite |
kliem
commented
4 years ago Changed branch from public/27122-reb to public/27122-reb2
kliem
commented
4 years ago Can someone please help me with the following issue.
`/bin/sh: ../../src/bin/./testcflags.sh: No such file or directory`The following line seems to be a problem:
+opt := $(shell export CC=$(CC) && ../../src/bin/./testcflags.sh $(opt))Otherwise things are looking good, I would say.
Things have improved "by themselves" (of course not):
https://github.com/kliem/sage-test-27122/actions/runs/66307817
Now the current ticket (with #29087 merged) runs as smooth as the current beta https://github.com/mkoeppe/sage/actions/runs/65613035. However many tests got cancelled due to exceeding 6 hours.
sage: all(L.change_ring(SR).is_cross_positive_on(K)
for L in K.cross_positive_operators_gens()) # long time ## line 15240 ##Got cancelled at sage -t src/sage/numerical/linear_tensor.py (6 hours)
ubuntu-trusty, standard
Got cancelled at sage -t src/sage/modular/local_comp/liftings.py
ubuntu-trusty, standard-python2
Got cancelled at sage -t src/sage/schemes/affine/affine_subscheme.py
ubuntu-xenial, minimal -- ubuntu-bionic, minimal -- debian-jessie, minimal -- debian-buster, minimal -- fedora-26, minimal -- fedora-26, standard -- centos-8, standard -- archlinux-latest, minimal
ubuntu-xenial, standard -- ubuntu-xenial, standard-python2
ubuntu-bionic, standard -- ubuntu-bionic, standard-python2 -- ubuntu-focal, standard -- ubuntu-focal, standard-python2 -- linuxmint-19.3, standard, linuxmint-19.3, standard-python2
ubuntu-eoan, minimal
Got cancelled at sage -t src/sage/manifolds/differentiable/differentiable_submanifold.py
ubuntu-eoan, standard
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/u/underscore/libjs-underscore_1.8.3~dfsg-1_all.deb Could not connect to azure.archive.ubuntu.com:80 (52.177.174.250), connection timed out
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/s/sphinx/libjs-sphinxdoc_1.6.7-1ubuntu1_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/p/python-pluggy/python3-pluggy_0.6.0-1_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/p/python-py/python3-py_1.5.2-1_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/p/python-setuptools/python3-setuptools_39.0.1-2_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/p/python-virtualenv/python3-virtualenv_15.1.0+ds-1.1_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/p/python-virtualenv/virtualenv_15.1.0+ds-1.1_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/t/tox/tox_2.5.0-1_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/t/tox/python-tox_2.5.0-1_all.deb Unable to connect to azure.archive.ubuntu.com:http:
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?ubuntu-eoan, standard-python2
ubuntu-focal, minimal
cancelled at sage -t src/sage/geometry/hyperplane_arrangement/check_freeness.py
debian-jessie, standard
sage: if system() == "Linux":
P = subprocess.Popen(["sage", "-t", "--warn-long", "0", "--memlimit=2000", "memlimit.rst"], stdout=subprocess.PIPE, **kwds)
out, err = P.communicate()
ok = ("MemoryError: failed to allocate" in bytes_to_str(out)) ## line 521 ##probably related to [https://groups.google.com/d/msg/sage-release/kU5M1QVuQQY/IEX-j4PDAwAJ](https://groups.google.com/d/msg/sage-release/kU5M1QVuQQY/IEX-j4PDAwAJ)sage -t src/sage/manifolds/differentiable/degenerate_submanifold.py # Timed out
sage -t src/sage/rings/padics/padic_lattice_element.py # 3 doctests failed
sage -t src/sage/tests/cmdline.py # 3 doctests failed
debian-jessie, standard-python2
sage -t src/sage/rings/rational.pxddebian-buster, standard -- debian-buster, standard-python2
debian-bullseye, minimal
sage -t src/sage/modular/modform/weight1.pydebian-bullseye, standard -- debian-bullseye, standard-python2 -- debian-sid, standard
debian-sid, minimal
cancelled at sage -t src/sage/misc/bindable_class.py
linuxmint-19.3, minimal
sage -t src/sage/rings/polynomial/polynomial_number_field.pyxfedora-26, standard-python2
fedora-28, minimal
cancelled at sage -t src/sage/plot/disk.py
centos-7, minimal
sage -t src/sage/sat/solvers/satsolver.pxdcentos-8, standard
cancelled during [pplpy-0.8.4] installing. Log file: /sage/logs/pkgs/pplpy-0.8.4.log
centos-8, standard-python2
centos-8, minimal
cancelled at sage -t src/sage/manifolds/differentiable/characteristic_class.py
centos-8, standard-python2
cancelled during traceback of sage -t src/sage/manifolds/differentiable/degenerate_submanifold.py # Timed out
archlinux-latest, standard -- archlinux-latest, standard-python2
slackware (build failure, see #29373)
kliem
commented
4 years ago Replying to @kliem:
Can someone please help me with the following issue.
- conda-forge and homebrew-macos
`/bin/sh: ../../src/bin/./testcflags.sh: No such file or directory`The following line seems to be a problem:
+opt := $(shell export CC=$(CC) && ../../src/bin/./testcflags.sh $(opt))
mkoeppe
commented
4 years ago Replying to @kliem:
Replying to @kliem:
Can someone please help me with the following issue.
- conda-forge and homebrew-macos
`/bin/sh: ../../src/bin/./testcflags.sh: No such file or directory`The following line seems to be a problem:
+opt := $(shell export CC=$(CC) && ../../src/bin/./testcflags.sh $(opt))
Where do you see this line?
mkoeppe
commented
4 years ago Oh, I see, you added this on the ticket. See #29381.
mkoeppe
commented
4 years ago Lots of the doctest failures that you reported can also be seen on 9.1.beta9 on these platforms. Help with fixing them is very welcome. See https://groups.google.com/d/msg/sage-release/kU5M1QVuQQY/5vDLmipuAwAJ
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
4 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
4 years ago Branch pushed to git repo; I updated commit sha1. New commits:
2d1d798 | testcflags.sh has moved to build/bin |
We should compile Sage with the extra compile argument
-march=nativefor extra performance, at least ifSAGE_FAT_BINARYis not set.In
gcc/spkg_configure.acwe check, whether the argument-march=nativeis accepted.In
build/make/Makefile.inwe assemble the flags.We add
-march=nativeto 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.inwith one line, instead of checkingSAGE_DEBUGetc. for each individual package, e.g. byexport CFLAGS=$CFLAGS(redundant, use flags as above with-march=nativeif possible)export CFLAGS=$CFLAGS_NON_NATIVE(flags as above without-march=native)export CFLAGS=$CFLAGS_O3(O3instead ofO2, but only if not in debug mode, add-march=nativeif possible)export CFLAGS=$CFLAGS_O3_NON_NATIVE(O3instead ofO2, no-march=native)export CFLAGS=$ORIGINAL_CFLAGS(use$CFLAGSas set beforeconfigure)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
or
Depends on #30375
CC: @sophiasage @vbraun @embray @kiwifb
Component: build
Keywords: Intrinsics, SIMD
Author: Jonathan Kliem
Branch:
7bc1f28Reviewer: Matthias Koeppe
Issue created by migration from https://trac.sagemath.org/ticket/27122