On Wednesday 03 October 2001 10:56 am, Michael Maraist wrote:
> > > x = z->opcode_funcs;
> > >
> > > while (pc >= code_start && pc < code_end && *pc) {
> > > do {
> > > y = x[*w]; \
> > > w = (y)(w,z); \
> > > } while (0);
> > > }
> > >
> > > slow it down by 6%?
> >
> > Perhaps x is no long considered a register. Are you compiling with -O2?
> > compile to source (-S on gcc) and loop for that inner loop. See what is
> > physically different. (I'm away from my test-environment at the moment)
>
> Oh, better yet, given all the cache-work I've done in the past two days,
> it's entirely possible that a cache line is violated due to the new
> assembly ordering. You'd have to check the assembly source to know.
>
> One check you can perform is to put a temporary variable w/in the loop and
> assign it to the outer variable. This avoids the indirection but keeps
> the cache / register set populated.
>
> If you did you -O2 it shouldn't matter though, because the code would be
> reordered either way.
Leaving the initial (outer) assignment of opcode_funcs to temp (x), the only
differences in the assembly between the two are the three less operations
within the inner loop that handle the original (inner) assignment. Your
other suggestions were tried and had no discernable effect. I'll try it on
a Sparc under Forte, and see what it does. (But I'm willing for now to just
accept it and chalk it up as a lesson learned. Test everything.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
