Dear list,
This is a followup on the threads dedicated to the alternatives existing to
use Sage math on Windows. More specifically, I did an informal comparison
of Erik Bray's Cygwin-based installer and using Windows 10 64 bits Windows
Subsystem for Linux.
I recently acquired (for other, unrelated, purposes) a small (< 11") and
light (<800g) notebook, bound to become (literally) a pocket machine. This
machine has an Atom z5 processor (1,4 MHz), 4 Gb memory and a 128 Gb SSD.
It starts with Win10 64 bit ("home edition").
It is still too new to be well-supported by common "live" distributions :
- Ubuntu boots its initial screen (rotated pi/2), allowing to start the
"live" system, but never displays anything else.
- Debian (which needs to be installed on an UEFI-enabled USB key, see
there <http://forums.debian.net/viewtopic.php?t=124417>) starts with
displaying its initial screen rotated pi/2, goes a long way in its booting
process, starts its graphical mode (still rotated pi/2), but ends up
crashing gnome.
So I decided to give Win10 a chance.
*Cygwin*
Erik Bray's installer for Sage 7.4 works flawlessly, and results in a
usable, if slow, Sage notebook. However, I never managed to get a prompt on
(native port <http://mirror.ibcp.fr/pub/gnu/emacs/windows/> of)emacs'
sage_shell_mode.
Furthermore, as far as I understand, installing an optional package
requiring compilation is not obvious...
So I decided to be a bit adventurous, and try :
*Windows Subsystem for Linux*
To avoid the limitations of the currently released system, I took the
following steps (details on demand) :
- Uninstalled Windows' emacs
- Upgraded to the latest Win10 release available via the "Windows
Insider" program (that cost me twenty-two fucking gigabytes (!) of
"Windows.old" recovery directory...).
- Upgraded the Ubuntu distribution to Xenial
- installed the requirements given in Sage's README
- Followed my own advice and installed a matching set of gcc, gfortran
and g++, as well as OpenSSL and its development libraries.
- installed (Ubuntu's) git.
- Cloned the git Sage tree, switched to develop and built Sage 7.6.beta3/
- Built Sage 7.6.beta3 (see below).
- Installed the VcXsrv <https://sourceforge.net/projects/vcxsrv/> X
server for Windows
- Installed (Ubuntu's) emacs, texlive, gnuplot, ghostscript (see below)
and imagemagick
- added an "alternative" to www-browser opening Windows' Firefox.exe
*Results :*
- Built is *extremely* slow : building from scratch took about 21 hours
(can't be precise, the compilation having been interrupted by network
losses and changes of place).
This was partly expected (one thread, low-power processor) ; however, a
main cause is that anything doisk-bound is dramatically slow : studying the
compilation log showed that the "system time" was about the same as "user
time" (in a normal Unix compilation, I usually get a "system time" about
2-5% of "user time").
- Starting Sage from the command line (Windows (via 'bash -c "DISPLAY=:0
sage"' or Linux) :
- Startup is slow
- Sage complains about a nonexistent /proc/vmstat
- Once started, Sage proceeds as expected on a Unix machine. Plots
are displayed by Imagemagick.
- I checked that the system is able to install and compile optional and
experimental packages.
- Starting the Jupyter notebook :
- Slow startup
- works as expected, including typeset output, 2D and 3D graphics
- Emacs + sage_shell_mode. That doesn't really works :
- Slow startup
- Sage complains about /proc/vmstat
- I never gets prompts
- Typing expression works and returns the expected results (in text
form)
- toggling either inline typesetting or inline plots starts an
infinite loop.
In order to explore this, I tested the imaxima emacs interface to Maxima,
usting what is distributed with Sage (in
$SAGE_ROOT/local/share/maxima/emacs/). This works flawlessly : I get
correct results, correctly typeset, and both inline (wxplot2d) or stndalone
(displayed with gnuplot) graphs. Emacs seems innocent of sage_shell_mode
problems.
The resulting system integrates well with the Windows interface (including
cut n' paste).
*Partial and interim conclusions :*
- The Linux subsystem has only, nonblocking, minor incompatibilities
with what Sage expects.
- The CPU performance is about what is expected from such a low-power
CPU.
- The disk-related performance is currently awful.
This is probably bound to the translation of disk I/O system calls to
NTFS-managed actions. To take an example, moving the Sage source tree after
"git clone", (i. e. "sudo mv sage /usr/local/sage-7"), which is more or les
instantaneous on an ext4 partition, takes about 30 seconds in the Windows
Subsystem for Linux.
- The interoperability of the subsystem with the host is acceptable (one
can call a Windows application from Linux, and a Linux application from
Windows, more or less transparently).
- The emacs problem remains to be understood.
Subjective point of view : I'm now a Unix die-hard. Installing a decent
Linux distribution and compiling Sage here seemed (to me) simpler than
configuring a set of Windows applications. The results show that this can
be done :
- using an unreleased version of Windows
- with a penalty in terms of initial installation complication
(installing a pre-compiled image or ppa would have spared me this, but I
wanted to assess the complication of the whole process)
- with a penalty in terms of disk I/O
- with acceptable results
- with the possibility of adding optional packages
The trade-offs are not obvious. No solution dominates the other. But both
solutions explored here (WSL vs Cygwin) seem to dominate the VM solution.
HTH,
-
Emmanuel Charpentier
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
