[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: following up on speed

On Sat, Jul 20, 2002 at 03:02:52AM -0400, Daniel Weinreb wrote:
> Michael Vanier wrote:
> >
> >Hmm, I think I wasn't being clear enough.  What I meant is that in C, there
> >is a tendency to use arrays and structs (however deeply nested) for all
> >data structures (I've worked on several large projects where this was the
> >case), whereas a lot of fairly simple data structures that one might find
> >in any textbook (linked lists, doubly-linked lists, trees, priority queues,
> >etc. etc.) are avoided because of the memory management headaches that
> >would arise.  In contrast, in languages like (say) ML, it's so trivial to
> >write this kind of data structure that it's almost automatic.
> >
> Well, when you contrast languages "like C" against those "like ML", you 
> are not necessarily
> comparing "malloc/free languages" against "GC languages".  Maybe you're 
> really comparing
> "no standard library" languages to "standard library" languages.  In 
> modern C++ with STL,
> all that stuff is pretty easy to do, too.

Are you saying that the STL obviates the need for GC?  I'm not an STL
expert, so perhaps you can enlighten me.  Say I need to implement a
data structure for an abstract syntax tree.  What does the STL provide
that automatically manages the memory of that data structure?

> At MIT, we were taught to think about semantics and abstraction much 
> more than we were taught
> to think about performance. There is a real danger in taking this 
> approach too far.

How far is "too far", and what is this "real danger" you speak of?

In my experience, I've seen exactly the opposite -- that students have
to worry so much about bit-level performance that they can't grasp
even simple abstractions.