Hi sage-devel, 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 :-). 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? Cheers, gsw --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
