Re: tree walker evaluator

[Jaroslav Hajek]

On Wed, Feb 4, 2009 at 11:24 PM, John W. Eaton <address@hidden> wrote:
> On  4-Feb-2009, Jaroslav Hajek wrote:
>
> | It's nice to have the walker separated. I've removed two left-over
> | obsolete declarations and a local method that you've probably
> | overlooked (pt-loop.h and pt-loop.cc).
> | I also inspected the code for looping over arrays and replaced the
> | complicated per-type casing using DO_ND_LOOP with a single generic
> | branch using do_index_op. Thus, iterating over logical and
> | single-precision arrays now works correctly (does not convert to
> | double) and the code seems a lot simpler to me. Further, since
> | do_index_op normally uses the underlying Array<T> indexing machinery,
> | this will make such loops automatically benefit from shallow slicing,
> | making them faster if the body is cheap.
>
> OK, thanks for looking at this.
>
> | The downside is that this somewhat slows very simple loops over row vectors.
> | Perhaps some specializations would be appropriate for simple row
> | vectors and row strings?
>
> I guess that's what I was trying to do with the DO_ND_LOOP macro,
> though not very well.
>
> jwe
>

OK, so I tried to put some optimizations back in, and ended up with a
much larger change optimizing scalar indices in indexing and
assignment. Changes are uploaded and seem to work. After these
changes, the speed of the following stupid benchmark:

n = 100000;
a = rand (n, 1);
# fake cumsum
tic;
for i = 1:n-1
  a(i+1) += a(i);
endfor
toc

increased by relatively nice 49% (from 12.6626s to 8.47494s), though I
was hoping for a bit more. I'm wondering where the bottleneck is...
maybe profiling would help.
Though this still doesn't go anywhere close to JIT, it may be nice to
have the interpreter's hot-spots optimized... especially as long as
Octave's JIT is stays in the land of wishes. Comments?

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz