On Wed, 15 Jul 2015 15:41:19 +0300 Oded Gabbay <[email protected]> wrote:
> >> > Or if we don't care about that, why? > >> I think that the speedups in this specific patch are more substantial > >> than the slowdowns. If it was the other way around, than I would have > >> removed this patch, like I did with another patch, which Siarhei > >> rejected because of it. > > > > But in theory, you should not get any slowdowns, right? Or did you > > actually expect that some things will slow down? > I'm not so sure I won't get any slowdowns. I guess it depends on the > size of the image and the amount of alignment that needs to be done > for that image > > e.g. if we have many small images, and for each image we need to do > unaligned operations first to make sure we are 16-bytes aligned, then > the unaligned operations may take more cycles then the cycles that are > saved from doing the vmx operations. There could be extreme cases, > where there is one vmx operation on aligned data and all the rest of > the operations are unaligned. Now, in the C implementation, you don't > care about unalignment, so you always work in 4 byte quanitites. > > Does that make sense ? Yeah, this kind of speculation is what I'm after. A plausible and acceptable reason why some things may slow down. I suppose I'm too new here to understand that without pointing it out. However, I think lowlevel-blt-bench's tests should be hitting some of those ugly tiny image cases, yet even the worst case there has +22% performance. Of course, it's possible that Cairo benchmarks happen to hit the ugly tiny images consistently badly, while llbb aims to cover all kinds of alignment equally. It's all up to judgement, but I think one does need to at least ask the question "This is slightly odd... is something actually wrong?" I and Ben definitely did find something very strange about the Raspberry Pi 1 CPU. Thanks, pq _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
