Subject: Re: Theory #51 (superior(?) programming languages) From: Erik Naggum <erik@naggum.no> Date: 1997/01/28 Newsgroups: comp.arch,comp.lang.lisp,comp.lang.scheme Message-ID: <3063405313554753@naggum.no> * 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. #\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.