Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!hplabs!decwrl!spar!malcolm
From: malcolm@spar.SPAR.SLB.COM (Malcolm Slaney)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp vs. C Floating Point (Suns)
Summary: Lisp getting faster/ Better benchmarks needed
Message-ID: <557@spar.SPAR.SLB.COM>
Date: 1 Feb 88 04:53:56 GMT
References: <536@spar.SPAR.SLB.COM> <6@sea.sm.unisys.com>
Reply-To: malcolm@spar.slb.com (Malcolm Slaney)
Organization: SPAR - Schlumberger Palo Alto Research
Lines: 38

In article <6@sea.sm.unisys.com> eggert@sea.sm.unisys.com (Paul Eggert) writes:
> In article <536@spar.SPAR.SLB.COM> malcolm@spar.SPAR.SLB.COM (Malcolm Slaney)
> gives a C version on of the Barrow/Gabriel/Lucid FFT benchmark, and concludes
> that Lisp compilers now generate code as fast as the code that C compilers
> generate.  But his C version's register declarations could stand improvements;
> in particular, the key scalar variables should be put in registers.  
Thanks for the better numbers.  I feel much better now that C is coming out
*slightly* ahead.

I would like to make two points.  First, as far as I can tell the Lucid
compiler is not putting ANYTHING in registers (I wish their disassembler
was 1/10th as good as their compiler!)  I hope this means there is still
plenty of room for improvement in the Lisp compilers.  Secondly, we *were*
seeing floating point run 10 times slower than Lisp because of the need
for boxing (tags) and no type propogation.  I'm VERY happy to see that the
lisp compilers are improving so much.

> Even with these changes, I would like to see a better benchmark for relating
> the quality of C compilers versus Lisp compilers.  The FFT benchmark is
> dominated by floating point work, which is relatively insensitive to the 
> choice of language and compiler.  
Thank you...that is my entire point.  I'm building systems to make signal
processing easier.  If floating point is relatively insensitive to the choice
of language (as I believe it is starting to be) then why not use Lisp and
get all the interactive and user interface advantages??????

> Even if we were to pick a different Gabriel benchmark, blindly translating 
> an existing Lisp program into C biases the results in favor of Lisp.
I'm not sure why this is true.  The only way to really compare two languages
for performance is to lock two hackers into two different rooms, feed them
equal amounts of caffeinated soda (:-) and see which one is faster after a
month.  I don't have the time or resources to do that.  Instead I have to
settle for "toy" benchmarks to identify problem areas and help understand
the issues.

I'm open to suggestions and more data.

								Malcolm