Hi, I haven't been following closely, but I wonder if it's a static vs shared thing. But usually that shouldn't account for such a large difference, so that's probably not the issue.
david On Jul 30, 2007, at 2:16 PM, Jonathan Bober wrote: > > Update: I've just been looking at this some more, having realized that > sage creates a detailed install.log file, and I can't find any > significant difference between the compiler options used when sage > compiles gmp and when I compile gmp manually. > > In particular, they both identify the processor the same way, and both > use > -mtune=pentium3 -march=pentium3 > > If also checked mpfr, and it seems to compile properly as well. I don't > know what's going on. > > On Mon, 2007-07-30 at 15:11 -0400, Jonathan Bober wrote: >> 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/ -~----------~----~----~----~------~----~------~--~---
