CPU usage on Solaris - I have posted.
- To: mathgroup at smc.vnet.net
- Subject: [mg65816] CPU usage on Solaris - I have posted.
- From: see-my-signature at southminster-branch-line.org.uk
- Date: Mon, 17 Apr 2006 02:29:12 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
Reply to: Apr-2006 at southminster-branch-line.org.uk
I'll make a few additions/corrections to that post, in the light of new
information since I first posted it to the other newsgroups a few weeks
ago. Yes, I am the original poster - I just prefer to use this email
address so I can control the spam a bit more.
1) Sometimes Mathematica gives a warning if select_preload.so is
pre-loaded from /usr/local/lib/sparcv9, although it seems to work okay.
It obviously realises this is a non-standard location.
I stopped it complaining by putting the select_preload.so in
/usr/lib/sparcv9 instead.
2) There is a *second* problem which causes Mathematica to use excessive
CPU usage on *multi-processor* SPARC hardware. It appears to only happen
on problems where Mathematica tries to use the multiple processors -
which is actually very few.
One such computation, which will induce the problem, is finding the
Eigenvalues of a matrix:
In[1]: = Eigenvalues[Table[Random[], {750}, {750}]];
I found a workaround for this.
In the csh/tcsh or similar:
% setenv OMP_NUM_THREADS 1
% mathematica
or if you use the bourne/bash type shells
$ OMP_NUM_THREADS=1
$ mathematica
Another more drastic workaround is to take processors offline with psradm.
Of course, the downside of this is that Mathematica does not use the
multiple processors, but that is better than using them in a way that
just uses tons of CPU time, but is actually no faster.
I've no idea what hardware/software combinations cause this problem, but
it is happening on a quad processor Sun Ultra 80 with Solaris 10 and
Mathematica 5.2. I've no idea if it is a Mathematica or Solaris bug. I
think it might be connected with the original problem, but I am not 100%
sure.
For test purposes one *might* be able to induce this problem on a single
processor system by setting OMP_NUM_THREAD to a number >1, but I have
not tried.
3) The precise technical explanation of the timeout on the system call I
posted previously was incorrect. As a Mathematica user you will probably
not care less, but some corrected information can be found here.
http://groups.google.co.uk/group/sci.math.symbolic/tree/browse_frm/thread/3614dc0ccab52f29/4d2ac9cf438f5da2?rnum=1&hl=en&q=cpu+usage+mathematica&_done=%2Fgroup%2Fsci.math.symbolic%2Fbrowse_frm%2Fthread%2F3614dc0ccab52f29%2F4d2ac9cf438f5da2%3Flnk%3Dst%26q%3Dcpu+usage+mathematica%26rnum%3D2%26hl%3Den%26#doc_4481c9f5474a4724
http://groups.google.co.uk/group/sci.math.symbolic/tree/browse_frm/thread/3614dc0ccab52f29/4d2ac9cf438f5da2?rnum=1&hl=en&q=cpu+usage+mathematica&_done=%2Fgroup%2Fsci.math.symbolic%2Fbrowse_frm%2Fthread%2F3614dc0ccab52f29%2F4d2ac9cf438f5da2%3Flnk%3Dst%26q%3Dcpu+usage+mathematica%26rnum%3D2%26hl%3Den%26#doc_da9cb2a63b88bb4c
That erroneous description does not affect the workaround I posted, so
you still need to compile select_preload.c and preload select_preload.so.
--
Dave K MCSE.
MCSE = Minefield Consultant and Solitaire Expert.
Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@domain. Hitting reply will work
for a couple of months only. Later set it manually.