On 19.06.2006 18:49, Peter Amstutz wrote: > For what it is worth, I believe that ptmalloc() has been the standard > allocator for glibc on Linux for quite a while > (http://www.malloc.de/en/index.html), so it doesn't really make sense to > have CS provide its own allocator there (and indeed might even be > counterproductive by interfering with other debugging tools).
Though, the glibc allocator is ptmalloc2, the CS one is ptmalloc3. (According to the 2nd chart of the right side of http://www.nedprod.com/programs/portable/nedmalloc/index.html, ptmalloc3 is a good deal quicker than ptmalloc2). If it interferes with utilities, use of ptmalloc can be disabled via configure. > The Windows memory allocator is terrible, so that will be a welcome > performance improvement. Absolutely. > Incidentally, for multithreaded/multiprocessor applications the Hoard > allocator (http://www.cs.umass.edu/~emery/hoard/) is supposed to be > superior by employing strategies to avoid lock contention of the heap > between CPUs. This is probably not necessary for the mostly > single-threaded CS, though. ptmalloc3 also does stuff like using different heaps for different threads to make it faster in concurrent situations. I can't really say how it compares with Hoard technically, but I would as well think that for CS' it's more than sufficient. (Also, since we try to avoid doing lots of alloc/deallocs during a frame anyway, the allocator speed is mostly relevant to level loading.) -f.r.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
