I'm on the debian science email list, which is very low traffic, and would be happy to post a statement there. Should I just ask for a Debian developer to contact William Stein (or Martin Albrecht or me) if someone reading is a math package manager for Debian?
++++++++++++++++++++++++++++++++ On 10/14/06, William Stein <[EMAIL PROTECTED]> wrote: > > On Fri, 13 Oct 2006 15:43:47 -0700, Martin Albrecht > <[EMAIL PROTECTED]> wrote: > > > > > On Friday 13 October 2006 16:29, William Stein wrote: > >> omalloc is now GPL'd! See below. > > > > Excellent! Let's make sure the Debian people are informed. They might > > reconsider packaging Singular (which would mean that they threw their > > autoconf wisdom in). > > The relevant Debian thread is here: > > http://www.mail-archive.com/debian-mentors@lists.debian.org/msg46083.html > > However, that thread hides email addresses, and I don't know how or want to > sign up for that list. So I actually have no idea how to inform the Debian > people. Any ideas? > > > Also, I've built a shared library of omalloc (by hand, but easily > > automated), > > and here are the timing results: > > > > sage: x = 3; y = 5 # malloc (GMP default) > > sage: timeit _ = x + y > > 100000 loops, best of 3: 8.14 µs per loop > > sage: timeit _ = x + y > > 100000 loops, best of 3: 8.05 µs per loop > > > > sage: sage.rings.integer.pmem_malloc() > > > > sage: timeit _ = x + y # PyMem_Malloc > > 100000 loops, best of 3: 8.27 µs per loop > > sage: x = 3; y = 5 > > sage: timeit _ = x + y > > 100000 loops, best of 3: 8.21 µs per loop > > > > sage: omalloc_malloc() > > > > sage: timeit _ = x + y # omalloc > > 100000 loops, best of 3: 7.55 µs per loop > > sage: timeit _ = x + y > > 100000 loops, best of 3: 7.55 µs per loop > > > > My conclusion for small integers: PyMem_Malloc is slower than malloc or > > omalloc. omalloc is slightly faster than malloc. However I find these > > benchmarks not very expressive (Python overhead, little difference etc.) > > > > Larger integers: > > > > <restart> > > sage: x = > > 45234723458934634056310653251305043576435013985134515643531450714359863148659136951369851836545643565 > > > > sage: y = > > 23423964523462384234234234872345623645623452345283548234652365482348562346523642348263486234954534554 > > > > sage: timeit _ = x + y #malloc > > 100000 loops, best of 3: 8.3 µs per loop > > > > sage: sage.rings.integer.pmem_malloc() > > > > sage: timeit _ = x + y #PyMem_Malloc > > 100000 loops, best of 3: 8.58 µs per loop > > > > sage: omalloc_malloc() > > > > sage: timeit _ = x + y # omalloc > > 100000 loops, best of 3: 7.58 µs per loop > > > > Conclusion for larger integers: These benchmarks seem to reinforce the > > previous conclusion. > > > > Thoughts? > > Could you do some simpler benchmarks that compare malloc and omalloc, > and don't have anything to do with Python? E.g., direct C-level > mpz_init's, etc.? And allocation of int*'s, etc. That's *all* very > relevant to implementing SAGE. > > 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/ -~----------~----~----~----~------~----~------~--~---
