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.