> -----Original Message-----
> From: compsci-bounces@???
> [mailto:compsci-bounces@???] On Behalf Of Andy Sy
> Sent: Monday, May 12, 2008 4:53 AM
> To: True Computer Science Mailing List
> Subject: On GC being "slow and non-deterministic"
>
> Here's an insightful quote on GC from the D Programming
> Language (which incidentally, is shaping up to be a *REALLY*
> interesting language) FAQ. This is from
> http://www.digitalmars.com/d/2.0/faq.html#gc_1
>
>
> Q: Isn't garbage collection slow and non-deterministic?
>
> A: Yes, but all dynamic memory management is slow and
> non-deterministic, including malloc/free. If you talk to the
> people who actually do real time software, they don't use
> malloc/free precisely because they are not deterministic.
> They preallocate all data.
>
>
> A helpful reminder, that.
>
More to this actually, the GC only becomes a hindrance if you're running
in a VM where the VM controls when it runs or when it doesn't run and
even what it does. Consider for example interpreted languages like Lisp
and Haskell which also require a GC in runtime *when in an interpreter*;
and also consider the advanced static analysis that compilers for these
languages are able to do when compiling to machine code.
I think the lesson here is that the compilers of languages like Lisp and
Haskell that rely on a GC being present during runtime will have to do
as much as it can to avoid embedding a garbage collector during runtime
and just implement this in the traditional deterministic do it yourself
memory management schemes. So yes, GC's are slow and generally
non-deterministic, that's why people who care about performance *try* to
avoid them at all cost.
--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmberris@???>
+639287291459
______________________________________________________
True Computer Science Mailing List
compsci@??? (#CompSci @ irc.free.net.ph)
http://lists.free.net.ph/mailman/listinfo/compsci
Searchable Archives: http://archives.free.net.ph
