Re: following up on speed

[Daniel Weinreb <address@hidden>]

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.

>
>
>As for your other point about programmers spending as much time tuning the
>GC as they do fixing pointer bugs in languages without GC, that may be the
>case, but at least in the former case the program works before the tuning
>starts. 
>
Yes, that's a really, really big difference!

>
>Parenthetically, I gather that one trick lisp programmers use a lot is to
>rewrite code to minimize allocations (consing), but that this is typically
>done as an optimization after the code is working.  Maybe some of the lisp
>gurus on the list can comment further on this.
>
It depends on the age of the Lisp guru.  Being a gray-haired type 
myself, I was trained by Richard
Greenblatt in the 70's that "consing is bad".  Fortunately I quickly 
realigned myself to be a trainee
of Dave Moon instead, who taught me more nuanced ways to reason about 
this. But certainly when
I was writing a Chaosnet NCP (think "TCP/IP implementation" but with a 
simpler protocol) in Lisp, I
was minimizing consing right from the get-go.

>
>
>However, I agree with you that it's often more difficult to understand the
>exact execution model in languages with GC (or any high level language for
>that matter) than it is with C.  I think this is a large part of the
>attraction of C for many programmers; no matter how hard it is to get
>things working, you know that (in theory) you can understand how everything
>works right down to the machine level if you need to, something which is
>pretty hard to do in most high-level languages.  That's the price you pay.
>
(Although, as was just very recently pointed out, lots of C/C++ 
programmers are not entirely
sophisticated about the performance implications of "malloc" and "free"!)

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.

Those of you on this list who regularly initiate undergraduates into the 
mysteries of Scheme:
do you teach them performance analysis? In the first semester?