Hi, I'm top posting, since I'm not responding to any particular remark on this thread. Sage *already* checks CPU flags on startup (see the SAGE_ROOT/local/lib/sage-flags.txt file and references to it in local/bin/sage-*). There is already a SAGE_FAT_BINARY flag for building Sage with a FAT mpir library *and* an ATLAS that runs on older hardware. I've been told that building ATLAS that way can result in a significant performance penalty (up to a factor of 4, say). All binaries I build for distribution are built with the SAGE_FAT_BINARY flag set.
This stuff was mostly implemented about 2 years ago by me, Michael Abshoff, and Jason Moxham... William On Thu, Feb 18, 2010 at 9:35 AM, Dr David Kirkby <[email protected]> wrote: > > > On 18 Feb, 13:05, Bill Hart <[email protected]> wrote: >> There are some problems with this. Compiling MPIR using generic C >> code, for example, will yield a *massive* slowdown of *everything*. > > > It would in general not be necessary to use C, but assembly code for a > low-end processor such as an early Pentium should be ok. With that, > the slowdown should not be so excessive. > >> Linbox and ATLAS are also somewhat problematic in this regard. > > > Yes, I can see this. IT's the reason I built the recent Sage binary on > an old machine - knowing no instructions would be used which would not > work on a more modern machine. Of course that slows the build time. > > >> The solution is to use fat binaries for MPIR on x86 and x86_64 and a >> minimum architecture for each other supported architecture. You can >> force MPIR to build using whatever architecture you like. However this >> should only be done for binaries, not when building from source, where >> MPIR will in general be able to do much better. > > Yes, obviously. > > I don't know how practical it would be to create a Sage installer > which copied appropiate binaries depending on the CPU.; From comments > I've seen here before, it appeas that recompiling 2 or 3 pacakages > (probably mpir being one of them), that the problem could be > cicumvented. > > > >> I'll let the Linbox and ATLAS people comment on their packages. >> However, I know that ATLAS, when it builds, tries multiple different >> assembly strategies until it finds an optimal one. It is possible to >> get within 30% of the assembly speed using generic C on some >> architectures, but I'm unsure if that can be done with ATLAS itself or >> not. The ratio might be somewhat greater, if it even provides a >> generic C implementation. >> >> Bill. > > I suspect C would be much slower, but if these programs have assembly > code for a first generation pentimum, then using that should be ok. > > Otherwise, just detecting the problem and refusing to install would be > better than the current situation where people install software only > to find they get misterious crashes > > -- > To post to this group, send an email to [email protected] > To unsubscribe from this group, send an email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
