On Feb 22, 2:19 pm, "Georg S. Weber" <georgswe...@googlemail.com>
wrote:
> Hi sage-devel,
Hi,
> currently Sage uses, if possible, the system's malloc.
> This has a big advantage --- that strategy certainly is the one
> supporting portability of Sage best.
>
> I don't know if there is a timeline already for the use of customized
> "Sage malloc" versions for some (or all) systems Sage runs on.
>
> But one obstacle in the past has been that Singular/omalloc had
> hardcoded the use of its own copy (slightly adapted source code) of
> Doug Lea's dlmalloc v2.6.5 from 1998 (see
> e.g.http://en.wikipedia.org/wiki/Doug_Lea
> --- there is also a link to a code repository).
>
> The most recent dlmalloc has the version number v2.8.3, and there are
> interesting remarks in its history/comments since v2.6.5. Like "don't
> use sbrk on Macs"; and "modern Linux kernels may still be able to
> serve memory via mmap, even if sbrk fails to do so, so now do use mmap
> as a backup strategy".
>
> But up to now, if in Singular/omalloc one wanted to switch away from
> the default dlmalloc v2.6.5, one ran into a "double free" problem (at
> least under Mac OS X, and Cygwin). This even happens, if one plugs
> back in the "default" dlmalloc code! To my knowledge, Michael Abshoff
> was the first one to report this here in sage-devel, but I couldn't
> find an appropriate trac ticket. So I created #5344 for this.
>
> And there's now a patch waiting for review :-).
"Needs work" - it breaks 25 doctests on OSX by introducing segfaults.
See the comments I made on the ticket.
> Depending on this issue is the patch I uploaded to trac #4181 (the
> problem underlying at least trac #3760 also, and possibly #5278). It
> just kicks out the use of a proprietary malloc implementation from
> Singular/omalloc, and enforces to use the system's malloc instead.
>
> Of course, there might a price to pay --- the old (but lean) dlmalloc
> from 1998 probably is faster in certain instances and use cases.
>
> But this leads us immediately back to the question of a "Sage malloc",
> customized resp. customizable for specific purposes. And certainly not
> only Singular/omalloc, but without doubt all of Sage would benefit
> from a recent malloc implementation with good and easy-to-use
> tunability (e.g. for maximum speed) on current systems. Doug Lea's
> malloc 2.8.x series has a promising concept of "mspaces", one for each
> thread, to name an example.
>
> Personally, I don't have the time to do investigations, and to conduct
> the necessary benchmarks and tests. Any volunteers?
-1 - memory debugging is already hard enough. Do not throw in
*another* opaque allocator to make things even more complicated.
This would also require a significant speedup IMHO to be worth it and
will also require significant code changes in the library to make this
happen. We already can use pymalloc in a bunch of places and it is
very fast for small allocs. Large mallocs are handed to the C library
which on most systems just calls mmap, so I am skeptical we will see a
real speedup anyway.
And that also leaves us with porting and debugging problems.
And since there are no threads in Python code I fail to see the
advantage of the better performance under threading :)
> Cheers,
> gsw
Thanks for trying to fix this, to bad it didn't work :(
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
