Hi,
I've written a toy fractal plotter
(http://ftp.davidashen.net/misc/mandel.lisp , a sample fractal is
http://ftp.davidashen.net/misc/fractal0.png); what concerns me is no
matter how many type declarations I add,
CMU CL runs four times faster than lispworks 4.4.5 (I have a
professional license) and Allegro 6.2 (trial).
I know that CMUCL is very good at floating point performance, but I
thought the commercial implementations would be close. Mac OS X.
What am I missing?
David
> What am I missing?
complex arithmetics is slow in lispworks. After I eliminated complex
numbers decomposition in POINT, and replaced complex arithmetics with
real one, it runs as fast as CMUCL (which does it for me, judging by
the result of disassemble). ACL 6.2 goes into endless loop or complains
about invalid LAP instruction somehow.
David
From: Wade Humeniuk
Subject: Re: floating point performance in cmucl, lispworks and acl
Date:
Message-ID: <TN6de.26941$vN2.1807@clgrps13>
············@gmail.com wrote:
> Hi,
>
> I've written a toy fractal plotter
> (http://ftp.davidashen.net/misc/mandel.lisp , a sample fractal is
> http://ftp.davidashen.net/misc/fractal0.png); what concerns me is no
> matter how many type declarations I add,
> CMU CL runs four times faster than lispworks 4.4.5 (I have a
> professional license) and Allegro 6.2 (trial).
> I know that CMUCL is very good at floating point performance, but I
> thought the commercial implementations would be close. Mac OS X.
>
> What am I missing?
Could you please add more information about how to run your code.
e.g. What are good args for PLOT? Does this generate a Postscript
file or what?
Also there does not seem to be many declarations at all in your
posted version. Do you have a more fully fleshed out one?
As just a quick suggestion, I suggest adding a
(declaim (inline point field))
to your file. (somewhere before the functions)
Also add a (declare (inline colcomp)) in your PLOT
function, right after the flet.
Wade
> Could you please add more information about how to run your code.
> e.g. What are good args for PLOT? Does this generate a Postscript
> file or what?
>
Yes, it generates a PostScript file. The following draws a general
picture:
(time (let* (
(niter 1024)
(lb #C(-2.2e0 -1.5e0))
(rt #C(0.8e0 1.5e0))
(res 400))
(with-open-file (outp "fractal.ps" :if-exists :supersede :direction
:output)
(plot niter lb rt res outp))))
about 30 seconds in CMU CL on my computer. about 300 seconds -- TEN
times slower!
This one draws something that looks like a map of fjords. Turn
anitaliasing off if it looks sparse.
(time (let* (
(niter 999)
(lb #C(0.1343500e0 0.6331000e0))
(rt #C(0.1344125e0 0.6331625e0))
(res 400))
(with-open-file (outp "fractal.ps" :if-exists :supersede :direction
:output)
(plot niter lb rt res outp))))
times are very similar.
> Also there does not seem to be many declarations at all in your
> posted version. Do you have a more fully fleshed out one?
the only useful declarations are in POINT. Anything else does not (and
should not) affect speed in any of the implementations.
>
> As just a quick suggestion, I suggest adding a
>
> (declaim (inline point field))
>
> to your file. (somewhere before the functions)
No, you don't want to do that, because point is recursive and thus
cannot be inlined, and there is ONE call to field per map.
>
> Also add a (declare (inline colcomp)) in your PLOT
> function, right after the flet.
It is called once per several hunderds of invocations of POINT, does
not affect anything.
David
From: Wade Humeniuk
Subject: Re: floating point performance in cmucl, lispworks and acl
Date:
Message-ID: <iH7de.40623$3V3.2839@edtnps89>
I assume somewhere you globally declare that (speed 3) (safety 0) (debug 0)?
(I do not see that declaration anywhere in your file).
Also for LW you have to add the (float 0) to the optimize settings for
floating point stuff to be optimized.
Wade
Wade Humeniuk wrote:
> I assume somewhere you globally declare that (speed 3) (safety 0)
(debug 0)?
> (I do not see that declaration anywhere in your file).
>
yes.
> Also for LW you have to add the (float 0) to the optimize settings
for
> floating point stuff to be optimized.
yes.
From: Wade Humeniuk
Subject: Re: floating point performance in cmucl, lispworks and acl
Date:
Message-ID: <h39de.42147$3V3.24757@edtnps89>
This change to your code doubles the speed on my machine. LWW 4.3.7
Perhaps it will give you some further ideas for speeding things up.
The changes to POINT removes all float boxing.
Wade
(defun POINT (re im rc ic n)
"computes mandelbrot sets"
(declare (type fixnum n)
(optimize (speed 3) (safety 0) (debug 0) (float 0))
(type single-float im re ic rc))
(prog ()
start
(let* ((im2 (* im im))
(re2 (* re re))
(re2+im2 (+ re2 im2))
(2reim (* 2.0s0 re im)))
(declare (single-float im2 re2 2reim re2+im2))
(cond
((< 4.0s0 re2+im2) (return-from point n))
((zerop n) (return-from point nil))
(t (setf re (+ (- re2 im2) rc)
im (+ 2reim ic))
(decf n)
(go start))))))
(defun FIELD (lb rt res n paint)
"draws a field between lb and rt, calling paint c color on non-mandelbrot points"
(declare (optimize (speed 3) (safety 0) (debug 0) (float 0)))
(let* ((le (realpart lb))
(bo (imagpart lb))
(ri (realpart rt))
(to (imagpart rt))
(sh (float (/ (- ri le) res)))
(sv (float (/ (- to bo) res))))
(declare (type single-float le bo ri to sh sv))
(do ((re le (+ re sh)))
((<= ri re) nil)
(declare (type single-float re))
(do ((im bo (+ im sv)))
((<= to im) nil)
(declare (type single-float im))
(let* ((color (point 0.0s0 0.0s0 re im n)))
(when color (funcall paint (complex re im) color)))))))
Wade Humeniuk wrote:
> This change to your code doubles the speed on my machine. LWW 4.3.7
> Perhaps it will give you some further ideas for speeding things up.
>
> The changes to POINT removes all float boxing.
>
> Wade
>
> (defun POINT (re im rc ic n)
Of course removing operations on complex numbers speeds up LW. But I
don't want to hand code them; it is what the complex type in the
language is for. These modifications improve the performance of LW, but
not of CMUCL.
Why should I not use complex numbers if they are in the language and
can be declared to be based on fixed-floats?
David
In article <·······················@f14g2000cwb.googlegroups.com>,
·············@gmail.com" <············@gmail.com> wrote:
> Wade Humeniuk wrote:
> > This change to your code doubles the speed on my machine. LWW 4.3.7
> > Perhaps it will give you some further ideas for speeding things up.
> >
> > The changes to POINT removes all float boxing.
> >
> > Wade
> >
> > (defun POINT (re im rc ic n)
>
> Of course removing operations on complex numbers speeds up LW. But I
> don't want to hand code them; it is what the complex type in the
> language is for. These modifications improve the performance of LW, but
> not of CMUCL.
>
> Why should I not use complex numbers if they are in the language and
> can be declared to be based on fixed-floats?
>
> David
Don't forget to send a nice mail to the LispWorks developers
and request to improve the implementation of complex numbers.
Send also a short example demonstrating the problem.
Feedback of this kind keeps them busy and helps to
improve the implementation...
From: Raymond Toy
Subject: Re: floating point performance in cmucl, lispworks and acl
Date:
Message-ID: <sxd64y1vhnt.fsf@rtp.ericsson.se>
>>>>> "david" == david ······@gmail com <············@gmail.com> writes:
david> Wade Humeniuk wrote:
>> This change to your code doubles the speed on my machine. LWW 4.3.7
>> Perhaps it will give you some further ideas for speeding things up.
>>
>> The changes to POINT removes all float boxing.
>>
>> Wade
>>
>> (defun POINT (re im rc ic n)
david> Of course removing operations on complex numbers speeds up LW. But I
david> don't want to hand code them; it is what the complex type in the
david> language is for. These modifications improve the performance of LW, but
david> not of CMUCL.
david> Why should I not use complex numbers if they are in the language and
david> can be declared to be based on fixed-floats?
Perhaps consing is the problem. As far as I know, only CMUCL and SBCL
have non-consing specialized complex numbers.
Ray