I am the main author of SAGE, which is software for Algebra
and Geometry Experimentation:
http://sage.math.washington.edu/sage
SAGE includes Singular, which in turn depends crucially on your
omalloc package. Many of the SAGE developers have spent a
significant amount of time during the last 1.5 years writing the
commutative algebra component of SAGE, which is built on top of Singular.
One of our developers (Martin Albrecht) was looking for libraries or
ideas for malloc replacements for some of the new libraries that we are
writing in certain cases, and discovered that omalloc has a restrictive
license. In particular, it says that "For this
package the GPL does not apply. Permission of use within the
software SINGULAR is granted by the author. In addition to this
permission to modify the sources is granted to the copyright holders
of SINGULAR. If you wish to use this package outside of SINGULAR
or to modify it in any way, please contact the author "Olaf Bachmann"".
It thus seems that by using omalloc in SAGE we are violating your
copyright, unless you give us permission to use it.
Moreover, as stated the copyright precludes inclusion of
omalloc (and hence Singular) in SAGE.
Questions:
(1) Do you give us permission to use omalloc as part
of SAGE?
(2) Do you give us permission to modify omalloc and
redistribute the changed versions?
Best regards,
William Stein
http://modular.math.washington.edu
------- Forwarded message -------
From: "Olaf Bachmann" <ol...@google.com>
To: "William Stein" <wst...@gmail.com>
Cc: sing...@mathematik.uni-kl.de
Subject: Re: omalloc
Date: Fri, 13 Oct 2006 01:03:49 -0700
Hi Wiliam,
sure, use and/or modify omalloc, no problem. @Singular team: I hereby ask
you to take away those special licensing restrictions of omalloc and to put
it under the same license as Singular.
Olaf
> Now that Singular is settled on (is this right?),
Yes, Singular is settled on. But Macaulay2 is still always an easy
(optional) install in the SAGE environment, and we'll continue to build
on it too. But for SAGE's core commutative algebra functionality
Singular is settled on.
William
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).
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?
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_icq: 177334829
_jab: martinr...@jabber.ccc.de
>
> 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-...@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?
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
++++++++++++++++++++++++++++++++
David -- Thanks for volunteering to do this. I think you should just post
this
message to the list. They should contact Singular about further
questions about Singular. Olaf's email very clearly indicates that
he releases omalloc under the GPL since it says "I hereby
ask you to take away those special licensing restrictions of omalloc and
to put
it under the same license as Singular."
---------------
From: "Olaf Bachmann" <ADDRESS DELETED>
To: "William Stein" <wst...@gmail.com>
Received: by 10.78.157.6 with HTTP; Fri, 13 Oct 2006 01:03:49 -0700 (PDT)
Subject: Re: omalloc
Cc: sing...@mathematik.uni-kl.de
Hi Wiliam,
sure, use and/or modify omalloc, no problem. @Singular team: I hereby ask
you to take away those special licensing restrictions of omalloc and to put
it under the same license as Singular.
Olaf
-------------------
Debian is a pretty large project so I'm sure that they would be just as stuck
as we are in finding out who wanted to package Singular. There is probably a
request-for-packaging in some Debian database and I would (correction: I
will) post a comment there.
Sure, will do. What do you mean by " allocation of int*'s ": Allocation of int
pointers (4/8 byte)? Anyway, I'll just perform several tests for different
sizes.
> Thoughts?
(1) I assume you're using omalloc as a drop-in replacement for
malloc, i.e. just substituting malloc/free/realloc or something like
that. Does omalloc have a more sophisticated interface though?
(2) Have you run the timings for x = y + z from a C loop, instead of
using timeit? To save you a bit of typing, here's what we were
playing with on the last day of the workshop:
http://sage.math.washington.edu/home/dmharvey/sage/test.spyx
Also are you testing with the patch that Joel and I were working on?
Here's one version (from Joel's directory), although this is NOT for
inclusion in SAGE yet:
http://sage.math.washington.edu/home/jbmohler/patches/
ring_element_addition.patch
David
It looks like that -- much stuff in omalloc.h -- but it doesn't seem to be
extensively documented (at least there is no bird-eye's-view). What would
your sophisticated interface look like - in a perfect world? Omalloc has the
usual stuff like calloc, memdup, strdup and some more advanced stuff like
mallocAligned, typed mallocs (which is just casting), and
debugging/statistics.
> (2) Have you run the timings for x = y + z from a C loop, instead of
> using timeit?
Not yet, but I will.
> To save you a bit of typing, here's what we were
> playing with on the last day of the workshop:
> http://sage.math.washington.edu/home/dmharvey/sage/test.spyx
Thanks.
> Also are you testing with the patch that Joel and I were working on?
> Here's one version (from Joel's directory)
No, vanilla SAGE 1.4.
> , although this is NOT for inclusion in SAGE yet:
>
> http://sage.math.washington.edu/home/jbmohler/patches/
> ring_element_addition.patch
I will give it a try.
>
> On Saturday 14 October 2006 19:24, David Harvey wrote:
>> On Oct 13, 2006, at 6:43 PM, Martin Albrecht wrote:
>>> Thoughts?
>>
>> (1) I assume you're using omalloc as a drop-in replacement for
>> malloc, i.e. just substituting malloc/free/realloc or something like
>> that. Does omalloc have a more sophisticated interface though?
>
> It looks like that -- much stuff in omalloc.h -- but it doesn't
> seem to be
> extensively documented (at least there is no bird-eye's-view). What
> would
> your sophisticated interface look like - in a perfect world?
I have no idea. I don't know anything about memory management. This
project is the first time I've thought about it in any detail :-)
David