Subject: Re: Theory #51 (superior(?) programming languages)
From: Erik Naggum <>
Date: 1997/01/28
Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme
Message-ID: <>

* Steven Huang
| Question:  Do you recompile, assemble, and link your C executable every
| time you need to run it?

of course not.

| Question:  Do you need to load your Lisp program every time you run it?
| (How often is it already in memory?)

of course not.

| An accurate benchmark must first simulate the usual working environment,

sigh.  what were we measuring?  were we measuring the time from we put the
phone down after ordering a brand new computer all the way through getting
the number of combinations on a lotto coupon, or were we measuring how fast
a single function ran?  I was measuring the latter.  I think this goes
beyond the bloody obvious.

| I am not familiar with the usual Lisp environment, so that part is up to
| you.

depends on your needs.  if it the function always needed in your Lisp
programs, you link the Lisp image with it (in case of a .o file), or you
dump a new lisp image with it (in case of a Lisp function).  if it is not
very frequently used, but often enough that you want to have it available,
you could autoload it or load a stub function.  if it is rarely necessary,
you typically load the .o or compiled Lisp function before you start using
it.  in either case, it is in memory when you call it, and it will stay in
memory.  you also typically have a Lisp running throughout your whole
session, just like X or xterm or the shell or Emacs.  not all applications
under Unix are as ephemeral as say, an `ls' command.

there is no theoretical upper limit to how much time must have elapsed
before you can determine that some process has started (except for the
beginning of time, which we don't know how far back is).  if I say that I
include the time it took to load a file from disk, you could argue that the
disk needs to reach its calibrated spin speed, which could be a significant
number of seconds.  it gets sillier and sillier, of course, but if you
don't want to limit the timing to the smallest possible timable event, you
will never, and I mean _never_ in the absolute sense, get two people to
agree on _any_ timing statistics.  which I assume is _your_ point.  mine
was trying to show a useful correspondence between compiled code in two
languages.  I repeat myself, but please go away.

1,3,7-trimethylxanthine -- a basic ingredient in quality software.