On Tue, Jan 4, 2011 at 10:22 AM, Siarhei Siamashka <[email protected]> wrote: > On Wednesday 08 December 2010 16:13:48 Liu Xinyun wrote: >> There is a performance test between commits >> commit 56777f3f675869806cd30bcd21a5b39d788507cb >> Author: Dmitri Vorobiev <[email protected]> >> Date: Wed Sep 22 12:34:57 2010 +0300 >> >> Use <sys/mman.h> macros only when they are available >> >> commit 3d094997b1820719d15cec7dc633ed37e1912bfc >> Author: Siarhei Siamashka <[email protected]> >> Date: Tue Nov 30 00:31:06 2010 +0200 >> >> Fix for potential unaligned memory accesses > > Right, if we look at the changes between these two commits: > >> new: ba69989374fe9cbe5151c5aac7b824da0806f94a >> Speedups >> ======== >> image-rgba ocitysmap-0 7476.29 (7520.52 3.09%) -> >> 6817.63 (6822.39 3.04%): 1.10x speedup ▏ >> image-rgba poppler-0 15028.69 (15029.97 0.71%) -> >> 13748.83 (13793.77 0.91%): 1.09x speedup ▏ >> image-rgba gnome-terminal-vim-0 23378.23 (23494.57 0.70%) -> >> 21916.17 (21926.92 0.52%): 1.07x speedup ▏ >> image-rgba xfce4-terminal-a1-0 16632.31 (16637.27 0.60%) -> >> 15630.85 (15650.89 0.63%): 1.06x speedup ▏ >> image-rgba firefox-planet-gnome-0 87751.74 (87809.43 0.18%) -> >> 82620.93 (82949.20 0.27%): 1.06x speedup >> >> image-rgba firefox-talos-gfx-0 51169.66 (51542.49 0.36%) -> >> 48572.45 (48610.13 0.26%): 1.05x speedup >> >> image-rgba swfdec-giant-steps-0 11619.84 (11646.91 0.46%) -> >> 11056.41 (11057.69 0.40%): 1.05x speedup > > Removal of software prefetch provides a good performance improvement. It was a > nice catch, thanks for that patch. But as a side effect, it also makes SSE2 > optimizations more competitive and somewhat harder to beat by SSSE3. > >> new: 1ca715ed1e6914e9bd9f050065e827d7a9e2efc9 >> Slowdowns >> ========= >> image-rgba firefox-talos-svg-0 177350.25 (181525.48 1.11%) -> >> 198170.08 (202124.06 0.96%): 1.12x slowdown ▏ >> image-rgba swfdec-youtube-0 15843.51 (15850.03 0.76%) -> >> 18104.51 (18224.94 0.40%): 1.14x slowdown ▏ > >> new: 1d4f2d71facd5f2bbce74fbe3407ccea6cf4bea1 >> Slowdowns >> ========= >> image-rgba firefox-talos-svg-0 197582.42 (202455.51 1.19%) -> >> 208636.52 (212057.02 0.90%): 1.06x slowdown > > And these two slowdowns are caused by the changes in radial gradients code. > I guess it can't be helped because now radial gradients are supposed to be > more > correct.
I'm quite confident that SIMD makes it possible to speed up the computation of the interpolation parameter of gradients (both linear and radial). If someone is interested in improving the performance of radial gradients, I can point out some transformations which remove basically all of the branching and make the computation very easy to perform in parallel. I already implemented them (the idea should be correct but they are untested) in: http://cgit.freedesktop.org/~ranma42/cairo/commit/?h=wip/gl2&id=5814ec1c2cec04c4e6cbb70ff2b24d8e157ff321 As a side note, if we want SIMD gradients, we should probably profile the gradient walker. I expect quite a lot of time to be spent there, at least for the linear gradients. Andrea PS: I'm guilty of the gradient slowdown, but on the good side it seems to be the best implementation of radial gradients available, surpassing in correctness and/or numerical stability Quartz, GhostScript, poppler, Adobe Reader, Acrobat Pro X... _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
