On 07/17/10 07:20 AM, Martin Albrecht wrote:
How does this sound.
1) We add an environment variable SAGE_ATLAS_THREADS
2) If unset, then the behavior is unchanged, so we build an unthreaded
ATLAS. 3) If set to "auto":
$ export SAGE_ATLAS_THREADS=auto
then we let ATLAS automatically determine the number of threads. (I think
that is what ATLAS determines as the number of processors on your system.
IIRC, on 't2.math' this was 128).
4) If set to an integer N,
$ export SAGE_ATLAS_THREADS=8
we use N (in this case 8) threads.
Hi,
somehow I get the feeling the number of environment variables in Sage is
increasing on an exponential rate.
I'd much rather not have some ATLAS specific environment variable. Instead -
if we need a variable - I'd have SAGE_NUM_CORES or something.
William convinced me the other day that it would be better to build with
multicore support by default (since that's the future anyway) instead of only
if some obscure variable is set. I'm sure this would require more work but
might be a worthwhile activity.
Martin
In an ideal world, everything would be threaded, and Sage would work.
In practice, it certainly possible that some part of Sage may not work reliably
threaded on some particular platform.
With your proposal, its an all or nothing situation.
I recall ages ago developing some software, which worked multi-threaded well, on
every platform except AIX. I spent ages looking at the code, then eventually
found there was a bug.
I recall a colleague whose multi-threaded code on Intel x86 worked well, but
failed when he run it on a SPARC. Once again, it was a mistake in his code.
I don't know if you have every written multi-threaded code, but it is
non-trivial and very easy to make a mistake. Experience shows me that those
mistakes show up on on one platform only. It's hard enough to track the bug if
you wrote the code yourself, since the bugs are not always reproducible. It
would be 100x harder if someone else had written the code.
So IMHO, it would be unwise to *only* have an ability to set the number of
threads globally. What may be more useful, is an ability to set the number of
threads globally, but have the ability to override that for particular cases.
Remember also that this parameter on ATLAS is a compile-time parameter - not a
run-time parameter.
Slightly related, we see a problem with William's builds on bsd.math recently.
There was a bug in the 'deps' file, which meant Sage could break. It broke for
William every time, but worked fine for everyone else, even on bsd.math.
Once you do anything on parallel, it becomes much more likely that you will
discover a bug.
Dave
--
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
