Some other packages do use assembly support, e.g. FLINT, zn_poly, possibly M4RI, probably numerous others.
And of course, in all that C code, the compiler is bound to apply optimisations specific to the build architecture in at least a handful of cases. The solution is of course to use generic C flags for all but the most performance critical stuff, which has to be handled differently. It is of course also possible that there are just bugs in some packages. Bill. On 18 Feb, 23:07, "Dr. David Kirkby" <[email protected]> wrote: > William Stein wrote: > > 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 > > So why does the issue keep coming up on sage-support? The thread "A command > which causes Sage to crash" was one recent example, but I've seen you advise > people to recompile specific parts of Sage before. > > Your post above would imply this should never be an issue, but that does not > appear to be so in practice. > > Dave -- 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
