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