[Openmcl-devel] Performance benchmark results

[Gary Byers]

On Tue, 23 Apr 2002, Christophe Rhodes wrote:

> On Mon, Apr 22, 2002 at 07:53:00PM -0600, Gary Byers wrote:
>
> > I find it surprising that a bytecoded implementation is often over an
> > order of magnitude faster than either of the native implementations on
> > most of the BIGNUM/* benchmarks; I suspect some mixture of Black Magic,
> > clever algorithms, and (possibly) a little excessive zeal on the part
> > of CLISP's compiler.  (It seemed that some calls to "side-effect-free"
> > arithmetic functions were getting optimized out because their results
> > weren't used.)  I may have been mistaken about the excessive zeal or
> > may have misinterpreted the disassembled bytecode I looked at; I'll
> > try to look again when I'm more awake.  Whether that's a factor or not,
> > I'm sure that there's room for improvement in both OpenMCL and SBCL.
>
> Indeed. My understanding wrt clisp's bignum performance is that it uses
> a C bignum library (CLN?) for most of the hard work, so it's only
> byte-compiling function calls for the arithmetic.
>
> Cheers,
>
> Christophe

The "excessive zeal" that I was talking about was in cases like:

(defun call-gcd-n-times (u v n)
  (dotimes (i n) (gcd u v)))

The CLISP compiler will optimize out the calls to GCD (since the only
side-effect it has is to take a little execution time ...)

Eric's benchmarks are written to defeat this, as in:

(defvar *result* 0)

(defun call-gcd-n-times (u v n)
  (dotimes (i n) (setq *result* (gcd u v))))

So, if an overzealous compiler isn't a factor in explaining CLISP's
results, clever algorithms do indeed seem to be the likely culprit.
(Some amount of tweaking/compiler improvements could make the OpenMCL
version faster, but I doubt if it would get 10X faster ...)


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel