[bitc-dev] Pools in lieu of GC
Rick R
rick.richardson at gmail.com
Wed Mar 4 21:56:04 EST 2009
It is certainly possible. The only time a garbage collector has to do any
work is when it is out of memory to hand out. Even malloc/free do work
behind the scenes, for some allocators, they can do quite a bit of work. The
GC allocator on the other hand could be handing out of a pre-allocated slab,
or just pulling memory from a fast malloc.
I have read about a generational garbage collector that operated approx. 20%
faster than hand coded memory over the lifetime of a non-trivial, real world
application. The downside is that it required 3x the available heap space of
the hand coded one. At 2x the available memory, it operated at approx. 90%
of the hand standard.
e7 Lisp was built explicitly for live sound processing applications and
mixers. It features an incremental red/gray/black GC suitable for "hard
realtime". To my knowledge it achieves that goal (it's written in C++, but
may be worth borrowing)
On Wed, Mar 4, 2009 at 9:22 PM, Pal-Kristian Engstad <
pal_engstad at naughtydog.com> wrote:
> Jonathan S. Shapiro wrote:
> > What people tend to forget is that GC is just as fast as hand allocation.
> >
> I wondered about this statement -- how can that be true? If we assume
> that the programmer did some careful analysis of the code, determining
> when memory can be reclaimed, how can that be as fast as having code
> (albeit with type information) that scans memory to see if it is still
> reachable? Mind you, I'm not arguing that it can be done with fairly low
> overhead, but there still must be some overhead? So can you try to
> substantiate that claim, Jonathan?
>
> PKE.
>
> --
> Pål-Kristian Engstad (engstad at naughtydog.com),
> Lead Graphics & Engine Programmer,
> Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
> Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.
>
> "Emacs would be a far better OS if it was shipped with
> a halfway-decent text editor." -- Slashdot, Dec 13. 2005.
>
>
>
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
--
We can't solve problems by using the same kind of thinking we used when we
created them.
- A. Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20090304/0c021d94/attachment-0001.html
More information about the bitc-dev
mailing list