On Tue, Oct 20, 2009 at 5:54 AM, Dr. David Kirkby <[email protected]> wrote: > > I reported earlier a problem with libm4ri which has code which determines the > number of CPUs and their cache sizes using autoconf macros. I do not know if > there is any other code in Sage that does this, but it was pointed out to me > on > by John Carr on comp.sys.hp.hpux that it's unwise to do this. > > When you think about it, he is absolutely right. Furthermore, it has much > wider > implications than the relatively rare HP-UX operating system which caused me > to investigate the issue, as one of the macros actually crashed on HP-UX. > > If we make a sage binary on sage.math with 24 cores, then any code like > libm4ri > that determines the number of processors at compile time will most likely work > far from optimally on a typical computer. Therefor the use of autoconf macros, > which only get executed at compile time, is not the place to determine the > number of processors available.
We don't build our binaries on sage.math. We build them on virtual machines that have 1 core. It's reasonable that binaries would be slightly non-optimal compared to something one would be one's self from source. > Does for example ATLAS if built on sage.math assume the user who downloads the > binaries has 24 CPUs? No. > In the case of libm4ri John Carr thought that uses Open MP, which would have a > way to determine the number of processors at run-time. > > This is just one more example of where testing on an unusual operating system > (HP-UX) highlights issues which have far wider implications than just on the > platform where the issue was found. Respectfully, the assertion that it is "wrong" to use characteristic of the hardware such as number of CPU's (and cache sizes, etc.) to tune their compilation strikes me as naive. Sure, it would be nice in theory if there existed some magic way to write code that could run optimally on all possible numbers of CPU's (processor flags, cache sizes, etc.), but I think that's basically impossible with present technology for nontrivial algorithms. -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
