On Tue, Jul 26, 2016 at 11:39 AM, leif <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
