On Tue, 14 Jul 2015 11:41:25 +0300 Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Thu, 2 Jul 2015 13:04:11 +0300 > Oded Gabbay <oded.gab...@gmail.com> 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 <oded.gab...@gmail.com> > > Acked-by: Siarhei Siamashka <siarhei.siamas...@gmail.com> > 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 Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
