Re: Revised PPC assembly implementation

linux@horizon.com writes:

Huh?  I'm saving 19 registers, r13..r31, and not saving 13, namely
r0..r12.

Oops. :)  Somehow I thought you were saving r13..r32 or something. :)

Damn.  So that's actually *worse* than me earlier version which achieved
an (also piddling) 2% speedup?

I wouldn't say it is worse, I would say it is the same.  I didn't do
as many runs of the previous version.  The spread of times looked
about the same with both of your versions.

Damn, I wish I had at that IBM pipeline profiling tool.  If it could
just tell me which cycles didn't have both ALUs busy, I could solve it
in relatively little time.

I'm going to look at trying to get it going.

The place that could really use scheduing help is the G4, which has three
integer ALUs, but can only *think* about executing the bottom three entries
in the reorder queue.  So if one of those instructions isn't ready, it
stalls in the queue and idles the ALU with it.

Yes, the performance on the G4 is also important.  Not everyone has a
G5. ;)

Maybe I can improve the scheduling some more...

The main loop seems to be taking about 560 cycles (assuming that
essentially all the time spent in my little test program is spent in
the main loop).  It contains about 1000 integer instructions, which
will take at least 500 cycles, as we have 2 ALUs.  So we are already
within about 10% of the theoretical optimum.

So I think we are already at the point of diminishing returns as far
as the overall performance of git is concerned.  But if you want to
try to get that last 10%, go for it... :)

Paul.