On Monday 29 November 2010 20:59:52 Siarhei Siamashka wrote: > On Wednesday 17 November 2010 07:47:39 Xu, Samuel wrote: > > For MOVD, we simplified the backward copy code since pervious code is too > > long and not gain obvious performance, > > And this is what I'm worried about. First you proposed this part of code > (backwards copy) without providing any initial explanation or benchmark > numbers. And now you abandon it, also without providing any benchmark > numbers or description of your test. But because you still have x86 > instructions there instead of MOVD, store forwarding aliasing surely may > affect performance, as demonstrated by my simple test program posted > earlier [3] as part of the discussion. > > Can we be sure that this SSSE3 patch actually provides any practical > performance improvement over the current pixman code? Considering that > compared to your initial profiling data, now SSE2 optimized code is used > for this operation and also problematic software prefetch which was almost > halving [4] effective memory bandwidth for this operation is now > eliminated [5].
> Surely, using 'test/lowlevel-blt-bench' microbenchmark it showed good > improvement for L1 cached data. But on the other hand, performance of small > random operations has dropped (shown as 'R' statistics). Maybe that's > happening because of the scanline function call overhead and this fwd/bwd > special handling for small buffer sizes? So a final verification with some > real practical use case would be interesting. > > [...] > > 1. http://www.mail-archive.com/pixman@lists.freedesktop.org/msg00357.html > 2. http://www.mail-archive.com/pixman@lists.freedesktop.org/msg00378.html > 3. http://www.mail-archive.com/pixman@lists.freedesktop.org/msg00415.html > 4. http://www.mail-archive.com/pixman@lists.freedesktop.org/msg00404.html > 5. http://www.mail-archive.com/pixman@lists.freedesktop.org/msg00563.html Just did some benchmarks with the 'gnome-system-monitor' cairo perf trace which happens to use 'src_x888_8888' operation. It looks like SSSE3 has about the same performance as SSE2, providing no measurable benefits on this use case. The low complexity of this operation and the hardware prefetcher make any differences between implementations much less noticeable in general. Intel Atom N450, 64-bit userland, gcc 4.5.1 $ CAIRO_TEST_TARGET=image ./cairo-perf-trace gnome-system-monitor.trace ======= C slow path ========= [ # ] backend test min(s) median(s) stddev. count [ # ] image: pixman 0.21.3 [ 0] image gnome-system-monitor 15.011 15.034 0.08% 6/6 ======= C fast path [1] ========= [ # ] backend test min(s) median(s) stddev. count [ # ] image: pixman 0.21.3 [ 0] image gnome-system-monitor 14.659 14.697 0.20% 6/6 ======= SSE2 fast path [2] ===== [ # ] backend test min(s) median(s) stddev. count [ # ] image: pixman 0.21.3 [ 0] image gnome-system-monitor 14.431 14.496 0.19% 6/6 ======= SSSE3 fast path [3] ====== [ # ] backend test min(s) median(s) stddev. count [ # ] image: pixman 0.21.3 [ 0] image gnome-system-monitor 14.455 14.496 0.17% 6/6 ====== artificial test with just an empty stub for src_x888_8888 ======== [ # ] backend test min(s) median(s) stddev. count [ # ] image: pixman 0.21.3 [ 0] image gnome-system-monitor 12.215 12.241 0.11% 6/6 --- So I'm not sure if this SSE3 code is very useful as is. But of course, if some practical use case makes a heavy use of this function so that it works on the data residing in L1/L2 caches, then it could show a big improvement. 1. http://cgit.freedesktop.org/pixman/commit/?id=16bae834 2. http://cgit.freedesktop.org/pixman/commit/?id=e0b430a1 3. http://lists.freedesktop.org/archives/pixman/2010-November/000742.html -- Best regards, Siarhei Siamashka
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
