gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: Lisp vs. Java vs. C++ speed comparison time? [LONG]


From: Camm Maguire
Subject: [Gcl-devel] Re: Lisp vs. Java vs. C++ speed comparison time? [LONG]
Date: 02 Jul 2004 12:42:16 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Greetings!  Coincidentally, we've been looking at the Boyer benchmark
too in testing the recent GCL 2.6.2 release. Thought it might be of
interest to post some GCL results here too (using the boyer benchmark
version posted in this thread):

All times are reported in real time/gc time.

n   GCL-2.6.2   CMUCL 18e  CLISP 2.33.2

0   0.03/0.00   0.04/0.00     0.17/0.01
1   0.21/0.07   0.25/0.00     1.14/0.05
2   0.46/0.12   0.67/0.02     3.08/0.14
3   1.20/0.26   1.76/0.08     8.15/0.50
4   3.74/0.95   5.30/0.69    23.45/1.46
5  12.32/3.72  15.80/2.11    79.51/7.55


All lisps here are the latest versions in Debian unstable.  GCL was
run in ANSI mode.  The machine was a dual Xeon 2.4Ghz.  We already
know that the relative GCL/CMUCL performance can vary somewhat by
machine, presumably influenced by cache size and cpu/memory bandwidth
ratios.  It is clear for example that CMUCL is doing a better job on
the memory layout/access times which predominate in the gc time
component.  On this particular machine, again presumably, memory
access is not the rate limiting step, and the results are more
governed by in cache cpu performance.

All that one might reasonably conclude from this exercise is that in
some cases, GCL is about as fast as CMUCL.

A few extra notes.  GCL comes with an automatic function proclamation
feature which is useful in optimizing the compile, for both GCL and
CMUCL (at least).  One uses it as follows:

(compiler::emit-fn t)
(compile-file "foo.lisp")
(compiler::make-all-proclaims "foo.fn")
(load "sys-proclaim.lisp")
(compile-file "foo.lisp")

This is not simply bundled into compile-file as it is capable of
generating cross-referencing information across many files that can be
useful in optimizing a real system.  The above tests had the
sys-proclaim.lisp file loaded into each lisp before running
compile-file.  What is interesting is that on my machine at least,
this measurably helped the cmucl compile over a 'vanilla'
compile-file, and the insertion of 

(declaim (optimize (speed 3) (safety 0) (debug 0) (compilation-speed
0)))

at the top of the lisp source file actually degraded cmucl performance
from the vanilla version.  The fastest cmucl numbers are reported
above. 

Take care,


Antonio Menezes Leitao <address@hidden> writes:

> address@hidden (Mark McConnell) writes:
> 
> > To clarify: I'm concerned the test was unfair to Lisp.  Java's
> > compiler tries to optimize for speed, but Lisp won't try [or won't try
> > its hardest] unless you say (proclaim '(optimize speed)).  Antonio, is
> > there a chance you could run the test again with that line included?
> 
> Sure.  I added a 
> 
> (declaim (optimize (speed 3) (safety 0) (debug 0) (compilation-speed 0)))
> 
> at the beginning of the (Common Lisp) file, recompiled it and timed it
> again.  Here are the results of two runs (I also run the Java code
> again):
> 
> N  CMUCL  CLISP Allegro ServerVM
> 0   0.04   0.14   0.02   0.05
> 1   0.12   0.84   0.18   0.13
> 2   0.37   2.40   0.51   0.43
> 3   1.18   6.28   1.46   1.11
> 4   2.94  18.24   5.30   3.68
> 5  11.81  69.04  24.04  15.81
> 
> N  CMUCL  CLISP Allegro ServerVM
> 0   0.02   0.13   0.03   0.02
> 1   0.17   0.84   0.18   0.13
> 2   0.40   2.32   0.51   0.40
> 3   1.02   6.57   1.45   1.08
> 4   3.03  17.99   4.82   3.71
> 5  13.03  70.86  23.35  15.37
> 
> The results are not very different from the previous ones I published
> and that I repeat below:
> 
> N  CMUCL  CLISP Allegro ServerVM
> 0   0.04   0.13   0.04   0.02
> 1   0.13   0.84   0.26   0.18
> 2   0.41   2.31   0.72   0.50
> 3   1.25   6.58   1.99   1.46
> 4   3.22  17.87   6.36   3.89
> 5  12.60  69.65  26.97  19.25
> 
> I guess the Boyer benchmark doesn't show much opportunity for
> optimization.
> 
> One last note:
> 
> I think we shouldn't put too much confidence in these numbers.  My
> test machine is one of those new Centrinos that dynamically adjusts
> the processor speed.  This might cause inconsistent timings.  One
> strange phenomena is the larger variance of the JVM compared with the
> Lisps.  In the same Common Lisp environment I get (more or less)
> consistent timings, but in the JVM I get from 15 s to 25 s for the
> last test case (apparently, depending on the day of the test :-).
> 
> Anyway, given the investment being done in Java compared with the
> investment being done in Common Lisp, I foresee difficult times for
> Common Lisp compilers that want to compete with Java for speed.
> Fortunately, speed is the least of my concerns.  Usually, all my code
> is compiled with (declaim (optimize (speed 0) (safety 3) (debug 3))).
> 
> Best regards,
> 
> António Leitão.

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]