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.
Jon Harrop wrote: > 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.
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.
Ray Dillinger wrote: > 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.
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...
> 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.
> 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.
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.
> 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.
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:
Jon Harrop wrote: > 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.
It is also worth noting the Stalin code has no type declarations.
Jens Axel Sřgaard wrote: > Jon Harrop wrote: >> 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.
> It is also worth noting the Stalin code has no type declarations.
Well, it uses "vec" and "list" but I'm not sure what you'd call a type declaration.
Daniel C. Wang wrote: > {stuff deleted} >> 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.
> 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.
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.
Jon Harrop wrote: > 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):
Which Scheme version did you use? Is it the same as the one you used under Bigloo (except for the +fl, etc. operators).
> > 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.
> It is also worth noting the Stalin code has no type declarations.
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.
Jon Harrop wrote: >Bigloo in particular has the worst error reporting I've ever seen...
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.
Kjetil Svalastog Matheussen wrote: > On Sun, 14 Aug 2005, Jon Harrop wrote:
> > 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.
> 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:
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.
Förster vom Silberwald wrote: > Jon Harrop wrote: >>Bigloo in particular has the worst error reporting I've ever seen...
> It depends. There are three stages: bigloo -i, bigloo, and bigloo > -Obench. And all will give you different error messages.
I'll check those out, thanks.
> Do you think that OCaml its error messages are better?
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...
> 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.
Yes. I am very impressed with Stalin.
> 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.
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.
Rob Thorpe wrote: > What version of Stalin are you guys using?
I'm using the Stalin from Debian testing, which identifies itself as 0.10.
> 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.
Weird. I think that is exactly the same version that I'm using. The package is "0.9+0.10alpha", whatever that means.
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.
q...@purdue.edu wrote: > 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?
Jon Harrop <use...@jdh30.plus.com> writes: > real 0m2.152s > real 0m2.435s > real 0m3.255s > real 0m3.712s > real 0m0.987s > real 0m1.056s > real 0m1.037s > real 0m1.773s
Are you sure you want to compare run times which differ in amounts of under one second?
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.
> 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.
> 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.
Sure. Here's the code and some new (longer) timings:
(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)))))))
On Tue, 16 Aug 2005, Jon Harrop wrote: > q...@purdue.edu wrote: >> 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.
> Sure. Here's the code and some new (longer) timings:
Kjetil Svalastog Matheussen wrote: > 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
Good point!
> Seems like a cut and paste error. Same compile time for stalin on > both machines?
Oops. I forgot to measure the compile time on x86. Here are some new results for Stalin on x86:
Jon Harrop wrote: > Yes. I am very impressed with Stalin.
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: