Sage on Bash on Ubuntu on Windows

[VulK]

Hi All,
Some time ago I briefly played with Bash on Ubuntu on Windows with some
limited success. The situation dramatically improved recently. I would risk
saying that our nightmares to support windows are nearly over.


Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\VulK>bash
root@DESKTOP-U13FH0M:/mnt/c/Users/VulK# uname -a
Linux DESKTOP-U13FH0M 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
root@DESKTOP-U13FH0M:~# apt-add-repository -y ppa:aims/sagemath
root@DESKTOP-U13FH0M:~# apt-get update
...
root@DESKTOP-U13FH0M:~# apt-get install sagemath-upstream-binary
...
root@DESKTOP-U13FH0M:/mnt/c/Users/VulK# sage

SageMath version 7.2, Release Date: 2016-05-15
Type "notebook()" for the browser-based notebook interface.
Type "help()" for help.

sage: 2+2
4
sage:


even the notebook seems to work just fine. I did not play with x11 yet.

If I am not mistaken Bash should be available to everyone with the upcoming
windows update without the need to install a developer preview.
Best
S.


TLDR: there is no need to support windows directly any more: it can now run
executables compiled for Ubuntu

[Erik Bray]

I disagree for a few reasons:

1) This is not available to all Windows users.
2) Currently this feature is intended as a developer tool only;
Microsoft has stated explicitly that it is not intended for end-user
application distribution on Windows. That said, I see no reason it
couldn't be used that way, but there are limitations to its use for
that purpose. For example, it is a walled garden--it is not possible,
for example, to run native applications within the "bash" environment
3) It's unclear what performance impact this has over a native
application. Less, certainly, than using Cygwin.

Probably others as well.

[VulK]

I am not proposing this as our final solution since, as you point out, it is
a suboptimal hack on many respects; I am just saying that we can use this
today (actually from Aug 2nd) to bring anyone running windows 10 on the sage
bandwagon with minimal effort on our side. If I am not mistaken Bash should
be available to anyone with Windows 10 Anniversary Update on that date not
just developers.

Clearly performance are not going to be good, native applications are the way
to go for this; on the other hand I am not sure it is much (or at all?)
slower than a virtual machine setup.

Best
S.



* Erik Bray <erik....@gmail.com> [2016-07-26 13:25:31]:

> --
> 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 post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Erik Bray]

On Tue, Jul 26, 2016 at 1:42 PM, VulK <etn4...@gmail.com> wrote:
> I am not proposing this as our final solution since, as you point out, it is
> a suboptimal hack on many respects; I am just saying that we can use this
> today (actually from Aug 2nd) to bring anyone running windows 10 on the sage
> bandwagon with minimal effort on our side. If I am not mistaken Bash should
> be available to anyone with Windows 10 Anniversary Update on that date not
> just developers.
>
> Clearly performance are not going to be good, native applications are the way
> to go for this; on the other hand I am not sure it is much (or at all?)
> slower than a virtual machine setup.

Yes, absolutely agreed it is (soon to be) the best available stop-gap measure :)

[Volker Braun]

On Tuesday, July 26, 2016 at 1:25:34 PM UTC+2, Erik Bray wrote:

2) Currently this feature is intended as a developer tool only; 

On the plus side every user who is interested in Sage will immensely benefit from the scientific software universe that opens up by installing the ubuntu-on-windows layer. As long as Microsoft keeps supporting it I'd say that solution is even superior to a native windows app. 

[Jori Mäntysalo]

On Tue, 26 Jul 2016, VulK wrote:

> Clearly performance are not going to be good, native applications are
> the way to go for this; on the other hand I am not sure it is much (or
> at all?) slower than a virtual machine setup.

Virtualization is not emulation. CPU-intensive applications have more than
99% of the speed compared to bare metal.

--
Jori Mäntysalo

[Bill Hart]

I don't see any reason why Sage under the WSL should be much slower than a native app. I strongly suspect it will be way faster and certainly infinitely better than Cygwin.

[Vincent Delecroix]

<not a troll>
The real solution is of course to install a Unix environment and delete
windows forever. As long as Microsoft supports it.
</not a troll>

[Erik Bray]

On Tue, Jul 26, 2016 at 4:25 PM, Vincent Delecroix

OS bashing will not be tolerated.

[leif]

Well, depends on the implementation of the VM (and hardware as well as
OS support).

But if "CPU-intensive" means no (frequent, complex) system calls, that's
/usually/ true.


W.r.t. "native": Most binaries from Ubuntu won't exploit the
capabilities of modern CPUs though.


-leif

[leif]

But company bashing will... ;-)

Microsoft used to have a POSIX layer also; no idea what happened to that
(and how usable it actually was/is).

But it never made it into mainstream Windows AFAIK.


-leif

[Erik Bray]

On Tue, Jul 26, 2016 at 6:21 PM, leif <not.r...@online.de> wrote:
> Erik Bray wrote:
>> On Tue, Jul 26, 2016 at 4:25 PM, Vincent Delecroix
>> <20100.d...@gmail.com> wrote:
>>>
>>>
>>> On 26/07/16 07:52, Volker Braun wrote:
>>>>
>>>> On Tuesday, July 26, 2016 at 1:25:34 PM UTC+2, Erik Bray wrote:
>>>>>
>>>>>
>>>>> 2) Currently this feature is intended as a developer tool only;
>>>>
>>>>
>>>>
>>>> On the plus side every user who is interested in Sage will immensely
>>>> benefit from the scientific software universe that opens up by installing
>>>> the ubuntu-on-windows layer. As long as Microsoft keeps supporting it I'd
>>>> say that solution is even superior to a native windows app.
>>>>
>>>
>>> <not a troll>
>>> The real solution is of course to install a Unix environment and delete
>>> windows forever. As long as Microsoft supports it.
>>> </not a troll>
>>
>> OS bashing will not be tolerated.
>
> But company bashing will... ;-)

That's not really okay either--constructive criticisms are fine but
you never know where your next funding source will come from...

> Microsoft used to have a POSIX layer also; no idea what happened to that
> (and how usable it actually was/is).
>
> But it never made it into mainstream Windows AFAIK.

Yep. My understanding is that the current WSL did in fact grow out of
that but it had been left undocumented and deteriorating for a long
time.

[William Stein]

On Tue, Jul 26, 2016 at 9:21 AM, leif <not.r...@online.de> wrote:
>> OS bashing will not be tolerated.
>
> But company bashing will... ;-)
>
> Microsoft used to have a POSIX layer also; no idea what happened to that
> (and how usable it actually was/is).
>
> But it never made it into mainstream Windows AFAIK.

In the interest of balance, last week Microsoft donated USD $5K to
support the Women in Sage Days conferences.

This new Ubuntu in Windows initiative is really fantastic. I'm glad
they (evidently) now support fork and pseudotty's -- they didn't when
somebody tried a few months ago, and I heard that this was their top
priority.

Regarding the above discussion about speed, what combination of
OS/Virtualization/Emulations/Native/etc. is actually fastest is not
something that can be determined by "pure thought", since there are
two additional factors (which I saw a lot in work of Bill Hart, Jason
Moxham and Brian Gladman on MPIR and FLINT):

1. Performance is multidimensional. It can easily be that f(X) is
faster in one setting, whereas g(X) is slower. Or even that the
relative speed of f depends on X.

2. Performance depends enormously on how much work has gone into
optimizing libraries for certain platforms. E.g., once when I tested
using MPIR in Linux via VirtualBox on Windows, it was much faster than
just using MPIR natively built using MSVC (no claims about today).
Why? Much more effort had gone into optimizing MPIR on Linux than on
native Windows.

-- William

--
William (http://wstein.org)

[Erik Bray]

On Tue, Jul 26, 2016 at 6:33 PM, William Stein <wst...@gmail.com> wrote:
> On Tue, Jul 26, 2016 at 9:21 AM, leif <not.r...@online.de> wrote:
>>> OS bashing will not be tolerated.
>>
>> But company bashing will... ;-)
>>
>> Microsoft used to have a POSIX layer also; no idea what happened to that
>> (and how usable it actually was/is).
>>
>> But it never made it into mainstream Windows AFAIK.
>
> In the interest of balance, last week Microsoft donated USD $5K to
> support the Women in Sage Days conferences.

My point exactly :)

> This new Ubuntu in Windows initiative is really fantastic. I'm glad
> they (evidently) now support fork and pseudotty's -- they didn't when
> somebody tried a few months ago, and I heard that this was their top
> priority.

Yes. The fork support especially is going to be a big win--fork on
Cygwin is a big ol' mess especially due to DLL rebasing.

> Regarding the above discussion about speed, what combination of
> OS/Virtualization/Emulations/Native/etc. is actually fastest is not
> something that can be determined by "pure thought", since there are
> two additional factors (which I saw a lot in work of Bill Hart, Jason
> Moxham and Brian Gladman on MPIR and FLINT):
>
> 1. Performance is multidimensional. It can easily be that f(X) is
> faster in one setting, whereas g(X) is slower. Or even that the
> relative speed of f depends on X.
>
> 2. Performance depends enormously on how much work has gone into
> optimizing libraries for certain platforms. E.g., once when I tested
> using MPIR in Linux via VirtualBox on Windows, it was much faster than
> just using MPIR natively built using MSVC (no claims about today).
> Why? Much more effort had gone into optimizing MPIR on Linux than on
> native Windows.

Yes--this is why I hesitate to assume one way or the other.

[William Stein]

On Tue, Jul 26, 2016 at 9:37 AM, Erik Bray <erik....@gmail.com> wrote:
> On Tue, Jul 26, 2016 at 6:33 PM, William Stein <wst...@gmail.com> wrote:
>> On Tue, Jul 26, 2016 at 9:21 AM, leif <not.r...@online.de> wrote:
>>>> OS bashing will not be tolerated.
>>>
>>> But company bashing will... ;-)
>>>
>>> Microsoft used to have a POSIX layer also; no idea what happened to that
>>> (and how usable it actually was/is).
>>>
>>> But it never made it into mainstream Windows AFAIK.
>>
>> In the interest of balance, last week Microsoft donated USD $5K to
>> support the Women in Sage Days conferences.
>
> My point exactly :)

Microsoft has donated over $60K to Sage development over the years
(these are as 100% pure gifts -- never ever a contract) . When I say
"Microsoft" I really mean a particular person (Kristen Lauter) was
able to get Microsoft to donate. I try not to make her difficult job
of extracting a donation from Microsoft even harder.

>
>> This new Ubuntu in Windows initiative is really fantastic. I'm glad
>> they (evidently) now support fork and pseudotty's -- they didn't when
>> somebody tried a few months ago, and I heard that this was their top
>> priority.
>
> Yes. The fork support especially is going to be a big win--fork on
> Cygwin is a big ol' mess especially due to DLL rebasing.

I'm very curious -- is the new Ubuntu in Windows fork fast? E.g., a
few milliseconds? Or is it potentially very slow (half second) like
on Cygwin?

>
>> Regarding the above discussion about speed, what combination of
>> OS/Virtualization/Emulations/Native/etc. is actually fastest is not
>> something that can be determined by "pure thought", since there are
>> two additional factors (which I saw a lot in work of Bill Hart, Jason
>> Moxham and Brian Gladman on MPIR and FLINT):
>>
>> 1. Performance is multidimensional. It can easily be that f(X) is
>> faster in one setting, whereas g(X) is slower. Or even that the
>> relative speed of f depends on X.
>>
>> 2. Performance depends enormously on how much work has gone into
>> optimizing libraries for certain platforms. E.g., once when I tested
>> using MPIR in Linux via VirtualBox on Windows, it was much faster than
>> just using MPIR natively built using MSVC (no claims about today).
>> Why? Much more effort had gone into optimizing MPIR on Linux than on
>> native Windows.
>
> Yes--this is why I hesitate to assume one way or the other.
>

> --
> 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 post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



--

William (http://wstein.org)

[leif]

William Stein wrote:
> Regarding the above discussion about speed, what combination of
> OS/Virtualization/Emulations/Native/etc. is actually fastest is not
> something that can be determined by "pure thought", since there are
> two additional factors (which I saw a lot in work of Bill Hart, Jason
> Moxham and Brian Gladman on MPIR and FLINT):
>
> 1. Performance is multidimensional. It can easily be that f(X) is
> faster in one setting, whereas g(X) is slower. Or even that the
> relative speed of f depends on X.

Sure. Therefore different code paths are selected depending on the
machine (processor, cache size etc.; jump tables or selection at build
time) as well as on parameters of a function (ALGORITHM_FOO_THRESH).

But it think we were rather referring to executing (almost) exactly the
same code on the same bare metal, but in different environments (native
OS vs. some VM / abstraction layer).

In practice, performance may of course in addition vary (heavily!)
depending on "external" factors, such as system load and topology etc.

> 2. Performance depends enormously on how much work has gone into
> optimizing libraries for certain platforms. E.g., once when I tested
> using MPIR in Linux via VirtualBox on Windows, it was much faster than
> just using MPIR natively built using MSVC (no claims about today).
> Why? Much more effort had gone into optimizing MPIR on Linux than on
> native Windows.

Not necessarily. That's

a) GCC vs. MSVC

b) native machine code vs. (presumably) generic (or probably some more
generic code than the processor actually supports), as there are no
"fat" builds on Windows AFAIK. (You have to explicitly choose the
target architecture or "generic" when building with MSVC.)


(Unpredictable?) scheduling on Windows when trying to tune is another
issue, as is in a VM running on top of Windows, according to Bill I think.


-leif

[William Stein]

On Tue, Jul 26, 2016 at 11:39 AM, leif <not.r...@online.de> wrote:
> William Stein wrote:
>> Regarding the above discussion about speed, what combination of
>> OS/Virtualization/Emulations/Native/etc. is actually fastest is not
>> something that can be determined by "pure thought", since there are
>> two additional factors (which I saw a lot in work of Bill Hart, Jason
>> Moxham and Brian Gladman on MPIR and FLINT):
>>
>> 1. Performance is multidimensional. It can easily be that f(X) is
>> faster in one setting, whereas g(X) is slower. Or even that the
>> relative speed of f depends on X.
>
> Sure. Therefore different code paths are selected depending on the
> machine (processor, cache size etc.; jump tables or selection at build
> time) as well as on parameters of a function (ALGORITHM_FOO_THRESH).
>
> But it think we were rather referring to executing (almost) exactly the
> same code on the same bare metal, but in different environments (native
> OS vs. some VM / abstraction layer).

Summary: it's potentially misleading to "referring to executing
(almost) exactly the
same code on the same bare metal," since that's rarely what Sage is doing.
Much of Sage depends on MPIR (and ATLAS), and neither of those packages
runs the same code on different platforms.

>> 2. Performance depends enormously on how much work has gone into
>> optimizing libraries for certain platforms. E.g., once when I tested
>> using MPIR in Linux via VirtualBox on Windows, it was much faster than
>> just using MPIR natively built using MSVC (no claims about today).
>> Why? Much more effort had gone into optimizing MPIR on Linux than on
>> native Windows.
>
> Not necessarily. That's
>
> a) GCC vs. MSVC
>
> b) native machine code vs. (presumably) generic (or probably some more
> generic code than the processor actually supports), as there are no
> "fat" builds on Windows AFAIK. (You have to explicitly choose the
> target architecture or "generic" when building with MSVC.)

Correct me if I'm wrong, but there's significant code in MPIR that is
architecture and OS specific, at both the C and assembly level...

You're right that it's not a priori *necessarily* true that "Much more

effort had gone into optimizing MPIR on Linux than on native Windows."

However, my impression is that it is actually true. Maybe Bill
Hart or Brian Gladman will clarify.

-- William

[Bill Hart]

The MPIR code runs ok on Windows, though it is always some small factor behind Linux (usually 15% where we've bothered to check). So far we've been unable to superoptimise for that platform because the OS just never gets quiet enough for the superoptimiser to work.

However, there can be other reasons why Windows code would be slower. We don't fully understand them all, but for example, we see consistently about a 4x slowdown in Flint functions on Windows vs Linux, even when compiling for native Windows.

The compiler has different restrictions (registers that must be preserved, copies of data that must be made, etc.), the memory allocation is slower and many, many other things. A lot of it boils down to far less effort having gone into that platform across the board, than has gone into optimising for Linux. Everything from the compiler to the libraries we are using. 

I guess we'll know in a few days whether WSL can be a good solution for open source mathematical projects. I've actually been really looking forward to Microsoft releasing it.

Bill.

[leif]

William Stein wrote:
> On Tue, Jul 26, 2016 at 11:39 AM, leif <not.r...@online.de> wrote:
>> William Stein wrote:
>>> Regarding the above discussion about speed, what combination of
>>> OS/Virtualization/Emulations/Native/etc. is actually fastest is not
>>> something that can be determined by "pure thought", since there are
>>> two additional factors (which I saw a lot in work of Bill Hart, Jason
>>> Moxham and Brian Gladman on MPIR and FLINT):
>>>
>>> 1. Performance is multidimensional. It can easily be that f(X) is
>>> faster in one setting, whereas g(X) is slower. Or even that the
>>> relative speed of f depends on X.
>>
>> Sure. Therefore different code paths are selected depending on the
>> machine (processor, cache size etc.; jump tables or selection at build
>> time) as well as on parameters of a function (ALGORITHM_FOO_THRESH).
>>
>> But it think we were rather referring to executing (almost) exactly the
>> same code on the same bare metal, but in different environments (native
>> OS vs. some VM / abstraction layer).
>
> Summary: it's potentially misleading to "referring to executing
> (almost) exactly the
> same code on the same bare metal," since that's rarely what Sage is doing.

With "(almost) exactly the same code" I really meant *machine*
instructions, not some high-level language code.

The "almost" just because *some* (typically few) machine instructions
are emulated in a VM, so the number of instructions effectively executed
may be higher than "on the bare metal", without virtualization or some
other abstraction layer.

That is, for example, comparing the speed of a computation on Linux to
that on Linux in a VM on Windows, on the *same* machine, using the same
binary. (Or, more on topic, sagemath-upstream-binary on Ubuntu vs. the
same sagemath-upstream-binary on the same Ubuntu on Windows.)

> Much of Sage depends on MPIR (and ATLAS), and neither of those packages
> runs the same code on different platforms.
>
>>> 2. Performance depends enormously on how much work has gone into
>>> optimizing libraries for certain platforms. E.g., once when I tested
>>> using MPIR in Linux via VirtualBox on Windows, it was much faster than
>>> just using MPIR natively built using MSVC (no claims about today).
>>> Why? Much more effort had gone into optimizing MPIR on Linux than on
>>> native Windows.
>>
>> Not necessarily. That's
>>
>> a) GCC vs. MSVC
>>
>> b) native machine code vs. (presumably) generic (or probably some more
>> generic code than the processor actually supports), as there are no
>> "fat" builds on Windows AFAIK. (You have to explicitly choose the
>> target architecture or "generic" when building with MSVC.)
>
> Correct me if I'm wrong, but there's significant code in MPIR that is
> architecture and OS specific, at both the C and assembly level...

The only difference at the C level I know of is different #includes
(maybe some OS types and functions), and the size of long on 64-bit,
which is only 32 bits on 64-bit Windows (only long long is 64 bits
there), with some impact on the public library interface.

> You're right that it's not a priori *necessarily* true that "Much more
> effort had gone into optimizing MPIR on Linux than on native Windows."
> However, my impression is that it is actually true. Maybe Bill
> Hart or Brian Gladman will clarify.

It's true that there are different folders (MPN_PATH) for the same CPU
on Linux and Windows, but AFAICT "only" due to different assembler
syntax (irrelevant to performance) and -- perhaps even to a lesser
extent -- different calling conventions / ABIs (which *might* have an
impact on performance, e.g. which registers need to get saved and
restored, or can be used at all, access to shared data and functions
etc.). Besides the directory structure (which is doubled), not much
different to, say, PowerPC on Linux/ELF vs. Darwin/Mach-O, where in
contrast simply external macro definitions make the difference.

So Brian had to "port" Jason's assembly code for x86 and x86_64 to
"x86w" and "x86_64w" (where asm files are in plain Intel assembly, not
to be preprocessed by m4), sometimes straight-forward, sometimes with
more effort. (Brian and Bill will of course know better, but that was
my impression.)


-leif

[Bill Hart]

On Tuesday, 26 July 2016 23:12:03 UTC+2, leif wrote:

<SNIP>

 

The only difference at the C level I know of is different #includes
(maybe some OS types and functions), and the size of long on 64-bit,
which is only 32 bits on 64-bit Windows (only long long is 64 bits
there), with some impact on the public library interface.

There are sometimes different code paths depending on which native assembly functions are available.

Regarding 32 vs 64 bits, MPIR uses 64 bits on 64 bit Windows, even for _ui and _si arguments.

 

> You're right that it's not a priori *necessarily* true that "Much more
> effort had gone into optimizing MPIR on Linux than on native Windows."
>  However, my impression is that it is actually true.    Maybe Bill
> Hart or Brian Gladman will clarify.

It's true that there are different folders (MPN_PATH) for the same CPU
on Linux and Windows, but AFAICT "only" due to different assembler
syntax (irrelevant to performance) and -- perhaps even to a lesser
extent -- different calling conventions / ABIs (which *might* have an
impact on performance, e.g. which registers need to get saved and
restored, or can be used at all, access to shared data and functions
etc.).

We are able to use yasm on both Linux and Windows. The main difference is the ABI and the fact that some of the assembly on Windows is custom written (though not much).

 

 Besides the directory structure (which is doubled), not much
different to, say, PowerPC on Linux/ELF vs. Darwin/Mach-O, where in
contrast simply external macro definitions make the difference.

So Brian had to "port" Jason's assembly code for x86 and x86_64 to
"x86w" and "x86_64w" (where asm files are in plain Intel assembly, not
to be preprocessed by m4), sometimes straight-forward, sometimes with
more effort.  (Brian and Bill will of course know better, but that was
my impression.)

Code that is faster on Linux isn't always faster on Windows. Most of it is just a straight "port", even made using automated tools which Brian wrote. But there are some exceptions.

Bill.

[Nicolas M. Thiery]

On Tue, Jul 26, 2016 at 06:29:22PM +0200, Erik Bray wrote:
> >> OS bashing will not be tolerated.
> >
> > But company bashing will... ;-)
>
> That's not really okay either--constructive criticisms are fine

+1

> but you never know where your next funding source will come from...

This argument is a bit dangerous, as it suggests that we, as a
community, would shut up for money. Granted, bashing any group
whatsoever can be very counter productive by alienating potential
users and collaborators; this is one practical reason to avoid it. But
the main reason is that it's unethical and non scientific.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Erik Bray]

On Wed, Jul 27, 2016 at 8:11 AM, Nicolas M. Thiery
<Nicolas...@u-psud.fr> wrote:
> On Tue, Jul 26, 2016 at 06:29:22PM +0200, Erik Bray wrote:
>> >> OS bashing will not be tolerated.
>> >
>> > But company bashing will... ;-)
>>
>> That's not really okay either--constructive criticisms are fine
>
> +1
>
>> but you never know where your next funding source will come from...
>
> This argument is a bit dangerous, as it suggests that we, as a
> community, would shut up for money.

It's just the first example I reached for.

> Granted, bashing any group
> whatsoever can be very counter productive by alienating potential
> users and collaborators; this is one practical reason to avoid it. But
> the main reason is that it's unethical and non scientific.

Yes, you also never know who you're collaborating with or what their
background is.

[VulK]

On the topic of performances I just came across this post on phoronix:
http://www.phoronix.com/scan.php?page=article&item=windows-10-lxcore&num=1

TL;DR: benchmarks give surprisingly good performances provided you do not
access the filesystem. At the moment, while running sage could be ok, this
would make compiling it on WSL a terrible nightmare.

S.




* Erik Bray <erik....@gmail.com> [2016-07-26 18:37:43]:

[leif]

VulK wrote:
> On the topic of performances I just came across this post on phoronix:
> http://www.phoronix.com/scan.php?page=article&item=windows-10-lxcore&num=1
>
> TL;DR: benchmarks give surprisingly good performances provided you do not
> access the filesystem. At the moment, while running sage could be ok, this
> would make compiling it on WSL a terrible nightmare.

This presumably also affects Sage's start-up time (and in general,
Python imports), as it loads hundreds of .so's.


For Windows 95 and 98[SE] IIRC, there existed an ext2 filesystem
driver... ;-)


-leif

[VulK]

* leif <not.r...@online.de> [2016-08-03 11:03:38]:

> VulK wrote:
> > On the topic of performances I just came across this post on phoronix:
> > http://www.phoronix.com/scan.php?page=article&item=windows-10-lxcore&num=1
> >
> > TL;DR: benchmarks give surprisingly good performances provided you do not
> > access the filesystem. At the moment, while running sage could be ok, this
> > would make compiling it on WSL a terrible nightmare.
>
> This presumably also affects Sage's start-up time (and in general,
> Python imports), as it loads hundreds of .so's.

Yep! It is not really bad but it is not great either.

>
>
> For Windows 95 and 98[SE] IIRC, there existed an ext2 filesystem
> driver... ;-)
>
>
> -leif
>
>

[Jean-Pierre Flori]

https://sourceforge.net/projects/ext2fsd/

Worked ok the few time I had to use Windows and had to access stuff on my ext4 partition.

[Bill Hart]

There are some awful issues with WSL for now. It has a stack limit of 8MB which means certain programs that expect a  >= 16MB stack won't work. ulimit refuses to increase the stack size.

Building things can be *incredibly* slow. Not that this shouldn't be a major issue for now, since it is supposed to run ordinary Ubuntu binaries. No need to build them specially for WSL.

The Sage binary tarball takes 25 minutes to untar!

I found a number of packages that seems to corrupt the .o files during the build process every now and again, requiring one to delete the .o files by hand and rebuild them. Of course this doesn't happen on real Ubuntu. However, it seems to only happen when doing a parallel build.

We are getting lots of double free and corruption errors on code that works absolutely fine on real Ubuntu (though this might just be the memory manager being more sensitive to actual bugs), and spawning seems to result in a Not Enough Memory error no matter what.

Moreover, one needs to download and install the Anniversary update, which takes hours, then one needs to enable developer tools, including the WSL. That takes ages to install. Then one needs to install Ubuntu, which takes quite a while in itself.

It's Ubuntu 14.04 and many of the packages are quite old, e.g. gcc 4.8.

So far I am not that impressed. However, it is marked beta, so I hope they will improve it over time.

On the other hand, the ordinary Ubuntu-14.04 binary for Sage seems to actually work. It takes about a minute to start up the first time.

As a timing comparison I did a Fateman polynomial benchmark on my 2 GHz Haswell laptop vs a 2.2 GHz K10 Ubuntu server.

The timing on the laptop was 176s. On the server it took 169s. So that seems about right.

A pearce polynomial benchmark took 95 s on the laptop and 85s on the server.

So as far as I'm concerned compute performance is isomorphic, especially given that Sage was built from source on the server and I used a generic Sage binary on the laptop.

And this is the first time ever that I have Sage at least partly working (maybe fully working) on my laptop! So that's really something.

If anyone has any particular benchmarks or code they'd like me to try, I'd be happy to try it out.

Note that one has access to the ordinary Windows file system, which people were worried about. And 'top' works. Microsoft are definitely on the right track here, but it still needs more work in my opinion. My guess is there's a small group within Microsoft responsible for this, and I'm sure they need the (moral) support of the Open Source community to keep going with this project, which is almost there. Maybe patience will pay off.

Bill.

[Bill Hart]

sage -t --all seems to be passing most of its tests. Any tests that require starting pari currently don't pass.

There were also some complaints about uncommitted changes in the git tree. Also control.py failed its test.

I managed to kill WSL (nothing to do with Sage) at the point Sage was half way through the groups tests. I can't be bothered restarting it.

There may have been other failures before that point that I didn't notice, but not many.

Bill.

[Vincent Delecroix]

Does at least "sage -gp" work?

Did you run "make ptestlong" to launch the tests? If so there is a log
in SAGE_ROOT/logs/ptestlong.log. That would be nice to have it!

[Bill Hart]

No I didn't. But I'll set it running overnight tonight.

I wonder if it is possible to actually give someone login access to my laptop by starting the sshd or something like that.

Bill.

[Bill Hart]

On Wednesday, 3 August 2016 18:23:27 UTC+2, vdelecroix wrote:

Does at least "sage -gp" work?

No.

wbhart@ASUS:~/SageMath$ ./sage -gp

gp: error while loading shared libraries: libpari-gmp-2.8.so.0: cannot open shared object file: No such file or directory 

Bill.

[Nils Bruin]

On Wednesday, August 3, 2016 at 11:16:16 AM UTC-7, Bill Hart wrote:

wbhart@ASUS:~/SageMath$ ./sage -gp

gp: error while loading shared libraries: libpari-gmp-2.8.so.0: cannot open shared object file: No such file or directory 

Is this a binary distribution? There used to be a problem with gp and the relocation required with binary distributions. If you have a ball that's packed with the old version of volker's script you might be hit by this:

 https://trac.sagemath.org/ticket/20592

[Paul Masson]

Running "make" under WSL for Sage 7.2.rc2 consistently hangs for me at this line:

checking whether rename honors trailing slash on source...

Could that be related to limits you mention or is it some other error?

[Erik Bray]

On Wed, Aug 3, 2016 at 3:44 PM, 'Bill Hart' via sage-devel
<sage-...@googlegroups.com> wrote:
> There are some awful issues with WSL for now. It has a stack limit of 8MB
> which means certain programs that expect a >= 16MB stack won't work. ulimit
> refuses to increase the stack size.

Thanks for this detailed status report Bill.

> Building things can be *incredibly* slow. Not that this shouldn't be a major
> issue for now, since it is supposed to run ordinary Ubuntu binaries. No need
> to build them specially for WSL.
>
> The Sage binary tarball takes 25 minutes to untar!
>
> I found a number of packages that seems to corrupt the .o files during the
> build process every now and again, requiring one to delete the .o files by
> hand and rebuild them. Of course this doesn't happen on real Ubuntu.
> However, it seems to only happen when doing a parallel build.
>
> We are getting lots of double free and corruption errors on code that works
> absolutely fine on real Ubuntu (though this might just be the memory manager
> being more sensitive to actual bugs), and spawning seems to result in a Not
> Enough Memory error no matter what.
>
> Moreover, one needs to download and install the Anniversary update, which
> takes hours, then one needs to enable developer tools, including the WSL.
> That takes ages to install. Then one needs to install Ubuntu, which takes
> quite a while in itself.

This experience in particular speaks to why Microsoft has insisted
that this is currently being positioned as a tool for *developer
convenience* only, and not a platform for end-user software
distribution. Again, it could be done, but it seems like almost more
hassle than the Docker approach, for "casual" users. Great though for
developers!

> It's Ubuntu 14.04 and many of the packages are quite old, e.g. gcc 4.8.
>
> So far I am not that impressed. However, it is marked beta, so I hope they
> will improve it over time.

Yup!

> On the other hand, the ordinary Ubuntu-14.04 binary for Sage seems to
> actually work. It takes about a minute to start up the first time.
>
> As a timing comparison I did a Fateman polynomial benchmark on my 2 GHz
> Haswell laptop vs a 2.2 GHz K10 Ubuntu server.
>
> The timing on the laptop was 176s. On the server it took 169s. So that seems
> about right.
>
> A pearce polynomial benchmark took 95 s on the laptop and 85s on the server.
>
> So as far as I'm concerned compute performance is isomorphic, especially
> given that Sage was built from source on the server and I used a generic
> Sage binary on the laptop.

Great. That's what I would have thought.

> Note that one has access to the ordinary Windows file system, which people
> were worried about. And 'top' works. Microsoft are definitely on the right
> track here, but it still needs more work in my opinion. My guess is there's
> a small group within Microsoft responsible for this, and I'm sure they need
> the (moral) support of the Open Source community to keep going with this
> project, which is almost there. Maybe patience will pay off.

To the filesystem yes, but you can't run Windows executables from
within the bash shell which is a minus.

[Bill Hart]

I don't know. I've spoken to one expert and he thinks almost all the issues are due to interfaces that aren't implemented by Microsoft yet. They have an online poll where you can vote for the features you'd most like to see them implement. Many of the items have thousands of votes, and they are gradually making their way through the list.

I expect that even the next release of WSL will be more robust. It might have been a little premature of them to release it as beta. Perhaps alpha would have been more logical at this point.

Bill.

[Bill Hart]

make ptestlong compiled for a very long time and then terminated with:

make[3]: Leaving directory `/home/wbhart/SageMath/src'

real    113m4.343s

user    100m46.281s

sys     8m50.719s

cd ../.. && sage-logger './sage --docbuild --no-pdf-links all html ' logs/dochtml.log

/home/wbhart/SageMath/local/bin/python: /home/wbhart/SageMath/local/lib/python2.7/site-packages/sage/rings/complex_double.so: undefined symbol: gsl_complex_sin; 'sage_setup.docbuild' is a package and cannot be directly executed

make[2]: *** [doc-html] Error 1

make[2]: Leaving directory `/home/wbhart/SageMath/build/make'

make[1]: *** [all] Error 2

make[1]: Leaving directory `/home/wbhart/SageMath/build/make'

real    113m30.334s

user    100m52.234s

sys     8m59.688s

***************************************************************

Error building Sage.

The following package(s) may have failed to build (not necessarily

during this run of 'make all'):

The build directory may contain configuration files and other potentially

helpful information. WARNING: if you now run 'make' again, the build

directory will, by default, be deleted. Set the environment variable

SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.

make: *** [all] Error 1

I have attached the logs. Note I am using a binary tarball not a source tarball.

Bill.

On Wednesday, 3 August 2016 18:23:27 UTC+2, vdelecroix wrote:

[Bill Hart]

Thanks for the hint. Yes, I used a binary. However, I downloaded it freshly from the Sage website, so I would guess it is not hit by any old issues?

Bill.

[Bill Hart]

In particular, the ticket says the problem was fixed 2 months ago, and I downloaded the tarball just yesterday.

Bill.

[Dima Pasechnik]

what is the output of ldd on 

/home/wbhart/SageMath/local/lib/python2.7/site-packages/sage/rings/complex_double.so

(I guess it's linked to a system library, and on your system it's a different one...)

[leif]

Erik Bray wrote:
> On Wed, Aug 3, 2016 at 3:44 PM, 'Bill Hart' via sage-devel
> <sage-...@googlegroups.com> wrote:

>> [BIG SNIP]

>> Note that one has access to the ordinary Windows file system, which people
>> were worried about. And 'top' works. Microsoft are definitely on the right
>> track here, but it still needs more work in my opinion. My guess is there's
>> a small group within Microsoft responsible for this, and I'm sure they need
>> the (moral) support of the Open Source community to keep going with this
>> project, which is almost there. Maybe patience will pay off.
>
> To the filesystem yes, but you can't run Windows executables from
> within the bash shell which is a minus.

Well, mounting a filesystem doesn't by its own mean you can run binaries
from there. ;-)

But for example ssh-ing from and to Windows would be cool as well, or
using arbitrary TCP/IP services from one "system" on the other. Perhaps
that's already possible in theory.


-leif

[Nils Bruin]

On Thursday, August 4, 2016 at 5:46:04 AM UTC-7, Bill Hart wrote:

In particular, the ticket says the problem was fixed 2 months ago, and I downloaded the tarball just yesterday.

Yes, but it was resolved as "wontfix", because the patch was added to a repository that Volker keeps outside of the sage tree. I can easily imagine that whoever rolled the new tarball might not have updated the relevant script: there wasn't a particular cue for that, other than the resolution of the ticket (and why would one be following that?). In any case, the binaries I can see are still just 7.2 and are from May, so they would predate the fix. Apparently people using binaries are quite happy with gp not working (indeed, gp only gets used for some rather specialist jobs)

If you check:

readelf -d gp | grep RPATH

you might be able to see if there is still some bad path hanging around. I'm almost certain you're running into this problem.

[Bill Hart]

wbhart@ASUS:~$ ldd /home/wbhart/SageMath/local/lib/python2.7/site-packages/sage/rings/complex_double.so

        linux-vdso.so.1 =>  (0x00007fffd8abf000)

        libpari-gmp-2.8.so.0 => /home/wbhart/SageMath/local/lib/libpari-gmp-2.8.so.0 (0x00007f000977d000)

        libgmp.so.16 => /home/wbhart/SageMath/local/lib/libgmp.so.16 (0x00007f00094ee000)

        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f00091d0000)

        libpython2.7.so.1.0 => /home/wbhart/SageMath/local/lib/libpython2.7.so.1.0 (0x00007f0008dc9000)

        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0008ba0000)

        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f00087d0000)

        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f00085c0000)

        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f00083b0000)

        /lib64/ld-linux-x86-64.so.2 (0x00007f000a400000)

[Bill Hart]

Yes, I am pretty sure this is the problem too, now that you've explained it.

Here is the output of readelf:

wbhart@ASUS:~/SageMath/local/bin$ readelf -d gp | grep RPATH

 0x000000000000000f (RPATH)              Library rpath: [/home/buildbot/slave/binary_pkg/build/source/SageMath/jc4b6yulaujayb9sr94ia88eourzeqip0oidmas391yaj2/local/lib:/home/buildbot/slave/binary_pkg/build/source/SageMath/jc4b6yulaujayb9sr94ia88eourzeqip0oidmas391yaj2/local/lib:/home/buildbot/slave/binary_pkg/build/source/SageMath/jc4b6yulaujayb9sr94ia88eourzeqip0oidmas391yaj2/local/lib:/usr/lib]

Those don't look like directories on my machine.

I'll try all this next time Sage tarballs are put up.

Bill.