On Jun 9, 2008, at 5:17 PM, Jonathan Bober wrote:
> > On Mon, 2008-06-09 at 10:19 -0700, mabshoff wrote: >> >> [...] >> No clue. Can you actually compare the gp binary from Sage directly >> with the timings from your self builid binary to eliminate the >> problem >> that libPari is involved here? If the gp binary in Sage is slower >> by a >> factor of three compared to the one you build this sounds like a bug >> to me. But it could also be conversation overhead for example. > > Definitely could be conversion overhead. On my machine (warning: I'm > still running the "ridiculously old" Sage 2.10.2) I get > > sage: time y = pari(40000).bernfrac() > CPU times: user 4.14 s, sys: 0.00 s, total: 4.14 s > Wall time: 4.15 > sage: type(y) > <type 'sage.libs.pari.gen.gen'> > sage: time x = Rational(y) > CPU times: user 1.50 s, sys: 0.00 s, total: 1.50 s > Wall time: 1.50 > > It looks like the conversion from sage.lib.pari.gen.gen to > sage.rings.rational.Rational just converts y to a string and then > parses > the resulting string, which is why this takes so long. That's true, that definitely accounts for part of it. But there's still quite a big gap between the times from sage -gp and from my standalone GP build (see my followup email earlier on this thread). I wonder if we are just building GMP incorrectly. That bernfrac() routine should depend mainly on the speed of long integer multiplication and division. I am not a GP expert --- how does one generate large random integers in GP? I could try multiplying them to see how long that takes. david --~--~---------~--~----~------------~-------~--~----~ 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
