On Mon, Oct 1, 2012 at 1:17 AM, Jonathan Morton <jonathan.mor...@movial.com> wrote: > On Sun, 30 Sep 2012 15:05:18 -0700, Matt Turner <matts...@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 _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman