Performance of Dolphin

Hello,

Here is yet another way to do iteration. It is quite fast with the right
amount of memory, but not as fast, as I would hope.

I think we're at the limit of what could be done without optimizing
the expression used to recompute value in array.

Artur Zaroda
[hidden email]

------------------------------------------------------------------------

Object subclass: #FoolClosure
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        classInstanceVariableNames: ''!

!FoolClosure class methodsFor!

run

        | t1 t2 size steps then i s |
        size:=self size.
        steps:=10.
        t1:=(Array new: size squared) atAllPut: 1.0.
        t2:=(Array new: size squared) atAllPut: 30.0.
        Transcript display: 'Heat Conduction Run'; cr.
        i:=1.
        then:=self transformationFrom: t1 to: t2 andThen:
                (self transformationFrom: t2 to: t1 andThen:
                [ Transcript display: (t1 at: size*(size-1)/2); cr.
                        (i:=i+1)>steps ifTrue: [^self].
                        then]).
        s:=then.
        [s:=s value value value value value value value value value value] repeat!

size

        ^300!

size: size row: i col: j from: t1 to: t2 next: next

        | center up down left right |
        center:=(i-1)*size+j.
        up:=center-size.
        down:=center+size.
        left:=center-1.
        right:=center+1.
        ^[t2 at: center put:
                1.0+(0.6*(t1 at: center))+(0.1*((t1 at: up)+(t1 at: down)+(t1 at: left)+(t1 at: right))).
        next]!

transformationFrom: t1 to: t2 andThen: next

        | cl size |
        size:=self size.
        cl:=next.
        2 to: size-1 do: [:i|
                2 to: size-1 do: [:j|
                        cl:=FoolClosure size: size row: i col: j from: t1 to: t2 next: cl]].
        ^cl! !

On Sat, 20 Jan 2001, Dave Harris wrote:

> [hidden email] (Artur Zaroda) wrote (abridged):
>
> To me it seemed about the same. I didn't notice any degradation, but I
> didn't notice any improvement either so I probably should have left it
> out. It didn't occur to me it might be slower. #basicAt: should avoid a
> message dispatch.

I tried something like:

t:=Array new: 1.
t at: 1 put: t.
[(((((((((((((((((((t
at: 1) at: 1) at: 1) at: 1) at: 1)
at: 1) at: 1) at: 1) at: 1) at: 1)
at: 1) at: 1) at: 1) at: 1) at: 1)
at: 1) at: 1) at: 1) at: 1) at: 1]
millisecondsToRepeat: aVeryLargeNumber

and the same for #basicAt:. The result for #at: was consistently about
13% lower, than that for #basicAt:.

Artur Zaroda
[hidden email]

"Dave Harris" <[hidden email]> wrote in message
news:[hidden email]... Well here's the original Dylan code as posted by Rolf Wester.   BTW,  I'm
not at all sure that there has been an apples to apples comparison of Dylan
and Smalltalk times yet because the original Dylan numbers I got from Rolf
Wester's post were on a PII 450, and all of my numbers were from a PIII-500.
Also there was a bit of chatter in c.l.d about the relative "newbie" nature
of this code.  You don't have to use "aref" in Dylan, and had the original
poster defined a few more types for the arrays the times would have been
better.  After those suggestions, the thread degraded into questions about
why the Fun-O product had stack problems...

Another BTW: the main reason I'm using Dolphin now and not Fun-O's FD 2.0 is
the very active Dolphin newsgroup and the great product support provided by
Object Arts!!  (Not to mention the great Dolphin product).


Dylan source
-------------
define method temp (nx :: <integer>, ny :: <integer>, nt :: <integer>)

   let t1 = make(<array>, dimensions: #(300 , 300), fill: 0.0);
   let t2 = make(<array>, dimensions: #(300 , 300), fill: 0.0);

   for (k :: <integer> from 0 to nt - 1)
     for (i :: <integer> from 1 to nx - 2)
       for (j :: <integer> from 1 to ny - 2)
           aref(t2, i, j) := aref(t1, i, j) + 1.0 + 0.1 *
                                              (aref(t1, i + 1, j) +
                                               aref(t1, i - 1, j) +
                                               aref(t1, i, j + 1) +
                                               aref(t1, i, j - 1) -
                                         4.0 * aref(t1, i,j));
        end for;
     end for;
     for (i :: <integer> from 1 to nx - 2)
       for (j :: <integer> from 1 to ny - 2)
           aref(t1, i, j) := aref(t2, i, j) + 1.0 + 0.1 *
                                              (aref(t2, i + 1, j) +
                                               aref(t2, i - 1, j) +
                                               aref(t2, i, j + 1) +
                                               aref(t2, i, j - 1) -
                                         4.0 * aref(t2, i,j));
        end for;
     end for;
     format-out("%d \n", aref(t1, 150, 150));
   end for;
end method;

temp(300 , 300 , 10);

[hidden email] (Dave Harris) writes:

> I don't understand why Dylan was so slow. I don't know the FunDev
> product, but from the review at:
>   http://www.byte.com/column/BYT20000628S0007
>
> it is a static compiler. Are you sure it was used in "production mode"?

I think there was a problem when compiled in production mode that
caused the program to crash after a short amount of time. Something to
do with the stack that fun-o is looking into. So the times were in
'loose mode'.

Another timing problem was that the Dylan code time was timed from
start of application to end. This includes all the time to load DLL's,
initialize the application, etc. When evaluating in a Dolphin
workspace you avoid this. Perhaps the Dylan code should be timed by
running the function from the interactor. Or for Dolphin, to compare,
by generating a console application that runs the function then timing
how long it takes to execute.

Chris.
--
http://www.double.co.nz/dylan

"John Whittaker" <[hidden email]> wrote in
<zv996.5796$[hidden email]>:

>  I also hoped that I might be able to introduce the Dylan
>language to Smalltalkers through this exercise.  While Smalltalk is my
>language of choice right now, I've always loved the functional approach.
>Dylan combines the best of both worlds.  

Isn't Dylan basically dead, though? The Functional Objects website hasn't
been updated for ages...

P. (ex-Harlequin, where FO came from, although I wasn't in the Dylan group)

[hidden email] (Paul Hudson) writes:

> Isn't Dylan basically dead, though? The Functional Objects website
> hasn't been updated for ages...

Fun-O still seems to exist. I get emails from them occasionally and
they do answer my support calls. I do wish they'd be a little more
active in the newsgroup and updating their site though.

Chris.
--
http://www.double.co.nz/smalltalk