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


-- 
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.

Reply via email to