I've written a simple little vector grid program that uses cl-sdl to
draw an animated grid.
The update rule is that each vector at n+1 is the average of itself and
its four compass point neighbors. This can result in pretty patterns
with the right perturbations but it seems quite slow.
I was wondering if you experienced lispers would like to look at the
lisp and critique it for style and speed.
For speed I also have a implementation specific question. I'm using sbcl
on debian unstable and it reports that:
; note: unable to
; avoid runtime dispatch on array element type
; because:
; Upgraded element type of array is not known at compile time.
; (SETF (AREF (GRID-V-N+1 GRID) X Y)
; (SCALE-VECTOR
; (VECTOR+ (AREF # # #)
; (AREF # # #)
; (AREF # # #)
; (AREF # # #)
; (AREF # # #))
; 0.2))
; --> SB-KERNEL:%ASET LET*
; ==>
; (SB-KERNEL:HAIRY-DATA-VECTOR-SET ARRAY SB-INT:INDEX SB-C::NEW-VALUE)
in function iterate-grid-v but the I tried making the scale-vector
function explicitly return type v (the array's declared type) using the
"the" keyword but it made no difference. Is this message significant and
if so how can I get it to be able to optimise the array access.
The code is at
http://freehost03.websamba.com/charlieb/cl-sdl-vector-grid.tar.gz
Thanks
Charlieb.
charlieb <··@privacy.net> writes:
> For speed I also have a implementation specific question. I'm using
> sbcl on debian unstable and it reports that:
>
> ; note: unable to
> ; avoid runtime dispatch on array element type
> ; because:
> ; Upgraded element type of array is not known at compile time.
>
> ; (SETF (AREF (GRID-V-N+1 GRID) X Y)
[...]
I haven't looked at your code in detail, but the message might be
significant (only profiling can really tell, though). If it is, then
you need, as the message says, to inform the compiler about the
array's type (and not particularly the type of the element you are
attempting to store there): this is done by, if I'm reading your code
correctly, saying
(setf (aref (the (simple-array v (* *)) (grid-v-n+1 grid)) x y)
...)
However -- and please bear in mind that I haven't run cl-sdl ever, so
I could be wrong -- I have heard that there is a bug in cl-sdl which
results in slowness under sbcl: type information isn't propagated to
the foreign function interface, and as a result foreign calls use
overly generic code. If the slowness of your program persists, maybe
contacting the cl-sdl maintainers would help.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> (setf (aref (the (simple-array v (* *)) (grid-v-n+1 grid)) x y)
> ...)
>
> However -- and please bear in mind that I haven't run cl-sdl ever, so
> I could be wrong -- I have heard that there is a bug in cl-sdl which
> results in slowness under sbcl: type information isn't propagated to
> the foreign function interface, and as a result foreign calls use
> overly generic code. If the slowness of your program persists, maybe
> contacting the cl-sdl maintainers would help.
>
> Christophe
That seems to have done the trick. I also tried putting the (the
(simple-array v (* *)) around the return of grid-v-n+1 but that made no
difference. Is there some optimisation rule that I'm missing or am I
just overestimating the intelligence of type inference?
As far as cl-sdl is concerned the only warnings I get are about the init
functions which are only called once so no worries there for now. I'm
happy keeping up to date and learning a bit of lisp optimisation.
Thanks.
Charlieb
charlieb <··@privacy.net> writes:
> Christophe Rhodes wrote:
>
>> (setf (aref (the (simple-array v (* *)) (grid-v-n+1 grid)) x y)
>> ...)
>
> That seems to have done the trick. I also tried putting the (the
> (simple-array v (* *)) around the return of grid-v-n+1 but that made
> no difference. Is there some optimisation rule that I'm missing or am
> I just overestimating the intelligence of type inference?
Well, that would work, as long as you also promised never to redefine
incompatibly the GRID-V-N+1 function. However, in the absence of such
a promise, the compiler cannot assume that you won't redefine it
arbitrarily, so either it can optimize for the current definition,
while storing away the function body for recompilation should the
assumptions underlying any of these speculative optimizations change,
or else it can simply not optimize.
(A third possibility, given that the definition and use are in the
same file: lisp systems are allowed to assume that references to
functions defined in the same file are to that function: see CLHS
3.2.2.3. Currently, sbcl does not exploit this to any significant
degree.)
> As far as cl-sdl is concerned the only warnings I get are about the
> init functions which are only called once so no worries there for
> now. I'm happy keeping up to date and learning a bit of lisp
> optimisation.
Grand. Best of luck!
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
>>Is there some optimisation rule that I'm missing or am
>>I just overestimating the intelligence of type inference?
>
>
> Well, that would work, as long as you also promised never to redefine
> incompatibly the GRID-V-N+1 function. However, in the absence of such
> a promise, the compiler cannot assume that you won't redefine it
> arbitrarily, so either it can optimize for the current definition,
> while storing away the function body for recompilation should the
> assumptions underlying any of these speculative optimizations change,
> or else it can simply not optimize.
>
I must remember how dynamic lisp is when thinking about these things!
Cheers
Charlie.
Christophe Rhodes <·····@cam.ac.uk> writes:
> However -- and please bear in mind that I haven't run cl-sdl ever, so
> I could be wrong -- I have heard that there is a bug in cl-sdl which
> results in slowness under sbcl: type information isn't propagated to
> the foreign function interface, and as a result foreign calls use
> overly generic code. If the slowness of your program persists, maybe
> contacting the cl-sdl maintainers would help.
If the SBCL FFI is the cause, it would not only be slow, it would be
SLOOOOOOW (and cons like crazy). But with proper type declarations it's
lightning fast and conses almost not noticeable. (At least in the
libcrypto FFI I wrote some time ago.)
Regards,
--
Julian Stecklina
Signed/encrypted mail welcome. Key-ID: 0xD65B2AB5
-> GIVE stylish confetti to HEAVILY ARMED CLOWN <-
-> Heavily Armed Clown: Wheeee!! <-