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?
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
On 10/12/06, William Stein <wst...@gmail.com> wrote:
> 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?
On Fri, 13 Oct 2006 10:45:43 -0700, David Joyner <w...@usna.edu> wrote: > 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.
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).
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 = 452347234589346340563106532513050435764350139851345156435314507143598631486 59136951369851836545643565
sage: y = 234239645234623842342342348723456236456234523452835482346523654823485623465 23642348263486234954534554
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.
> 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).
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 = > 452347234589346340563106532513050435764350139851345156435314507143598631486 59136951369851836545643565
> sage: y = > 234239645234623842342342348723456236456234523452835482346523654823485623465 23642348263486234954534554
> 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.
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 <wst...@gmail.com> wrote:
> On Fri, 13 Oct 2006 15:43:47 -0700, Martin Albrecht > <m...@informatik.uni-bremen.de> 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).
> 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.)
> > sage: y = > > 234239645234623842342342348723456236456234523452835482346523654823485623465 23642348263486234954534554
> > 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.
On Sat, 14 Oct 2006 09:25:17 -0700, David Joyner <wdjoy...@gmail.com> wrote:
> 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?
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: singu...@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.
> On 10/14/06, William Stein <wst...@gmail.com> wrote:
>> On Fri, 13 Oct 2006 15:43:47 -0700, Martin Albrecht >> <m...@informatik.uni-bremen.de> 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).
>> 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.)
>> > 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.
On Saturday 14 October 2006 18:25, David Joyner wrote:
> 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?
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.
> 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.
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.
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?
(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:
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:
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? 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?
On Oct 14, 2006, at 1:50 PM, Martin Albrecht wrote:
> 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 :-)
|
