[bitc-dev] Pools in lieu of GC
Jonathan S. Shapiro
shap at eros-os.com
Wed Mar 4 22:37:17 EST 2009
On Wed, Mar 4, 2009 at 9:56 PM, Rick R <rick.richardson at gmail.com> wrote:
> 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.
This has been historically typical, but it is a misleading analysis.
The reason for the 2x overhead is that the underlying OS does not
provide support. The non-current generation does not need to be backed
by real memory most of the time, so that real memory overhead can, in
principle, be shared across a large number of programs. Current
implementations don't tend to do that.
> 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)
Hmm. Tried to go look at it. Either the site is temporarily down or
it's dead. Do you know which?
shap
More information about the bitc-dev
mailing list