[MUD-Dev] New Beginings

[David B. Held]

From: "Bruce Mitchener" <bruce at cubik.org>

> Really, as has already been said in some previous replies, it
> comes down to knowing your toolset, knowing what it is good at,
> and what its weaknesses are.  There is no silver bullet and no
> perfect solution for managing memory.  But GC surely isn't the
> curse that you seem to think that it is. :)

Well, calling it a "crutch" was a bit strong, but what I tend to
dislike about GC is the fact that object lifetime is more than an
optimization detail when it comes to programming.  The problem of
properly handling finalization in all cases just highlights this.
GC allows coders to write code without explicitly thinking about
object lifetime, and I don't think this is necessarily a good thing.
There are surely cases where you are limited in what you can say
about lifetime, and in those cases, a collector may be the most
appropriate solution.  But there are also many cases where a trivial
analysis will discover the appropriate lifetime, and the best
management strategy can be selected manually, and will do better
than a collector.

> Collectors need not be inefficient and even may be faster or
> product better runtime results than manually invoking free().

Yes, I've heard the "GC can be faster than manual allocation"
argument before, and would like to point out that there are always
caveats.  Yes, you can write an efficient collector for a given set
of use cases.  Yes, you can use malloc() in a way that is
inefficient.  Yes, malloc() itself may be intrinsically slow.  My
main gripe is that in C++, you have *choice*.  In a language with
intrinsic GC, you do not.  You can cheat the GC by caching your
objects, but then you are doing extra work to circumvent the memory
manager.  In C++, you need not do any such "cheating".  So when
someone says that C++ isn't as advanced as their favorite GC
language, I simply like to point out that GC has its benefits *and*
its weaknesses.  And that if you really prefer GC, or happen to
think it is the best solution for a given problem, you can still opt
to use it in C++.  But if you happen to think that a non-GC solution
is appropriate, you can't implement that natively in most GC
languages.

> (There are dangers with putting everything or a lot of stuff on
> the stack as well rather than the heap.  Not all machines/OSes
> support really large stacks.)

I don't advocate abusing the stack just to beat a collector.

> Incremental collectors can have a time limit imposed on them to
> prevent them from exceeding a given amount of time to avoid
> halting your process.  Generational collectors are another good
> thing.

And if that's what you prefer to use, go right ahead.  Even do so in
C++ if you like.  But don't tell anyone to avoid C++ because it's
not a GC language.

> Naive usage of malloc/free or new/delete can also cause large
> performance issues. (Brad Roberts has eeked out some pretty
> amazing performance improvements in parts of the Cold server by
> restructuring code to avoid a lot of allocation/deallocation that
> wasn't useful.)

Yes, I agree that there are numerous ways to shoot yourself in the
foot with C/C++.  However, the state of the art is improving, and
many libraries exist to assist even the novice programmer in writing
robust, efficient code.  For instance, the Boost libraries provide
both pool allocators and smart pointers for memory management.
Judicious use of each can make even naive code very efficient, with
a minimal addition of labor.

Dave


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev