[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] Potential performance optimisation tested
From: |
Frederick H. Pitts |
Subject: |
Re: [Bug-apl] Potential performance optimisation tested |
Date: |
Sun, 02 Feb 2014 08:35:55 -0600 |
Elias,
This approach to optimizating Gnu APL sounds very reasonable to me. I
hope it succeeds. May Conway's "Game of Life" go faster. :-)
Fred
On Sun, 2014-02-02 at 21:19 +0800, Elias Mårtenson wrote:
> I made a test implementation of a performance optimisation for GNU
> APL. The short story is that it seems to work for limited tests, but
> there may be issues with my approach and I don't want to spend any
> more time on it unless Jürgen agrees it's a good idea. After all, I
> may have completely misunderstood the architecture of GNU APL and my
> approach may be fundamentally broken.
>
>
> When doing some benchmarking I noticed a lot of time was spent
> allocating, initialising and freeing Value instances. I realised that
> many such allocations are not actually needed. Take the following
> expression for example:
>
>
> ,1+2×foo
>
>
> In this case, the following things happen:
> 1. The multiplication function (implemented by eval_skalar_AB)
> creates a new array and fills it with the result of the
> operation (in this case, bif_multiply) on each cell.
> 2. The addition function is then called, resulting in an
> identical flow as in the multiplication above.
> 3. The ravel function is then called (Bif_COMMA::ravel),
> resulting in yet another array being created which is simply
> copied from B. Note that the ravel is identical between Z and
> B in this case.
> From a performance perspective, I saw a particular low-hanging fruit
> in the ravel call in the last point. Since the value that came from
> the addition is never used anywhere else, one can simply change the
> shape of B in-place and return it immediately.
>
>
> My experiment involved creating a new VF (value flag) value; VF_temp
> that indicates that the value may be reused. This flag is then set for
> all values that are only used once (for example, the return value from
> a primitive or user function). If a value needs to be preserved, it is
> copied, and the flag is not set.
>
>
> What all of this means is that values that are returned from a
> function, can be reused if it makes sense. There are several cases
> where this is the case. For example:
> * The comma function (as discussed above)
> * Reshape, especially when the shape of Z matches that of B
> * Scalar functions. If the sizes of the arguments of plus, for
> example, matches, then A or B can be reused if they are marked
> as temporary.
> * The each operator can (maybe?) push the result straight into
> the source array.
> I've only done very basic testing, but the ravel operator on a large
> array went from taking a second or so to pretty much zero. Same should
> be true for reshape, although that one crashes for me right now. :-)
> Scalar functions still have to process the elements, so their timing
> can't go to zero, but at least the should save the time spent setting
> up the result array and creating new values.
>
>
> Please let me know what you think.
>
>
> Elias