Prev: [CfP] DLS'10
Next: Tracing recursive functions in slime REPL (Allegro CL)
From: Andrea Taverna on 22 Apr 2010 15:40
Thanks for the responses, found the solution after RTFM :D

Solution:
-----%<-----%<-----%<-----%<-----%<-----%<
CL-USER> (defparameter A (make-array '(5 5)))
A
CL-USER> (iter (for i from 0 below 5)
(iter (for j from 0 below 5)
(setf (aref A i j) (random 100)))
(finally (setf (aref A 1 1) -1))) ; minimum at 1 1
NIL
CL-USER> (iter outer (for i from 0 below 5)
(iter (for j from 0 below 5)
(in outer (finding (list i j) minimizing (aref A i j)))))

(1 1)
-----%<-----%<-----%<-----%<-----%<-----%<

Then comes a more interesting question.
I tried benchmarking the code above with the loop version. I noticed
that the difference in term of consing is irrelevant.
I was worried about the consing that may occour by using destructuring
forms in loop/iter, i.e. something like
for (x y) = (f alpha beta i), where f returns a 2-element list, or, in
iter (for (list x y) = (f alpha beta i))
Can I conclude the compiler is clever enough to not cons new lists at
every iteration, when such forms appear?

thanks

Andrea
From: vanekl on 22 Apr 2010 17:37
Andrea Taverna wrote:
> Thanks for the responses, found the solution after RTFM :D
>
> Solution:
> -----%<-----%<-----%<-----%<-----%<-----%<
> CL-USER> (defparameter A (make-array '(5 5)))
> A
> CL-USER> (iter (for i from 0 below 5)
> (iter (for j from 0 below 5)
> (setf (aref A i j) (random 100)))
> (finally (setf (aref A 1 1) -1))) ; minimum at 1 1
> NIL
> CL-USER> (iter outer (for i from 0 below 5)
> (iter (for j from 0 below 5)
> (in outer (finding (list i j) minimizing (aref A i j)))))
>
> (1 1)
> -----%<-----%<-----%<-----%<-----%<-----%<
>
> Then comes a more interesting question.
> I tried benchmarking the code above with the loop version. I noticed
> that the difference in term of consing is irrelevant.
> I was worried about the consing that may occour by using destructuring
> forms in loop/iter, i.e. something like
> for (x y) = (f alpha beta i), where f returns a 2-element list, or, in
> iter (for (list x y) = (f alpha beta i))
> Can I conclude the compiler is clever enough to not cons new lists at
> every iteration, when such forms appear?

You should be able to get pretty good insight by running something
like this:

(time (dotimes (i 1000)
(function-to-test)))

Your CL implementation probably will tell you how much consing occurs.
(You could optionally use the ROOM function.)

Consing may not necessarily be a big consideration depending on a)
your CL implementation, and b) how often you call the function that
conses. Some garbage collectors handle consing quite efficiently, and
a function that conses but is rarely called will have little overall
impact (Amdahl's Law).
My advice: don't optimize too early :: CL is easy to refactor if the
need arises.


> thanks
>
> Andrea
From: Andrea Taverna on 26 Apr 2010 08:42
On 22 Apr, 23:37, vanekl <va...(a)acd.net> wrote:
> Andrea Taverna wrote:
[...]
> Your CL implementation probably will tell you how much consing occurs.
> (You could optionally use the ROOM function.)

That's what I've done in the benchmark ;)

Since I didn't noticed a significant difference in consing between the
loop hand-made version and the iterate idiom, nor there seemed to be a
constant increase in the quantity of memory consed by varying the size
of the set C, I presumed iterate interpreted the spec (for (...) ) in
a high level sense, without actually consing a list at each iteration
where a new maxima was found.

Andrea
First  |  Prev  | 
Pages: 1 2
Prev: [CfP] DLS'10
Next: Tracing recursive functions in slime REPL (Allegro CL)