Re: following up on speed

[Michael Vanier <address@hidden>]

> Date: Thu, 18 Jul 2002 08:03:50 -0400
> X-Authentication-Warning: everest.ascent.com: sundar set sender to sundar@everest using -f
> From: Sundar Narasimhan <sundar@ascent.com>
> Cc: ziggy@panix.com, DLWeinreb@attbi.com, ll1-discuss@ai.mit.edu
> 
> [Much good stuff about GC deleted].
> >OTOH the lack of GC discourages C
> >programmers from using anything other than trivial data structures; I'd
> >argue that this is a huge cost in terms of code complexity which dwarfs the
> >efficiency costs of GC.
> 
> Gee. Are we biased or what? In my experience when systems (with GC)
> get large enough (I'm not talking about academic programs here)
> Lisp/Scheme/Java programmers do spend a great deal of time looking at
> how allocation works/impacts their programs -- almost on par w/ how
> much time a C programmer might spend initially tuning allocations and
> perhaps later in debugging malloc/free issues perhaps. And indeed I've
> seen the exact opposite of what Michael is talking about -- most
> complex code I've seen wrt. data structures is still C and god forbid
> Fortran. This might mean more about what Math and Physics majors are
> taught than anything intrinsic about languages per se :)
> 

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.

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.  Given the choice, I'd much rather have a working program which
required extra effort in order to be reasonably efficient than to have to
kill myself to get the thing working in the first place.  For one thing,
this lets you do more experimentation on algorithms before you have to
"freeze" the design.

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.

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.

It would be really cool if a high-level language was built on top of a
lower-level version of itself which allowed unsafe operations, and if the
debugging tools let you drop down into this lower level when needed.  I
believe scm48 did this with pre-scheme, but I'm not aware of any other
examples (unless you count Modula-3 and C#'s "unsafe modules").

Mike