On Tue, 14 Jul 2015 11:41:25 +0300 Siarhei Siamashka <[email protected]> wrote:
> On Thu, 2 Jul 2015 13:04:11 +0300 > Oded Gabbay <[email protected]> wrote: > > > POWER8, 8 cores, 3.4GHz, RHEL 7.1 ppc64le. > > > > reference memcpy speed = 24764.8MB/s (6191.2MP/s for 32bpp fills) *Very* stable memcpy speed, comparing to patch 7. Impressive. > > > > Before After Change > > --------------------------------------------- > > L1 61.92 244.91 +295.53% > > L2 62.74 243.3 +287.79% > > M 63.03 241.94 +283.85% > > HT 59.91 144.22 +140.73% > > VT 59.4 174.39 +193.59% > > R 53.6 111.37 +107.78% > > RT 37.99 46.38 +22.08% > > Kops/s 436 506 +16.06% > > > > cairo trimmed benchmarks : > > > > Speedups > > ======== > > t-xfce4-terminal-a1 1540.37 -> 1226.14 : 1.26x > > t-firefox-talos-gfx 1488.59 -> 1209.19 : 1.23x > > > > Slowdowns > > ========= > > t-evolution 553.88 -> 581.63 : 1.05x > > t-poppler 364.99 -> 383.79 : 1.05x > > t-firefox-scrolling 1223.65 -> 1304.34 : 1.07x > > > > Signed-off-by: Oded Gabbay <[email protected]> > > Acked-by: Siarhei Siamashka <[email protected]> > Hi, why are there slowdowns up to 7%? Can the cost of adding more entries to the fast path table be that much, or is something else going on? Or if we don't care about that, why? If you have no idea, maybe check the "all" set of lowlevel-blt-bench if you can find unrelated operations slowing down for some obscure reason. I suppose could also see if adding the same amount of fast path table entries that will never match would cause the same slowdowns as this patch. Thanks, pq _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
