On Tue, May 13, 2008 at 6:14 PM, Rafael Sevilla <dido@???> wrote:
> On Tue, 13 May 2008 13:40:31 +0800
> "Dean Michael Berris" <mikhailberis@???> wrote:
> > In Lisp and Haskell, you run into the GC if you're running it in an
> > interpreter -- because the code is executed in an environment which
> > relies on a garbage collector. But when you compile the code into
> > machine code, *you don't have a GC because the compiler already has
> > performed static analysis on the lifetime(s) of the data you're
> > dealing with*.
> >
>
> This is preposterously untrue, and I have no idea where you got this
> notion. There is a garbage collector embedded into the run-time library
> and compiled code generated by the Glasgow Haskell Compiler [1], Ocaml,
> and Chicken Scheme (which uses the Cheney algorithm on an Appel
> trampoline). I know of no compiler system for any language, functional
> or otherwise, that relies solely on static analysis for memory
> management, as all known heuristics for doing this leave behind far too
> much garbage to be useful.
>
> [1] http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes
>
If you actually go to the GHC site, you will find that GHC *does*
static analysis in the form of Strictness Analysis:
from
http://haskell.org/haskellwiki/Performance/Strictness :
...
Optimising compilers like GHC try to reduce the cost of laziness using
strictness analysis, which attempts to determine which function
arguments are always evaluated by the function, and hence can be
evaluated by the caller instead. Sometimes this leads to bigger gains;
a strict Int can be passed as an unboxed value, for example.
Strictness analysis sometimes does wonderful things; for example it is
very good at optimising fac:
fac :: Int -> Int
fac n = if n <= 1 then 1 else n * fac (n-1)
Strictness analysis can spot the fact that the argument n is strict,
and can be represented unboxed. The resulting function won't use any
heap while it is running, as you'd expect.
...
So that's just one part of the optimizations that the GHC performs.
Perhaps my statement is lacking, and like as you have done taken out
of context will be false.
I should have side this instead, which is the whole intention (and
context) of the post:
But when you compile the code into machine code, *you don't have a GC
because the compiler already has performed static analysis on the
lifetime(s) of the data you're dealing with* _especially if you're
using an optimizing compiler in places where the heap can be avoided_.
So like the rest of the post suggests, in languages like Lisp and
Haskell _when compiled to machine code_, the compiler will have to try
as hard as it can to avoid using 1) the heap and eventually 2) the
garbage collector to mitigate the (unnecessary) performance hit that
the garbage collector does bring.
As far as relying solely on static analysis for memory management, I
didn't claim this. However, it was intentionally implied that static
analysis will allow you to determine which parts of the code can avoid
the heap, and which parts of the code when it does use the heap will
be requiring the data and up to when they will be requiring this data.
Of course, in cases where this would be impossible (I/O, randomly
generated data, etc.), then there is no other recourse but to rely on
a garbage collector to eventually collect the memory that can be
reclaimed. The Lisp compilers already do not only static analysis for
the sake of memory management but also static analysis for
source-level optimization -- and when compiled to machine code, most
(if not all) of locally utilized memory locations (in closures and
'let' symbols) are usually put on the stack instead of the heap.
It however doesn't refute that GC's are non-deterministic and are
generally a performance hit that you *can* live without and sometimes
may have to live with if the performance hit is not that critical.
--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://blog.cplusplus-soup.com]
[mikhailberis@???]
[+63 928 7291459]
[+1 408 4049523]
______________________________________________________
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
