On Tue, 25 Mar 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
+1, I can use this to speed up the polynomial evaluation code.
>
> 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. Furthermore there are many places in Sage that could benefit
> from a unified slab allocator (as opposed to a pool which can only
> grow). Finally the extensive symbolics modifications I am working on
> make use of glib (especially trees and lists) to enable very fast
> symbolic manipulations. By using glib algorithms I avoid having to
> roll my own code that would require extensive manual review and
> debugging. This code drop is big enough that Mabshoff would like a
> formal +1 vote, and I'd be happy to address any concerns.
>
> Mar 25 00:00:13 <mabshoff> yes. It isn't an spkg, but the code drop is
> large enought to warrent a vote.
> Mar 25 00:00:21 <mabshoff> You can quote me on that.
> Mar 25 00:00:35 <mabshoff> You should say *why* it is a good idea and
> *what* goodies it does provide.
> Mar 25 00:00:59 <mabshoff> Since it will only become useful after the
> switch to pbuild and doesn't
> Mar 25 00:01:21 <mabshoff> harm anything with the old build it also
> doesn't have an impact on the current
> Mar 25 00:01:24 <mabshoff> codebase.
> Mar 25 00:01:31 <mabshoff> You can quote me on that, too.
>
> --Gary
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
