On 10/12/2012 11:23 AM, Tom Hudson wrote:
Do you have particular bottleneck functions that you have reason to
believe would benefit from ARM SIMD optimizations? Under what
workloads, and how much benefit?

We've see a few ridiculously expensive transform functions in WebKit
that my colleagues in Chapel Hill might be able to recall, but usually
it's the rendering engines that are hot, not WebKit itself.
Yes, you're right that the rendering engine is usually the basic bottleneck,
but why shouldn't we optimize WebKit where it is possible.
For example the function what you asking is TransformationMatrix::multiply(). I made a test which could be speed up with optimizing this matrix multiplication.
I uploaded here: https://bugs.webkit.org/show_bug.cgi?id=98913
We have seen places where double math appears to be absolutely
required for correctness: matrix inversion and path convexity testing;
there are some other areas we're experimenting with that seem to
require it as well. You'd probably need to survey WebKit for stability
(or just hack in doubles and run layout tests) to see how many other
places will break if you throw away the extra precision.
I tried it in the Qt port and there were just a few (47) layout fails with
0.0 and -0.0 problems and one or two pixel differences. But we need more
investigations here.
The rest of Chromium's renderer (Skia) uses float, and we've deployed
SSE/NEON and played with float vs double quite a bit there. The
float->double conversion at the WebKit/Skia boundary doesn't seem to
be too much of a drag, but doing it in any sort of inner loop can
really kill performance.

Meanwhile, there are a lot of places where switching from ARM assembly
to NEON in the renderer hasn't given us as much win as we'd hoped for,
which is why the question "how much benefit?" seems important to
answer before spending too much time polishing a set of typedefs.

I can say the same as above. If there is a way to optimize WebKit,
but the benefit is just a half or one percent on an avrage page now
or maybe less, why shouldn't we do that, and of course on a specific
page/case we would benefit more.


On Fri, Oct 12, 2012 at 10:08 AM, Gabor Rapcsanyi
<rga...@inf.u-szeged.hu> wrote:
Yes I agree that we need to do some measures to see the benefits of floats.
But it's not just about the performance and memory gain of the floats, I
would like to make ARM SIMD optimizations for the transformation functions
to fasten up them, but ARM NEON technology only works with floats that's why
I want to change the doubles.
I would prefer a typedef solution to make this configurable as Ryosuke said,
and then the ports could chose whether they need floats, doubles or long

- Gabor

On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi <rga...@inf.u-szeged.hu>

That was a long time ago and there were no objections
Unless there's something in the spec requiring double precision it makes
sense to move away from double precision throughout WebKit.
I’m a little concerned about this.

The programming interface to the graphics system on OS X uses doubles, so
it’s likely we’ll be introducing float to double conversions for at least
that platform if we change things inside WebKit that are currently doubles
to float en masse.

Similarly, the native data type for numbers in JavaScript is double. So
any time we are passing a number from JavaScript to WebKit it’s likely that
additional double to float conversions will be required as we change
internals to use doubles instead of floats.

On the other hand, there may also be performance boost or memory gains
from using float instead of double.

If we do make this change, I think we need to do performance testing as we
do so, perhaps on more than one platform, to see if these changes are
leading to benefits or not.

I also think that “we should always use float unless a spec mandates
double” is probably not the right rule of thumb. There are many factors
other than “a spec” at play here.

-- Darin

webkit-dev mailing list

webkit-dev mailing list

Reply via email to