On Oct 27, 3:27 am, Burcin Erocal <bur...@erocal.org> wrote: > I don't think we can use omalloc in Sage since it is not thread safe. > Using GMP with two different memory allocators is not an option either. > So I am not sure if this problem can be solved easily.
A similar issue arises in ECL. By default, it plugs Boehm's malloc replacements into GMP. This of course doesn't work at all with Sage. As it turns out, the setup for arithmetic in ECL meant that most arithmetic gets stored into a "register" location first and gets copied into appropriate lisp data structures afterward. It is not a big disaster when the registers are not under Boehm's control, so ECL now has an option that allows it to run with GMP using a memory manager different from the one used by ECL. ECL only reluctantly reduces the size of these registers, so usually GMP calls result in no reallocation calls whatsoever. Only once the result is known is the lisp datastructure allocated and the GMP integer is copied into it (yes, the bitstrings representing GMP integers are location independent) If the size of the answer can be predicted beforehand, the use of a register can even be factored out: You just allocate enough space and call GMP with a destination pointing to that space. If the size of the answer is not known, then it is likely a good idea to first compute the result into a preallocated scratch register anyway and then allocate and copy, because saving a reallocate likely compensates a memcpy (especially because the scratch register will quickly gain a permanent spot in the cache!) So, depending on how libSingular's use of GMP is organized, it might be doable to let libSingular use omalloc and call GMP either with destinations that are guaranteed to not need reallocation or only with destinations that function as "registers" and can be managed by whatever allocator GMP uses (and preferably are only reallocated rarely). If omalloc's use is limited to libSingular, its thread-unsafeness is likely much less of an issue. Another point is of course the number of heaps that a typical sage session is starting to depend on! (PyMem_malloc, malloc, Boehm_malloc, omalloc, pari/gp's stack ...) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
