Firstly, the language comparison is with C++, Java and SML as well, all of
which have multiple implementations. Indeed, two implementations of SML are
already on the language comparison. Secondly, of the languages you listed,
at least Perl and Python have multiple implementations. Finally, the number
of implementations is irrelevant.

I'll have a look at Lispworks...

When I was younger (now I am 31) I also believed benchmarking is a
must. However, in the meantime it is even this: if your ray-tracer in
OCaml were 100000 times faster than the Bigloo-Scheme version I would
not opt for OCaml quickly. Perfromance is important, no question, but
in a code project it is a rather tiny part.

I agree that in most problem domains, constant time speed factors are
pretty much irrelevant for 95% of code, and we should be very skeptical
about judging "language speed" by simple benchmarks like this, because
an easier to program language, often leads to better algorithms, as well
as a lot less programming time (and less downside variation in program
speed -- cf: Erann's lisp-java-c experiment: the fastest C programs just
beat the fastest lisp programs, but many of the C programs were *much*
slower than the slowest lisp programs).    

But those tradeoffs aren't the same for all problem domains.  In those
rare problem domains where there's always lots time to optimize relative
to the runtime available, bare speed matters.

The problem is that it's still hard to tell the difference between a
faster language and better writers of optimized code, as the almabench
thread demonstrates.  How much time do you spend on optimization before
you abandon the project and say "It's easier to make this fast in X".
And obviously some things will be easier to optimize in language Y than
others.  All this makes any given benchmark or set of benchmarks suspect
as an absolute measure of speed, but it doesn't completely invalidate
their potential usefulness, as long as one understands what they mean
and what they do not mean.

However, LOC overly penalises Lisp and Scheme, IMHO. Specifically, Lisp and
Scheme programs are virtually unreadable unless the parentheses are
staggered by spreading expressions over several lines and using an
automatic indenter. So if I were to put a Lisp implementation of the ray
tracer on my site then I'd either state that, or I'd give results using
some other measure of verbosity, like characters. I do think Lisp deserves
to be somewhat penalised in this way, but LOC goes too far.

In contrast, my ray tracer involves integer and floating point arithmetic,
3D vectors, trees, tagged unions, recursion/iteration, naturally functional
(e.g. vector ops and ray_sphere) and imperative (e.g. for loops) style. So
it tests quite a lot using very little code and it is fun to play with.
This diversity also makes the collection of ray tracers a better
educational tool - people can glance at the code and see how different
things are implemented in different languages.

token count probably would be better

; Jon Harrops little raytracer
; With bits from Jan Van Lint's version and Nathan Baum's version
; Currently not working

(defconstant delta (sqrt long-float-epsilon))
(defconstant infinity most-positive-long-float)

(defun v* (s r) (map 'simple-vector #'(lambda (x) (* s x)) r))
(defun v+ (a b) (map 'simple-vector #'+ a b))
(defun v- (a b) (map 'simple-vector #'- a b))
(defun dot (a b) (apply #'+ (map 'list #'* a b)))
(defun unitise (r) (v* (/ (sqrt (dot r r))) r))

(defstruct ray orig dir)
(defstruct sphere center rad)
(defstruct group sphere scenes)

(defun ray-sphere (ray sph)
  (let* (t1 t2
         (v (v- (sphere-center sph) (ray-orig ray)))
         (b (dot v (ray-dir ray)))
         (disc (+ (- (* b b) (dot v v)) (expt (sphere-rad sph) 2))))
    (if (minusp disc) infinity
      (progn (setq disc (sqrt disc))
             (if (minusp (setq t2 (+ b disc))) infinity
               (progn (setq t1 (- b disc))
                      (if (plusp t1) t1 t2)))))))

(defun intersect (ray scene)
  (labels
   ((lp (hit scene) ; car hit is a lam, cdr a simple-vector normal
        (if (sphere-p scene)
            (let ((lam (ray-sphere ray scene)))
              (if (>= lam (car hit)) hit
                (cons lam (unitise
                           (v- (v+ (ray-orig ray) (v* lam (ray-dir ray)))
                               (sphere-center scene))))))
          (if (group-p scene)
              (if (>= (ray-sphere ray (group-sphere scene)) (car hit)) hit
                (reduce #'lp (group-scenes scene) :initial-value hit))
            (error "not a group or sphere in intersect")))))
   (lp (cons infinity #(0.0 0.0 0.0)) scene)))

(defun ray-trace (light ray scene)
  (let* ((hit (intersect ray scene))
         (lam (car hit))
         (normal (cdr hit)))
    (if (= lam infinity) 0.0
      (let (g (dot normal light))
       (if (plusp g) 0.0
         (let ((p (v+ (v+ (ray-orig ray) (v* lam (ray-dir ray)))
                      (v* delta normal))))
          (if (< (car (intersect (make-ray :orig p :dir (v* -1.0 light))
                                 scene)) infinity) 0.0 (- g))))))))

(defun create (n c r)
  (let ((obj (make-sphere :center c :rad r)))
    (if (= n 1) obj
      (let ((rt (* 3.0 (/ r (sqrt 12.0)))))
        (labels ((aux (x z) (create (1- n) (v+ c (vector x rt z)) (* 0.5 r))))
          (make-group :sphere (make-sphere :center c :rad (* 3.0 r))
                      :scenes (list obj (aux (- rt) (- rt)) (aux rt (- rt))
                                    (aux (- rt) rt) (aux rt rt))))))))

Hmm.  What would you (JH) be measuring here?

a) Keystrokes required to produce the code (see below, though)
b) Some kind of 'intrinsic verbosity', which would require some *serious*
thinking about idiomaticity, relevance of formatting and massive, massive
sampling to make it statistically relevant.

Oh, and all the ')))))' you see probably didn't get typed by hand (
<META-RET> closes all open parens).