On Fri, Dec 18, 2020 at 6:14 PM William Stein <wst...@gmail.com> wrote: > > Hello, > > There is a thread [1] on sage-support about using Sage on the new > Apple M1 ARM 64-bit based laptops. I have one of these, so I decided > to investigate, since this M1 processor is very, very impressive > regarding the compute / watt ratio. > > Tom Judson asked: > > I have a new MacBook Air with an Apple M1 chip. Does the Intel version of > > Sage 9.2 work on this machine? > > I assume by this question he really means "does the intel binary build > of Sage work"? It's a weird question, since Tom can presumably just > download the binary and see whether the answer is yes or no, so > presumably he already tried that and it didn't obviously work, but he > doesn't say either way. > > Dima responds: > > 9.2 is not known to work on macOS 11 (the one you have on M1), as far as I > > know. > > I think this means that nobody has tried it yet and reported back > either way to the mailing list. So I downloaded > sage-9.2-OSX_10.15.7-x86_64.dmg from > http://files.sagemath.org/osx/intel/index.html, extracted it, and > tried it. > > (1) I tried using the normal Terminal: > ``` > % cd /Applications/SageMath > % ./sage > ... > > /Applications/SageMath/src/bin/sage-python: line 2: 6235 Killed: 9 > sage -python "$@" > ``` > > (2) I tried making a copy of Terminal that is run using Rosetta 2, as > explained in the Homebrew install directions. > ``` > % cd /Applications/SageMath > % ./sage > ... > ``` > > A message pops up: "“python3.8” cannot be opened because the developer > cannot be verified. macOS cannot verify that this app is free from > malware." So I disable Gatekeeper: > > ``` > % sudo spctl --master-disable > ``` > > Then go to the "Security & Privacy --> General" configuration dialog > and re-enable python. Trying to run Sage again gives a dialog and the > option to run Python. Say "Open". Now sage does appear to start > (takes over a minute!), showing various warnings as things get > imported: > > ``` > wstein@Williams-MBP SageMath % ./sage > > ┌────────────────────────────────────────────────────────────────────┐ > > │ SageMath version 9.2, Release Date: 2020-10-24 │ > > │ Using Python 3.8.5. Type "help()" for help. │ > > └────────────────────────────────────────────────────────────────────┘ > > /Applications/SageMath/local/lib/python3.8/site-packages/traitlets/config/loader.py:795: > SyntaxWarning: "is" with a literal. Did you mean "=="? > > if len(key) is 1: > > /Applications/SageMath/local/lib/python3.8/site-packages/traitlets/config/loader.py:804: > SyntaxWarning: "is" with a literal. Did you mean "=="? > > if len(key) is 1: > > > /Applications/SageMath/local/lib/python3.8/site-packages/sage/calculus/functional.py:57: > DeprecationWarning: invalid escape sequence \d > > """ > ``` > > It works! (And startup is very fast after the first slow startup.) > ``` > sage: 2+2 > 4 > sage: integrate(sin(x^2),x) > /Applications/SageMath/local/lib/python3.8/site-packages/mpmath/ctx_mp_python.py:892: > SyntaxWarning: "is" with a literal. Did you mean "=="? > > if other is 0: > > /Applications/SageMath/local/lib/python3.8/site-packages/mpmath/ctx_mp_python.py:986: > SyntaxWarning: "is" with a literal. Did you mean "=="? > > if other is 0: > > 1/16*sqrt(pi)*((I + 1)*sqrt(2)*erf((1/2*I + 1/2)*sqrt(2)*x) + (I - > 1)*sqrt(2)*erf((1/2*I - 1/2)*sqrt(2)*x) - (I - > 1)*sqrt(2)*erf(sqrt(-I)*x) + (I + 1)*sqrt(2)*erf((-1)^(1/4)*x)) > sage: ModularSymbols(389,sign=1).decomposition()[-1] > Modular Symbols subspace of dimension 20 of Modular Symbols space of > dimension 33 for Gamma_0(389) of weight 2 with sign 1 over Rational > Field > ``` > > Jupyter notebook fails though with > > ``` > wstein@Williams-MBP SageMath % ./sage -notebook > ModuleNotFoundError: No module named '_ssl' > The Jupyter notebook requires ssl, even if you do not use > https. Install the openssl development packages in your system and > then rebuild Python (sage -f python3). > ``` > > It is of course impossible to build or install anything with this > binary. Why do we not ship openssl as part of the binary (the license > issues got resolved a few years ago)? It's not resolved yet.
E.g. python.org binary installer on macOS has a two-stage installation process, where the 2nd step does some kind of blessing of ssl certs. The installer banner says "At the end of this install, click on Install Certificates to install a set of current SSL root certificates." > Do we really ship binaries for > OS X that can't even wrote Jupyter notebook... yes we do. > or maybe this is a side effect of Rosetta2. no > > In any case, Sage works, but Jupyter notebook doesn't. However, one > could certainly directly install Jupyter separate from Sage, then > create a kernel. I'm sure that would (eventually) work, so the answer > to Tom's original question is basically **YES**, the Sage 9.2 x86 > binary works on Apple's M1 chip. > > What about Cython code? Works fine (note -- I do have xcode and > homebrew installed): > > ``` > wstein@Williams-MBP SageMath % vi a.spyx. # make a little program in cython... > sage: %load a.spyx > sage: f(10) > 11 > ``` > > Dima adds: > > You might try building the latest beta in Homebrew installed into the Intel > > emulator. We are very curious to know how far one can go this way. > > I tried this and I can report that, for me at least, this was a > complete disaster. Though I could install homebrew, I tried many > times in various ways, and couldn't really get *anything* in Sage to > successfully compile, though ./configure worked. a common catch with Homebrew is forgetting to run source .homebrew-build-env before ./configure > Even cython fails to > build (with issues finding stdio.h). I don't know if this is the > result of recent changes to homebrew (there is a new Dec 2020 release) > or the new MacOS 11.1 Big Sur version, or XCode. I'll also note that > running ./configure under x86 emulated homebrew seeme slow (it > reminded me of cygwin). > > Tom later adds: > > Homebrew is a quick and easy install under Rosetta (the Intel emulator). > > Python 3.8 is there, and I finally got Jupyter Notebook installed. > > However, when JN opens I have a problem. I gave up last night but may try > > to work on it later today. - Tom > > I didn't understand what he meant by the above at first; I hoped he > meant "installing Sage under homebrew was easy but Jupyter didn't > work". I think that's definitely NOT what he means. I think he means > that just installing homebrew at all is easy, but that even running > Jupyter (let alone Sage) is problematic. Or maybe he means he > installed the sage binary after installing homebrew like I described > above? > > Given what Sage really is (packaging a lot of upstream > developed-on-linux libraries), we might also focus harder on making > Sage-on-Linux available in as simple of a way as possible on Windows > and OS X, rather than native ports. One thing about Sage is that > (probably) because of Rasberry Pi, there is very good support for > building Sage on ARM linux (thanks to the people who spent so much > time on this over the years!). Docker-desktop for Apple M1 just came > out, and it makes it super easy to get a native ARM 64-bit Linux > Hypervisor running (there are other ways to accomplish this, but > Docker makes it absurdly easy). Basically, just install from here > [2], then > > ``` > docker run -td --name=sage-arm ubuntu > docker exec -it sage-arm bash > > root@79ac2b56798b:/# uname -a > Linux 79ac2b56798b 4.19.104-linuxkit #1 SMP PREEMPT Sat Feb 15 > 00:49:47 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux > ... > root@79ac2b56798b:/# git clone https://github.com/sagemath/sage.git > ``` > > Note the architecture "aarch64". After that, do all the standard > things to build sage in Ubuntu 20.04 on 64-bit ARM Linux (I installed > all recommended packages). This fails when building sagelib due to > running out of RAM, since docker by default only gets 2GB RAM. > Configure that in Docker desktop's configuration; I increased the > memory to 4GB and cores to 8. Once I did that, and I also did `export > MAKE='make -j8'`, then all of Sage quickly built. Here's what > happened when I ran "make test" (so almost perfect): > > ``` > ---------------------------------------------------------------------- > sage -t --random-seed=0 src/sage/groups/finitely_presented_named.py # > 1 doctest failed > sage -t --random-seed=0 src/sage/interfaces/singular.py # Killed due > to segmentation fault > sage -t --random-seed=0 src/sage/misc/package.py # 1 doctest failed > sage -t --random-seed=0 > src/sage/schemes/elliptic_curves/ell_rational_field.py # Timed out > after testing finished > sage -t --random-seed=0 src/sage/modular/arithgroup/arithgroup_perm.py > # Timed out > sage -t --random-seed=0 src/doc/en/thematic_tutorials/group_theory.rst > # 2 doctests failed > sage -t --random-seed=0 > src/doc/en/thematic_tutorials/vector_calculus/vector_calc_plane.rst # > Timed out > ---------------------------------------------------------------------- > Total time for all tests: 5119.5 seconds > cpu time: 2138.8 seconds > cumulative wall time: 3105.7 seconds > ``` > > It does startup and works well, of course. How do timings compare? > > Benchmark: I tried a bunch of random CPU intensive computations > comparing this build to a Google Cloud Platform server build of Sage > (in CoCalc) and in most cases sage on ARM64 in M1 Docker was twice as > fast. Also, using x86 emulation with the sage binary was pretty good. > Typical Example: > > ``` > Apple M1 ARM Linux: > sage: %time d = random_matrix(QQ,1000)**2 > CPU times: user 379 ms, sys: 78.6 ms, total: 458 ms > Wall time: 457 ms > > Intel on Google Cloud Platform: > sage: %time d = random_matrix(QQ,1000)**2 > CPU times: user 923 ms, sys: 102 ms, total: 1.03 s > Wall time: 1.02 s > > Apple M1 x86 emulation with sage binary: > sage: %time d = random_matrix(QQ,1000)**2 > CPU times: user 560 ms, sys: 49.2 ms, total: 609 ms > Wall time: 628 ms > ``` > > Another example: > ``` > Apple M1 ARM Linux: > sage: %time ModularSymbols(5077,sign=1).decomposition() > CPU times: user 10 s, sys: 447 ms, total: 10.5 s > Wall time: 10.7 s > > Intel on Google Cloud Platform: > sage: %time ModularSymbols(5077,sign=1).decomposition() > CPU times: user 24.2 s, sys: 501 ms, total: 24.7 s > Wall time: 25 s > > Apple M1 x86 emulation with sage binary: > sage: %time ModularSymbols(5077,sign=1).decomposition() > CPU times: user 13.7 s, sys: 176 ms, total: 13.8 s > Wall time: 13.9 s > ``` > > And something that is just using Python3 ints internally, so simpler: > > ``` > Apple M1 ARM Linux: > sage: %time sum(range(10^8)) > CPU times: user 771 ms, sys: 0 ns, total: 771 ms > > Intel on Google Cloud Platform: > sage: sage: %time sum(range(10^8)) > CPU times: user 1.96 s, sys: 3.82 ms, total: 1.96 s > > Apple M1 x86 emulation with sage binary: > sage: %time sum(range(10^8)) > CPU times: user 1.83 s, sys: 10.7 ms, total: 1.84 s > ``` > > I also have a powerful new Dell Windows 10 laptop with a 10th gen > Intel processor and Sage installed via Docker there (the cocalc-docker > image) and the benchmarks there look a lot like "Apple M1 x86 > emulation with sage binary" above: > ``` > sage: %time d = random_matrix(QQ,1000)**2 > CPU times: user 544 ms, sys: 40 ms, total: 584 ms > sage: %time ModularSymbols(5077,sign=1).decomposition() > CPU times: user 14.3 s, sys: 170 ms, total: 14.4 s > sage: %time sum(range(10^8)) > CPU times: user 1.85 s, sys: 0 ns, total: 1.85 s > ``` > > I'm well aware that above I'm comparing different *versions* of Sage > (9.2 versus 9.3 beta), and some were built from source and others are > binaries, and that can all easily make a huge difference. The > takeaway is that all are sufficiently fast to use for everyday work > and that the native built ARM 64-bit build under Docker on the M1 is > very good indeed. > > Anyway, this M1 apple laptop is pretty amazing. I was building Sage > from source **on battery** and it stayed fast, the battery barely > noticed, and the fans didn't come on. WOW. This is a game changer > regarding battery life when doing CPU heavy tasks. I really wish I > had this laptop during "Sage Days on a Train" many years ago... > > > [1] https://groups.google.com/g/sage-support/c/h7WLXgHBVnk/m/WSPgMSkKAgAJ > [2] > https://www.docker.com/blog/download-and-try-the-tech-preview-of-docker-desktop-for-m1/ > > -- > William (http://wstein.org) > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/CACLE5GC3n%2Bf%3D9hU%3DnsnCGrG1bjDr0NtobGUaF5Ubp82jrkEtaQ%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-support/CAAWYfq3mxSOByYtuD2%2B7JdC58RiuM-oTFkcGx2NAZH4zxTn%2Bpw%40mail.gmail.com.
