> I think the test for cach size and number of CPUs should be removed > from the configure script, for several reasons. > > From what I can gather from the autoconf list > > * Both macros, which you took from the auotconf macro archive, are > badly written - not just in what they do, but in a very general > sence. > > * Both will never work on non-x86 platforms. > > * I'm told from the autoconf developers that those macros will not > even work properly on many x86 processors. I asume this is mainly the > one for cache size, which relies on looking up the processor type in a > list of processors. As new processors are introduced, that is going to > be less and less useful. > > * Whilst I accept that most people build Sage to run on their own > machines, not everyone does. Hence deterining this at compile-time is > not the best place to do it. > > Instead the tests should be move to run-time. From what I gather from > one of the autoconf developers, the 4MRI library uses OpenMP. There is > code in OpenMP which can determine the number of processors at run- > time. I've not looked at this in any detail, but a quick glace on an > OpenMP tutorial > > https://computing.llnl.gov/tutorials/openMP/#OMP_SET_NUM_THREADS > > shows things like: > *************************************************************************** > *** #include <omp.h> > int omp_get_num_procs(void) > > Returns the number of processors that are available to the program. > > *************************************************************************** > *** > > I suspect the cache size will be more difficult to obtain, but > findining cache size is the sort of task that computer science > students do to find out the characteristics of the processors they are > running on. Ultimatey, some run-time test is probably best. I do not > know the details, but I can imagine that reading/writing randomlly to > an array would slow dramatically once the size of the array exceeds > the cache size. > > Either way, I would give the user the option to override an > automatically determined value. In particular, you might want to > consider limiting the number of processors used by default to some > number such as 8. I made this point some time back, about a patch > commited to Sage, which was later changed. My point is that if a > machine has more than 8 CPUs, it is highly likely to be a shared > system, and an individual should not be putting such a heavy load on > the machine. Instead, limit the number of procesors used to 8, but > give a user an option to set it to any number they want. > > If you can get some code together I can certainly try it on a number > of multi-processor machines I have access to. I can give you access to > the HP C3600 running HP-UX 11.11. But ultimatley, to make this cross > platform, any lookup of processor types is going to be a nightmare as > new CPUs are introduced.
I tend to agree with your point when it comes to the number of CPUs, that probably should be run-time instead of compile time. Btw. I just checked, this information isn't even used! This is now: http://bitbucket.org/malb/m4ri/issue/16/remove-check-for-number-of-cpus-from- autoconf Wrt the cache size I am not convinced. I see the problems you point out, but having the values as compile time constants should be make a difference, I should double check this though. Also, running this check on every library load seems like overkill to me. I will implement something dynamic which can be used at compile time instead of the hardcoded checks which we use right now. http://bitbucket.org/malb/m4ri/issue/17/implement-dynamic-run-time-check-for- l1-and-l2-cache Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
