+1 --Mike
On Tue, Mar 25, 2008 at 7:15 PM, <[EMAIL PROTECTED]> wrote: > > > > > 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 -~----------~----~----~----~------~----~------~--~---
