Apple M1 chip
227 views
Skip to first unread message
William Stein
Dec 18, 2020, 1:14:53 PM12/18/20
to sage-support, sage-devel
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)? Do we really ship binaries for
OS X that can't even wrote Jupyter notebook... or maybe this is a side
effect of Rosetta2.
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. 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)
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)? Do we really ship binaries for
OS X that can't even wrote Jupyter notebook... or maybe this is a side
effect of Rosetta2.
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. 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)
Dima Pasechnik
Dec 18, 2020, 2:26:09 PM12/18/20
to sage-devel, sage-support
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...
> or maybe this is a side effect of Rosetta2.
>
> 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.
source .homebrew-build-env
before ./configure
> 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/CACLE5GC3n%2Bf%3D9hU%3DnsnCGrG1bjDr0NtobGUaF5Ubp82jrkEtaQ%40mail.gmail.com.
William Stein
Dec 18, 2020, 3:41:03 PM12/18/20
to sage-devel, sage-support
On Fri, Dec 18, 2020 at 11:26 AM Dima Pasechnik <dim...@gmail.com> wrote:
> > 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.
But openssl is licensed apache2. Is the problem that only new
> > 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.
versions of openssl are so licensed, and they don't work well enough
yet? Just curious...
> > 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
checked). So I'm pretty stumped regarding this approach.
(Windows 10 aside:)
To add to my notes above, I mentioned that I also have a powerful new
Dell Windows 10 laptop with a 10th gen
Intel processor and Sage installed via Docker. I just built sage
9.3.beta4 on that machine entirely under WSL2 (+Ubuntu), i.e.,
"Windows Subsystem for Linux 2". The timings are much better than
with Docker desktop:
```
sage: %time d = random_matrix(QQ,1000)**2 # 516ms on WSL2
CPU times: user 544 ms, sys: 40 ms, total: 584 ms
sage: %time ModularSymbols(5077,sign=1).decomposition() # 11.3s on WSL2
CPU times: user 14.3 s, sys: 170 ms, total: 14.4 s
sage: %time sum(range(10^8)) # 953ms on WSL2
CPU times: user 1.85 s, sys: 0 ns, total: 1.85 s
```
Morever, WSL2 is very "integrated with Windows", with full filesystem
```
access, and super fast startup time. Also "./sage -notebook" just
worked with zero issues. So WSL2 is really, really good. It's
currently difficult to install on Windows 10, but I think it'll be
much easier sometime in the next year. One nice thing is that it
works fine on "Windows 10 home" -- you don't know pro anymore...
--
William (http://wstein.org)
Dima Pasechnik
Dec 18, 2020, 3:55:25 PM12/18/20
to sage-devel, sage-support
On Fri, 18 Dec 2020, 20:41 William Stein, <wst...@gmail.com> wrote:
On Fri, Dec 18, 2020 at 11:26 AM Dima Pasechnik <dim...@gmail.com> wrote:
> > 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.
But openssl is licensed apache2. Is the problem that only new
versions of openssl are so licensed, and they don't work well enough
yet? Just curious...
as far as I know there is no stable openssl version appropriately licensed, yet.
In fact what cpython does in its macOS installer is probably meant to trick lawyers. :-)
> > 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
Thanks. I did see that and it didn't help (and I just double
checked). So I'm pretty stumped regarding this approach.
(Windows 10 aside:)
To add to my notes above, I mentioned that I also have a powerful new
Dell Windows 10 laptop with a 10th gen
Intel processor and Sage installed via Docker. I just built sage
9.3.beta4 on that machine entirely under WSL2 (+Ubuntu), i.e.,
"Windows Subsystem for Linux 2".
we do of Sage CI on WSL(2?) using GitHub Actions, it does work, as far as I know.
The timings are much better than
with Docker desktop:
```
sage: %time d = random_matrix(QQ,1000)**2 # 516ms on WSL2
CPU times: user 544 ms, sys: 40 ms, total: 584 ms
sage: %time ModularSymbols(5077,sign=1).decomposition() # 11.3s on WSL2
CPU times: user 14.3 s, sys: 170 ms, total: 14.4 s
sage: %time sum(range(10^8)) # 953ms on WSL2
CPU times: user 1.85 s, sys: 0 ns, total: 1.85 s
```
Morever, WSL2 is very "integrated with Windows", with full filesystem
access, and super fast startup time. Also "./sage -notebook" just
worked with zero issues. So WSL2 is really, really good. It's
currently difficult to install on Windows 10, but I think it'll be
much easier sometime in the next year. One nice thing is that it
works fine on "Windows 10 home" -- you don't know pro anymore...
the problem is that there are Windows 10 machines around that just don't have WSL capabilities provisioned.
To install WSL one needs to go to a "shop", but the capacity to do this is not there.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GDv09_0WQZ2e2HSa1xrspdPWDT%3DYif_RzWvdbUTZ_DMOQ%40mail.gmail.com.
Matthias Koeppe
Dec 18, 2020, 4:30:27 PM12/18/20
to sage-devel
> However, one could certainly directly install Jupyter separate from Sage, then
> create a kernel. I'm sure that would (eventually) work,We have some tickets in this direction - see https://trac.sagemath.org/ticket/30306 -
which need help.
kcrisman
Dec 18, 2020, 10:35:42 PM12/18/20
to sage-devel
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...
Thanks for all this experimentation, William. Hope to help replicate and test for "ordinary" users :-) I am slated to have one of these delivered in 2021 for work and the battery issue will be great - our tech people have been singing its praises, anyway.
Reply all
Reply to author
Forward
0 new messages