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