2009/12/28 William Stein <wst...@gmail.com>: > On Sun, Dec 27, 2009 at 4:05 PM, Dr David Kirkby <drkir...@gmail.com> wrote: >> >> >> On Dec 27, 8:16 pm, mhampton <hampto...@gmail.com> wrote: >>> Seems about 8 times slower at some basic tests I have compared to >>> sagenb. > > What basic tests? Big integer arithmetic -- which relies on MPIR > -- is often an order of magnitude slower, because of lack of good > assembly optimization for Sparc. It probably *could* be much faster, > if somebody were to invest in supporting a developer to write code to > make it fast.
That would help, but the basic problem is those Sun T2+ (Niagra) processors are designed for a *very* dfferent task to what they are being used for. They are not designed for applications where single threaded peformance is important. They are designed for applications like busy web servers and databases, where there are many processes all competing for the CPU. In that case, the 128 threads will be put to good use. Most of the time, we are only using a very small fraction of the capabilities of that machine . http://groups.google.co.uk/group/comp.unix.solaris/browse_thread/thread/7041af61bab6cfd/718b4fb647765119?hl=en&ie=UTF-8&q=Single-threaded+T5240+performance&pli=1 shows an example of where a single-threaded integer task on the T5240 took 17.69 seconds, but that parallel version on the same machine took 0.32 seconds - a gain of 55x. > David -- I don't get how you can have a 30x slowdown with building > unless you're building in /home instead of /scratch, so that the true > slowdown is the crappy filesystem. It is certainly was not that. My home directory on 't2', is on a local file system, as I've long since moved the mountpoint on 't2' to not be /home. The only explanation I can think of, is that *possibly* I stopped the build, then restarted it, as I based this on a build that I already had on 't2'. I will recheck that later, but I very much doubt I did. But the fact the Sun T5240 was a bit slower than the HP C3600 did not surprise me, as I often senced the HP C3600 was faster at building Sage than 't2', even though I had not done any tests. >> Another issue is that the build is 32-bit, not 64-bit. For reasons I >> could never understand, Large bits of Sage add -m64 on OS X if SAGE64 >> is set to "yes". But many will not on Solaris. So trying a 64-bit >> build is not simple. > > Michael Abshoff ported Sage to 32-bit Solaris in May 2009 as the first > step to a general port. > He quit before even starting the 64-bit port. It just seems strange to have the -m64 only included if SAGE64 is 'yes' and the system is 'Darwin'. It would have been better to have simply added -m64 on any platform when the environment variable SAGE64 was set to 'yes'. Surely the *only* reason for setting the environment variable SAGE64 to "yes" would be when one wanted to build 64-bit. So why further make the restriction the operating system had to be Darwin (OS X)? I think the best way to apporach this is to use the script testcc.sh in http://trac.sagemath.org/sage_trac/ticket/7505 (awaiting review) then have in sage-env something like the following (untested, as writing on a windows laptop) C_COMPILER=`testcc.sh` if [ x$SAGE64 = "xyes" ] ; then if [ xC_COMPILER = "xIBM_on_AIX " ] ; then CFLAGS = "$CFLAGS -<64 bit option for IBM compiler>" elif [ x$C_COMILER = "xGNU" ] ; then CFLAGS = "$CFLAGS - m64 " elif [ xC_COMPILER = "xHP_on_HP-UX" ] ; then CFLAGS = "$CFLAGS -<64-bit option for HP C compiiler> " elif [ x$C_COMPILER = "xSun_Studio" ] ; then CFLAGS = "$CFLAGS - m64 " etc etc fi fi That way, the appropiate 64-bit flag is set correctly for any compiler once in sage-env, and never needs setting in spkg-install files. 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
