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. On Tuesday, 26 July 2016 21:04:23 UTC+2, William wrote: > > On Tue, Jul 26, 2016 at 11:39 AM, leif <not.r...@online.de <javascript:>> > 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 > -- 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.
