Nick B Wrote: > Jeremie Pelletier wrote: > > Tom S Wrote: > > > >> Jeremie Pelletier wrote: > >>> Tom S Wrote: > >>> > >>>> Jeremie Pelletier wrote: > >>>>> I myself allocate all my meshes and textures directly on the GC and I'm > >>>>> pretty sure its faster than C's malloc and much safer. > >>>> Hm, why would it be faster with the GC than malloc? I'm pretty sure it's > >>>> the opposite :P Plus, I could use a specialized malloc implementation, > >>>> like TLSF. > >>> The D GC is already specialized, and given its being used quite a lot in > >>> D, there are good chances its already sitting in the CPU cache, its heap > >>> already having the available memory block waiting on a freelist, or if > >>> the alloc is more than 0x1000 bytes, the pages available in a pool. You'd > >>> need to use malloc quite a lot to get the same optimal performance, and > >>> mixing the two would affect the performance of both. > >> It might be specialized for _something_, but it definitely isn't > >> real-time systems. I'd say with my use cases there's a very poor chance > >> the GC is sitting in the CPU cache since most of the time my memory is > >> preallocated and managed by specialized structures and/or malloc. I've > >> found that using the GC only for the hard-to-manually-manage objects > >> works best. The rest is handled by malloc and the GC has a very shallow > >> vision of the world thus its collection runs are very fast. Of course > >> there's a drawback that both the GC and malloc will have some pages > >> cached, wasting memory, but I don't let the GC touch too much so it > >> should be minimal. YMMV of course - all depends on the memory allocation > >> patterns of the application. > > > > I understand your points for using a separate memory manager, and I agree > > with you that having less active allocations make for faster sweeps, no > > matter how little of them are scanned for pointers. However I just had an > > idea on how to implement generational collection on a non-moving GC which > > should solve your issues (and well, mines too) with the collector not being > > fast enough. I need to do some hacking on my custom GC first, but I believe > > it could give yet another performance boost. I'll add my memory manager to > > my list of code modules to make public :) > Jeremie > > If the code is really usefull, why not offer it to the Tango team, for > formal inclusion in the next release ? > > Nick B
Because I dropped support for D1 long ago. If either the Tango or Phobos team like my code once I publish it, they are free to adapt it for their runtime. I rewrote the GC from scratch and optimized over the past 2 years to support my custom D runtime. It cannot be used as-is with neither phobos or tango without either changing the public interface of the GC or rewriting every runtime routine calling into the GC. I would only release it to public domain as an example of how to implement a tracing generational non-moving GC. I still need to implement the generational part, but I got the general algorithm down on paper today so I should have it working sometime this week. I'm not a big fan of code licenses and therefore like to write most of my code myself, if only to learn how it works. I rarely mind people asking for my code either, so long as I get credited for it :)
