Re: Low-level vs. High-level programming (was My First Computer)

[mjmahon@aol.com (Michael J. Mahon)]

Kevin Lawton wrote:

>White Flame (aka David Holz) <whiteflame52@y.a.h.o.o.com> wrote:
>| "Kevin Lawton" <kepla@btinternet.com> wrote in message
>| news:bcplc6$b5e$4@titan.btinternet.com...
<snip>
>| 2)  Are you as proficient in what speed-conscious decisions must be
>| made in Java to keep it fast as you are with keeping C code fast?
>
>Maybe, maybe not. I've done the Sun Java certification course which only
>made slight mention of performance issues. If there are any techniques you'd
>like to point out which can make a 10-fold or even 100-fold difference, then
>I'd be interested to know. I wouldn't have thought the term 'keep it fast'
>was as appropriate to Java as maybe 'prevent it running terribly slowly'.

Yes, it seems that the "higher level" the programmer, the less
conscious they are of performance issues in general and machine
behavior in particular.

More than twenty years ago, when I was deep in performance
analysis of real applications for a RISC design effort, I talked with
some AI wizards about Lisp performance.  We thought that such
applications might become a significant application load on a
machine in the next decade or so, and wanted to be sure that
the processor architecture gave appropriate consideration to the
frequently occurring operations in Lisp programs.

The conversation was somewhat disappointing, since it went
something like:

Q:  "What operations of Lisp programs are most important to
performance?"

A:  "What do you mean?"

I was astonished that the finest Lisp programmers had virtually
no idea what the computer was doing when it executed their
code.  Later, I discovered that this is a pattern:  the more that
programmers are "insulated" from machine realities by their
language, the less conscious of those realities they are.

A ridiculous example of this I recall was a case of a (fresh)
OS programmer writing a timer interrupt routine (which would
be invoked as many as thousands of times per second) keeping
"time to next interrupt" in seconds instead of machine cycles,
and doing a _double-precision (64-bit) integer divide_ on each
interrupt to get the value to set the "next interrupt" register!

In the Pascal variant being used, the double-precision integer
divide was invoked simply by using "/" in an expression with
variables declared "long int", so the programmer was not
inconvenienced by this onerous task.  ;-)

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/