I've just done a little benchmarking of the ray tracer written in Scheme and
compiled using Stalin. Here are the results. On x86 (900MHz Athlon T-bird):

$ g++ -O3 -march=athlon-tbird -ffast-math ray.cpp -o ray
$ time ./ray 6 160 >image.pgm
real    0m2.152s

$ mlton ray.sml
$ time ./ray 6 160 >image.pgm
real    0m2.435s

$ ocamlopt -inline 100 -ffast-math ray.ml -o ray
$ time ./ray 6 160 >image.pgm
real    0m3.255s

$ stalin -d0 -d1 -d5 -d6 -On -q -d -architecture IA32-align-double
-no-clone-size-limit -split-even-if-no-widening -copt -O2 -copt
-fomit-frame-pointer -copt -malign-double ray
$ time ./ray 6 160 >image.pgm
real    0m3.712s

On AMD64 (1.8GHz Athlon64):

$ g++ -O3 -march=athlon-tbird -ffast-math ray.cpp -o ray
$ time ./ray 6 160 >image.pgm
real    0m0.987s

$ mlton ray.sml
$ time ./ray 6 160 >image.pgm
real    0m1.056s

$ ocamlopt -inline 100 -ffast-math ray.ml -o ray
$ time ./ray 6 160 >image.pgm
real    0m1.037s

$ stalin -d0 -d1 -d5 -d6 -On -q -d -architecture IA32-align-double
-no-clone-size-limit -split-even-if-no-widening -copt -O2 -copt
-fomit-frame-pointer -copt -malign-double ray
$ time ./ray 6 160 >image.pgm
real    0m1.773s

I hadn't expected a simple Lisp or Scheme implementation to be able to
compete in terms of performance but only 70% slower on 32-bit AMD64 when
C++ and OCaml are fully 64-bit is very impressive, IMHO.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Calling Stalin a "simple" implementation has to be /the/ understatement
of the year!

There are things I don't like about Stalin (related mostly to its
"static" nature and skimpy error handling), but raw speed is one
thing it's terribly good at.  A *LOT* of work has gone into the
Stalin compiler to make it compile code that runs fast.  It is not
an example of a "simple" implementation.

                                Bear

Ooops! Sorry, I didn't mean to say "simple" there at all. Honestly, I wonder
who typed that... ;-)

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

As a Lisp/Scheme virgin, I'm finding Stalin much easier going than the other
compilers I've tried (Bigloo, SBCL, CMUCL). Bigloo in particular has the
worst error reporting I've ever seen...

Ahem. Yes, sorry about that.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

{stuff deleted}

Stalin is a very sophsticated implementation that uses whole program
compilation algorithms. It's very much like MLton. Chicken Scheme is
what I'd call a "simple" implementation.

Its a shame theres so much difference. Would be interesting
to see what results cmucl or sbcl gives. Have you posted a
request to comp.lang.lisp?

Anyway, perhaps you could try the following options for stalin? I got
better results with these:

   -d0 -d1 -d5 -d6 -On -k -Ob -Om -Or -Ot -q -d -architecture
IA32-align-double -no-clone-size-limit -split-even-if-no-widening -copt
-O3 -copt -fomit-frame-pointer
-copt -malign-double -copt -ffast-math -copt -freg-struct-return

--

It is also worth noting the Stalin code has no type declarations.

--
Jens Axel Søgaard

Well, it uses "vec" and "list" but I'm not sure what you'd call a type
declaration.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

I just remembered what I meant when I wrote that: "I hadn't expected a
simple implementation of the ray tracer written in Lisp or Scheme to be
able to compete in terms of performance...".

In other words, I was expecting fast Lisp/Scheme implementations of the ray
tracer to be obfuscated compared to the other languages but that doesn't
seem to be the case.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Which Scheme version did you use? Is it the same as the one you used
under Bigloo (except for the +fl, etc. operators).

Schneewittchen

There is one bug which hit me: Stalin takes a rather, rather long time
for compiling. Maybe this issue has changed in the meantime. I once
used Stalin on my old laptop under SuSE Linux 8.0 and every program
took at least 33 seconds when compiling. That was rather tedious; at
least for smaller programs.

Schneewittchen

It depends. There are three stages: bigloo -i, bigloo, and bigloo
-Obench. And all will give you different error messages. And there is
also the debugger in Bee. Okay, I cannot say much to the debugger since
I haven't used it much.

Do you think that OCaml its error messages are better? The problem
often in functional codes: ther error itself is often not related to
the place where it occurs.

Stalin is indeed an outstanding unsurpassed project. However, do you
really want to use Stalin in a professional environment? Bigloo its
manpower is as tiny
as Stalin its one. However, Bigloo has a much better presentation
home-page-wise, documenation, support, etc.

Schneewittchen
PS: Just out of curiosity: could you post your obersvation on
comp.lang.lisp that your made the experience that CMUCL has a rather
weak error message reporting facility. I do not like Common Lisp but I
always thought there exists some rather strong tools for debugging
code.

What version of Stalin are you guys using?

I've tried using Stalin 0.10alpha2, with little luck.  It can compile
simple things like "hello.sc" and "xhello.sc", but apart from that it
can't compile anything, even it's own benchmarks.

Nothing works if I start specifying C compiler optimization flags.

I'll check those out, thanks.

Vastly better, yes. Stalin second, g++ third, then MLton and SML/NJ and
finally Bigloo. That may well be because I'm not invoking Bigloo properly
though...

Yes. I am very impressed with Stalin.

It isn't the error messages from CMUCL and SBCL that give me a headache so
much as all the extra work required to get reasonable performance. AFAIK,
there is no theoretical reason why the Lisp compilers can't do the type
inference, static type checking optimisations that Stalin does (and SML/NJ,
MLton, OCaml etc.).

They do emit warnings telling the programmer where the type problems are but
that is no substitute for having the compiler do the work for you.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

I'm using the Stalin from Debian testing, which identifies itself as 0.10.

Weird. I think that is exactly the same version that I'm using. The package
is "0.9+0.10alpha", whatever that means.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Which Scheme version of ray are you compiling with Stalin?
Is it the version that I posted? If not, you can get much faster
results with Stalin as per my earlier post.

I'm using the version that you posted. Who are you, BTW?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Are you sure you want to compare run times which differ in amounts
of under one second?

Greetings,
        -- Jorgen

--
((email . "for...@forcix.cx") (www . "http://www.forcix.cx/")
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))

I wrote Stalin.

Please send me the exact code that you ran. I believe that I can make
it considerably faster. It appears that you modified the code that I
posted to take command line arguments. If one is not careful, this
could slow things down considerably.

Jon: Is it possible to post it here? Please!

Schneewittchen

Sure. Here's the code and some new (longer) timings:

Here are the compile lines I used on x86:

ocamlopt -inline 100 -ffast-math ray.ml -o ray
g++ -O3 -march=athlon-tbird -ffast-math ray.cpp -o ray
mlton ray.sml
javac ray.java
stalin -d0 -d1 -d5 -d6 -On -q -d -architecture IA32-align-double
-no-clone-size-limit -split-even-if-no-widening -copt -O2 -copt
-fomit-frame-pointer -copt -malign-double qobi

Running times for level=9, n=512 and ss=4 on 900MHz Athlon T-bird:

46.181s OCaml
33.086s C++ (gcc)
35.298s SML (MLton)
147.242s Java (Sun JDK 1.5)
73.976s Scheme (Stalin)

Compile times:

0.349s OCaml
5.205s C++ (gcc)
17.093s SML (MLton)
7.361s Java (Sun JDK 1.5)
94.647s Scheme (Stalin)

Here are the compile lines I used on AMD64:

ocamlopt -inline 100 ray.ml -o ray
g++ -O3 ray.cpp -o ray
mlton ray.sml
javac ray.java
stalin -d0 -d1 -d5 -d6 -On -q -d -architecture IA32-align-double
-no-clone-size-limit -split-even-if-no-widening -copt -O2 -copt
-fomit-frame-pointer -copt -malign-double qobi
(load (compile-file "nathan.lisp"))

Running times for level=9, n=512 and ss=4 on 1.8GHz Athlon64:

12.154s OCaml
12.226s C++ (gcc)
12.407s SML (MLton)
21.616s Java (Sun JDK 1.5)
26.867s Scheme (Stalin)
56.366s Lisp (SBCL)

MLton, Stalin and SBCL are run from 32-bit mode. All others from 64-bit
mode.

Compile times:

1.378s OCaml
2.279s C++ (gcc)
7.786s SML (MLton)
2.650s Java (Sun JDK 1.5)
94.647s Scheme (Stalin)
0.445s Lisp (SBCL)

Here's the Stalin implementation "qobi.sc" that I used:

(define-structure point x y z)

(define-structure obj c r objs)

(define-structure hit lam normal)

(define fail #f)

(define (fold-right f i l)
 (if (null? l) i (f (car l) (fold-right f i (cdr l)))))

(define infinity (/ 1.0 0.0))

(define epsilon 1e-15)

(define (s*v s b)
 (make-point (* s (point-x b)) (* s (point-y b)) (* s (point-z b))))

(define (v+v a b)
 (make-point (+ (point-x a) (point-x b))
             (+ (point-y a) (point-y b))
             (+ (point-z a) (point-z b))))

(define (v-v a b)
 (make-point (- (point-x a) (point-x b))
             (- (point-y a) (point-y b))
             (- (point-z a) (point-z b))))

(define (cpsv-v a b receiver)
 (receiver (- (point-x a) (point-x b))
           (- (point-y a) (point-y b))
           (- (point-z a) (point-z b))))

(define (dot a b)
 (+ (* (point-x a) (point-x b))
    (* (point-y a) (point-y b))
    (* (point-z a) (point-z b))))

(define (dot1 ax ay az b)
 (+ (* ax (point-x b)) (* ay (point-y b)) (* az (point-z b))))

(define (dot2 ax ay az bx by bz) (+ (* ax bx) (* ay by) (* az bz)))

(define (unitise r) (s*v (/ 1.0 (sqrt (dot r r))) r))

(define (ray-sphere orig dir center radius)
 (cpsv-v
  center
  orig
  (lambda (vx vy vz)
   (let* ((b (dot1 vx vy vz dir))
          (disc (+ (- (* b b) (dot2 vx vy vz vx vy vz)) (* radius radius))))
    (if (< disc 0.0)
        infinity
        (let ((t2 (+ b (sqrt disc))))
         (if (< t2 0.0)
             infinity
             (let ((t1 (- b (sqrt disc))))
              (if (> t1 0.0) t1 t2)))))))))

(define zero (make-point 0.0 0.0 0.0))

(define (intersect orig dir obj)
 (let lp ((obj obj) (hit (make-hit infinity zero)))
  (let ((l (ray-sphere orig dir (obj-c obj) (obj-r obj))))
   (cond ((>= l (hit-lam hit)) hit)
         ((pair? (obj-objs obj)) (fold-right lp hit (obj-objs obj)))
         ((null? (obj-objs obj))
          (make-hit l (unitise (v+v orig (v-v (s*v l dir) (obj-c obj))))))
         (else (display "Bad obj") (display obj) (newline))))))

(define neg_light (unitise (make-point 1.0 3.0 -2.0)))

(define orig (make-point 0.0 0.0 -4.0))

(define (ray-trace dir scene)
 (let* ((hit (intersect orig dir scene))
        (lam (hit-lam hit))
        (normal (hit-normal hit)))
  (cond ((>= lam infinity) 0.0)
        ((< (hit-lam
             (intersect
              (v+v orig (v+v (s*v lam dir) (s*v (sqrt epsilon) normal)))
              neg_light
              scene))
            infinity)
         0.0)
        (else (max 0.0 (dot normal neg_light))))))

(define (create level c r)
 (let ((obj (make-obj c r '()))
       (a (* 3.0 (/ r (sqrt 12.0)))))
  (if (= level 1)
      obj
      (let ((aux (lambda (x z)
                  (create (- level 1) (v+v c (make-point x a z)) (* 0.5
r)))))
       (make-obj c
                 (* 3.0 r)
                 (list obj
                       (aux (- a) (- a))
                       (aux a (- a))
                       (aux (- a) a)
                       (aux a a)))))))

(define level 6)
(define level (or (and (= (length argv) 3)
                       (string->number (vector-ref argv 1))) 9))

(define n 160)
(define n (or (and (= (length argv) 3)
                   (string->number (vector-ref argv 2))) 512))

(define ss 4)

(define scene (create level (make-point 0.0 -1.0 0.0) 1.0))

(define ss2 (* ss ss))

(define (aux x d) (+ (- x (/ n 2.0)) (/ d ss)))

(define (g x y)
 (do ((dx  0 (+ dx 1))
      (sum 0 (do ((dy    0 (+ dy 1))
                  (sum sum (+ sum
                              (ray-trace (unitise
                                          (make-point (aux x dx)
                                                      (aux (- (- n 1) y) dy)
                                                      (exact->inexact n)))
                                         scene))))
               ((>= dy ss) sum))))
   ((>= dx ss) sum)))

(define (pixel x y)
 (write-char
  (integer->char (inexact->exact (truncate (+ 0.5 (* 255 (/ (g x y)
ss2))))))))

(define n2 n)

(define (go)
 (with-output-to-file "scheme.pgm"
  (lambda ()
   (display "P5")
   (newline)
   (display n)
   (display " ")
   (display n)
   (newline)
   (display 255)
   (newline)
   (do ((y 0 (+ y 1))) ((>= y n2))
    (do ((x 0 (+ x 1))) ((>= x n))
     (pixel x y))))))

(go)

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

These are not optimal options for stalin. You could at least
use the same gcc-options as for g++: -O3 -march=athlon-tbird
--fast-math

Seems like a cut and paste error. Same compile time for stalin on
both machines?

--

Good point!

Oops. I forgot to measure the compile time on x86. Here are some new results
for Stalin on x86:

Compile line:

time stalin -d0 -d1 -d5 -d6 -On -q -d -architecture IA32-align-double
-no-clone-size-limit -split-even-if-no-widening -copt -O3 -copt
-fomit-frame-pointer -copt -malign-double -copt -march=athlon-tbird -copt
-ffast-mathqobi

Running time:

64.191s

Compile time:

574.331s

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

The Scheme community is happy that there are many Scheme
implementations and they will not raise their brows if you do not like
any specific Scheme implementation. Common Lisper call it a bug.
However, we call it a feature.

I have 3 missions:

a) Man must believe in God

b) Scheme is highly recommended for *scientific numerical calculations"

c) EVERY Scheme implementation has a lot to offer. The Scheme language
standard is a beauty in itslef. Although, Bigloo for example goes
farther and will give you pattern-matching for example:

==
(module test)

(define
   (map2e::obj fun::obj lis1::pair-nil lis2::pair-nil)
   (match-case (list lis2 lis2)
      [(() ()) '()]
      [((?h1 ???t1) (?h2 ???t2))
         (cons
            (fun h1 h2)
            (map2 fun t1 t2))]
      [(?- ?-) (error "map2" "invalid list argument" (list lis
lis2))]))

(print (map2 (lambda (x y) (+ x y))
       (list 2 34)
       (list 2 3)))
==

You shouldn't go with the impression Scheme is a tiny standard.

Corratec_Team_Racer