On Mon, 2007-07-30 at 01:21 -0700, William Stein wrote: > On 7/30/07, Jonathan Bober <[EMAIL PROTECTED]> wrote: > > > While timing the code that I wrote to compute p(n), I noticed that, in > > the latest version, it computes p(10^9) in: > > > > - approximately 2m 30s if I link to the gmp and mpfr included in Ubuntu > > (gmp version 3.something, I think) > > > > - approximately 3m 30s if I link to the gmp and mpfr included in sage > > 2.7.1 (built from source) > > > > - approximately 2m 18s if I link to the newest versions of gmp and mpfr > > that I just downloaded and compiled. > > Precisely which operating system and processor are you using?
Ubuntu 7.04 on a Core Duo (not Core 2) [on a Dell Inspiron E1505, but I don't that's important.] > You might want to take a look at spkg-install's in the gmp and > mpfr spkg's. In the spkg install scripts in the gmp spkg, I think the only package-specific configure flags are SAGE_CONF_OPTS="--enable-shared --disable-static" and spkg-install script for gmp runs configure as ./configure --prefix=$SAGE_LOCAL --enable-cxx=yes $SAGE_CONF_OPTS I'm not too familiar with the sage build process right now, so I'm not sure if there are other global options set. CFLAGS and CXXFLAGS might be set to something, and I don't know if this affects things. > > If so, it is not intentional. Probably if it were the case, the slowdown > would like be even more than you observed. > How do the precomiled binaries get built? Is it the same as everything else? I see that the binaries seem to require an i686 processor, but I think that gmp processor optimizations get more specific than this. (Wikipedia lists the Pentium Pro in the i686 family, and I don't think that the Pentium Pro even has any SSE instructions.) If the default build produces code that runs on a Pentium Pro, then it probably isn't producing optimized code for newer processors. I assume that there is an easy way for me to modify the spkg-install scripts for gmp and mpfr and then rebuild them - what is the process? > > Also, there is an --enable-fat for the ./configure script for gmp, that > > apparently compiles processor specific code for all x86 cpus, and > > selects the right code at run time. I would guess that this is what the > > Ubuntu build uses, and if my assumptions about how sage builds gmp are > > right, then that would explain why the Ubuntu version of gmp is faster. > > > > Anyway, I could be wrong about the reasons, but there is almost > > definitely something that causes my code to run slower when I link it to > > the sage build of gmp, and if this problem is widespread, then it > > probably causes a lot of slowdown throughout sage. > > There is clearly something seriously wrong based on your above timings, > and I hope we get to the bottom of it. I'm really glad you pointed > this out and have a clearly reproducible test case. > > By the way, on my MacBook Pro 2.33Ghz running OS x (and SAGE's GMP), > using your latest partitions code, it does p(10^9) in 1m 35s !! Wow. > Maybe I should have held out a few months for the Core 2 when I bought my laptop. A lot of that speedup probably comes from the fact that it is 64 bit. > sage: time v=number_of_partitions(10^9) > CPU times: user 94.72 s, sys: 0.27 s, total: 94.99 s > Wall time: 95.32 > sage: len(str(v)) > 35219 > sage: v%11 > 4 > > > By the way -- people wanting to upgrade sage-2.7.2 to have the latest > version of Jonothan's code, can just do hg_sage.pull() and > "sage -br". > > -- William > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
