[Pixman] Questionable numbers from lowlevel-blt-bench

[Matt Turner]

On Mon, Oct 1, 2012 at 1:17 AM, Jonathan Morton
<jonathan.morton at movial.com> wrote:
> On Sun, 30 Sep 2012 15:05:18 -0700, Matt Turner <mattst88 at gmail.com>
> wrote:
>> In doing performance work, I've noticed some weird results from
>> lowlevel-blt-bench. Often it has seemed that the RT results determined
>> the Kops/s almost entirely. I came across an instance of this today
>> which was particularly striking:
>>
>> Before:
>> add_8888_8888 =  L1:  47.01  L2:  36.84  M: 18.96 ( 33.14%)  HT: 35.94
>>  VT: 33.82  R: 30.64  RT: 19.36 ( 181Kops/s)
>>
>> After:
>> add_8888_8888 =  L1: 230.78  L2: 200.86  M: 90.48 (159.44%)  HT: 48.41
>>  VT: 45.46  R: 42.78  RT: 19.22 ( 181Kops/s)
>>
>> L1/L2/M numbers are improved by ~5x. HT, VT, and R numbers are
>> improved by ~1.35x. RT doesn't change... neither does Kops/s.
>>
>> What's going on here, and can we make the composite result more sensible?
>
> The figures in brackets are derived directly from one or more of the
> other figures.  In this case, the Kops/s number is derived directly
> from the RT number, which should explain why they correlate.

Ahh. At least I (and I'm pretty sure others too) thought that the Kops
number was supposed to be a composite of HT, VT, RT, and R. This
explains it then.

> The percentage figure, meanwhile, represents a percentage of memory
> bandwidth used by this blitter (under the M test), the peak bandwidth
> being derived from an earlier measurement.  (You're seeing more than
> 100%, which suggests that the earlier measurement is not optimal.)

Indeed. I'm prefetching in the modified function.

> The RT figure is meant to measure, as directly as possible, the per-call
> overhead which does not depend on the number of pixels involved.
> Accordingly, it is not expected to change significantly when doing
> pixel-related optimisations.

Right, makes sense.

Thanks!
Matt