Hello
I have written a simple Mandelbrot program (using cl-gd). It works fine
with sbcl, but is terriable slow under CMUCL.
Any idea what could be the problem? (No I don't forget compiling.)
Thanks for your help.
Andreas Klein
-------------------------------------------------------------------
(defun mandel (xmin ymin xmax ymax)
"Computes the mandelbrot set in the rectangle define by xmi,ymix and
xmax,ymax"
(with-image* (*width* *height*)
(allocate-color 0 0 0) ; background color
(let ((delta-x (/ (- xmax xmin) *width*))
(delta-y (/ (- ymax ymin) *height*))
(white (allocate-color 255 255 255)))
; everything that lie not in the mandelbrot set will be
white
(declare (double-float delta-x delta-y))
(do ((i 0 (+ i 1))
(x xmin (+ x delta-x)))
((= i *width*) nil)
(declare (double-float x)
(fixnum i))
(do ((j 0 (+ j 1))
(y ymin (+ y delta-y)))
((= j *height*) nil)
(declare (double-float y)
(fixnum j))
(let ((c (+ x (* #c(0.0d0 1.0d0) y))))
(declare (type (complex double-float) c)
(optimize (speed 3)
(compilation-speed 0)
(safety 0)
(debug 0)))
(do ((counter 0 (1+ counter))
(c_iter #c(0.0d0 0.0d0) (+ (* c_iter c_iter)
c)))
((= counter *bound*) nil)
(declare (type (complex double-float) c_iter)
(fixnum counter))
(if (> (abs c_iter) 2)
(progn
(set-pixel i j :color white)
(return))))))))
(write-image-to-file "mandel.png"
:compression-level 6
:if-exists :supersede)))
On Sep 6, 3:23 am, Andreas Klein <·····@cage.ugent.be> wrote:
> Any idea what could be the problem? (No I don't forget compiling.)
I don't know, but maybe CMUCL doesn't know how to manipulate unboxed
complex numbers. If that's right, it's not something that would be
easily fixed.
-- Scott
>>>>> "Scott" == Scott Burson <········@gmail.com> writes:
Scott> On Sep 6, 3:23 am, Andreas Klein <·····@cage.ugent.be> wrote:
>> Any idea what could be the problem? (No I don't forget compiling.)
Scott> I don't know, but maybe CMUCL doesn't know how to manipulate unboxed
Scott> complex numbers. If that's right, it's not something that would be
CMUCL supports unboxed complex single-float and double-float (and
double-double-float, an extension) numbers.
Ray
Scott Burson <········@gmail.com> writes:
> On Sep 6, 3:23 am, Andreas Klein <·····@cage.ugent.be> wrote:
>> Any idea what could be the problem? (No I don't forget compiling.)
>
> I don't know, but maybe CMUCL doesn't know how to manipulate unboxed
> complex numbers. If that's right, it's not something that would be
> easily fixed.
Might be an idea to add optimizations to the code, and look
closely at the compiler messages...
Raymond Wiker <···@rawmbp.local> wrote:
> Scott Burson <········@gmail.com> writes:
>
>> I don't know, but maybe CMUCL doesn't know how to manipulate unboxed
>> complex numbers. If that's right, it's not something that would be
>> easily fixed.
>
> Might be an idea to add optimizations to the code, and look
> closely at the compiler messages...
Which optimizations? I have added all optimizations I can think of.
Can you give an example?
Thanks Andreas
Andreas Klein <·····@cage.ugent.be> writes:
> Raymond Wiker <···@rawmbp.local> wrote:
>> Scott Burson <········@gmail.com> writes:
>>
>>> I don't know, but maybe CMUCL doesn't know how to manipulate unboxed
>>> complex numbers. If that's right, it's not something that would be
>>> easily fixed.
>>
>> Might be an idea to add optimizations to the code, and look
>> closely at the compiler messages...
>
> Which optimizations? I have added all optimizations I can think of.
>
> Can you give an example?
Sorry... I meant declarations, and on closer look, I see that
you have already added some of those. You might want to crank up the
optimization settings; this should cause the compiler to tell you
about places where type declarations might help. You could also use
(the ...) to give the compiler additional hints on the types of return
values.
Scott Burson <········@gmail.com> wrote:
> On Sep 6, 3:23 am, Andreas Klein <·····@cage.ugent.be> wrote:
>> Any idea what could be the problem? (No I don't forget compiling.)
>
> I don't know, but maybe CMUCL doesn't know how to manipulate unboxed
> complex numbers. If that's right, it's not something that would be
> easily fixed.
>
Could be possible. I have tried to track the problem down.
(defun f (x y)
(declare (double-float x y)
(optimize (speed 3)
(compilation-speed 0)
(safety 0)
(debug 0)))
(the double-float (+ x y)))
Here CMUCL gives a warning
; Note: Doing float to pointer coercion (cost 13) to "<return value>".
and the comiled code looks worse in comparison to SBCL. This problem is
know Section 5.13.3 in the CMUCL-doc. But If I understand the
documentation correctly (Section 5.11.10) this due to the non-local call
of f.
Thus I guess the original program has an other problem.
> I have written a simple Mandelbrot program (using cl-gd). It works fine
> with sbcl, but is terriable slow under CMUCL.
Have you tried using CMUCL's profiler (http://common-lisp.net/project/
cmucl/doc/cmu-user/compiler-hint.html#toc219)?
Andreas Klein <·····@cage.ugent.be> writes:
> Hello
>
> I have written a simple Mandelbrot program (using cl-gd). It works fine
> with sbcl, but is terriable slow under CMUCL.
>
> Any idea what could be the problem? (No I don't forget compiling.)
>
> Thanks for your help.
> Andreas Klein
At the very least you should add the following to the front of your
file:
(declaim (optimize (speed 3) (safety 1)))
This will get you a whole bunch of efficiency notes (about 80) that
should guide you into adding declarations to your code.
--
Fred Gilham ······@csl.sri.com
The spam folder --- you will never find a more wretched hive of scum
and villainy. We must be cautious.
Andreas Klein <·····@cage.ugent.be> writes:
> Hello
>
> I have written a simple Mandelbrot program (using cl-gd). It works fine
> with sbcl, but is terriable slow under CMUCL.
>
> Any idea what could be the problem? (No I don't forget compiling.)
>
> Thanks for your help.
> Andreas Klein
>
Another thing is to use the CMUCL extensions:
(declaim (ext:start-block mandel))
< your mandel function and any functions it makes use of >
(declaim (ext:end-block))
This will turn all your function calls into local calls that should
make the calling more efficient.
--
Fred Gilham ······@csl.sri.com
The spam folder --- you will never find a more wretched hive of scum
and villainy. We must be cautious.