Douglas Roberts wrote:
I believe that under optimal conditions (from the perspective of the
garbage collecting language) a benchmark can be contrived that equals
malloc.
If a person can plan out a workset that is minimal and needed all of the
time, then it won't need to be moved around independent of whether
malloc or GC is used. It can just be declared in fixed array on the
heap and that is that. Typically people that care about fast code plan
out the use of memory in a careful way, and also use a language that
generates code they can inspect and understand the generated machine
language to be efficient. That's typically C or C++ or Fortran.
A person prototyping code for a new problem doesn't yet have whole thing
in their head, so they don't want to commit to decisions like global
sharing of data. malloc/free is undesirable in that situation because
it just adds one more thing to keep track of.
Once they do have the whole problem understood (with the help of some
exploratory programming), there's nothing stopping them from making a
new production code that is fast. This has nothing to do with GC vs.
malloc though. It's just a question of whether it is cheaper to throw
more computers at it than it is to do some factoring and profiling or do
a new implementation.
There surely a class of problems where an implementation plan is evident
before any code is written and there's a clear lifetime for certain
blocks of data. This would be a case where malloc/free would probably
win. I'd also expect it has a substantial overlap with the class of
Boring Problems.
Marcus
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
