On Wednesday 26 March 2008, Gary Furnish wrote: > Trac #2436 adds the following algorithms from glib to libcsage: > Multiplatform threads > Thread pools > Asynchronous Queues > Memory Slices > Doubly and Singly linked lists > Queues > Sequences > Hash Tables > Arrays > Balanced Binary Trees > N-ary Trees > Quarks
I am all for that, so +1. > In particular it features a slab memory allocator based on: > http://citeseer.ist.psu.edu/bonwick94slab.html > http://citeseer.ist.psu.edu/bonwick01magazines.html > The documentation for glib is found at > http://library.gnome.org/devel/glib/2.14/glib-Memory-Slices.html The files > are all GPL 2.0 or greater. Although glib normally has > extensive dependencies, all of them have been removed, as have parts > of glib that are not strictly algorithms (such as string parsing). To > avoid autoconf/make troubles, the new parallel build system currently > in experimental testing features a simple, elegant python autoconf > replacement. The extra build time for libcsage is minimal, and wall > time often decreases due to the new parallel build system. Finally, > until testing is complete, parallel build and glib are orthogonal and > can exist in parallel to all existing Sage code, making review > significantly easier. > Right now there are no easy to use C libraries included with sage. > Using c++ stl requires extremely painful Cython wrapping. Therefore > everywhere pure performance is needed, ad hoc solutions are often used > (see integer.pyx, etc), which often introduce subtle and painful > bugs. This was already discussed at http://groups.google.com/group/sage-devel/browse_thread/thread/a25146f45a5c6b97/3e996f8485802a01 and IMHO the outcome was that it is unclear whether GLIB can improve the integer.pyx experience. There is a reason integer.pyx looks like it does (avoiding going up the inheritance tree etc.). > Furthermore there are many places in Sage that could benefit > from a unified slab allocator (as opposed to a pool which can only > grow). Sage already ships several Slab allocators: PyMem_Malloc, OMalloc, Givaro's slab allocator etc. Sure Sage could use those more but adding another slab allocator won't help, unless: - it is easier to debug, develop with, enable/disable, etc and/or - it offers better performance. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
