[webkit-dev] Disabling the 32-bit JITs by default.

Mon Feb 19 17:12:47 PST 2018

Quoting Filip Pizlo (2018-02-19 14:17:44)
> 
>     On Feb 19, 2018, at 11:43 AM, Guillaume Emont <guijemont at igalia.com> wrote:
> 
>     Quoting Filip Pizlo (2018-02-19 13:05:27)
> 
> 
> 
>             On Feb 19, 2018, at 10:53 AM, Guillaume Emont <guijemont at igalia.com
>             > wrote:
> 
>             Hi Keith,
> 
>             We at Igalia have been trying to provide a better story for 32-bit
>             platforms, in particular for Armv7 and MIPS. These platforms are
>             very
>             important to us, and disabling JIT renders many use cases
>             impossible.
> 
> 
>         What use cases?
> 
> 
>     I'm not sure of how much I can elaborate here, but in this particular
>     case that was for a set-top-box UI.
> 
> 
> I bet that this doesn’t need a JIT.

I have measured performances in a set top box UI a few months ago on a
mips device: in a typical use case provided by our client, I got 24 fps
wit JIT+DFG, vs 6 fps without it. In that use case, having the JIT makes
the difference between unusable and usable.

> 
> If you want me to believe that it does, you need to show perf numbers.

Apart from the above, I can also run some benchmarks. Are there specific
ones that you think matter more for this discussion? I have 2 mips
devices as well as a raspberry pi 2 on which I can run benchmarks.

In the meantime, I quickly ran v8spider on a ci20 mips board on r228714.
The NoJIT scenario was run with the same binary with JSC_useJIT=false, I
guess the difference could be bigger if we were comparing to cloop.

--- v8-spider on mips ---
                          NoJIT                      JIT                                        

crypto            11725.5325+-71.7021    ^   1830.4683+-6.8751        ^ definitely 6.4058x faster
deltablue         38857.3603+-189.8530   ^   2871.5320+-28.7077       ^ definitely 13.5319x faster
earley-boyer      13350.8512+-106.0597   ^   1775.7125+-4.0989        ^ definitely 7.5186x faster
raytrace           7894.6098+-33.3069    ^   2084.4858+-37.9436       ^ definitely 3.7873x faster
regexp             4055.1053+-120.4037   ^   2273.6319+-44.3103       ^ definitely 1.7835x faster
richards          36003.5590+-322.8705   ^   2108.9879+-46.2061       ^ definitely 17.0715x faster
splay              6936.2468+-24.3808    ^   1088.6877+-12.1142       ^ definitely 6.3712x faster

<geometric>       12534.9214+-43.8771    ^   1934.9295+-5.2966        ^ definitely 6.4782x faster

------

I ran the same on x86_64, and we see that for this benchmark, the
average JIT speedup is actually less than on mips:

--- v8-spider on x86_64 ---
                          NoJIT                      JIT                                        

crypto              758.9786+-2.7148     ^     83.2100+-17.1005       ^ definitely 9.1212x faster
deltablue          1330.8087+-149.0367   ^    120.3405+-15.2389       ^ definitely 11.0587x faster
earley-boyer        575.8073+-44.5565    ^     90.5132+-15.6952       ^ definitely 6.3616x faster
raytrace            322.8087+-8.4965     ^     58.8531+-2.7943        ^ definitely 5.4850x faster
regexp              191.0544+-2.1591     ^    131.5052+-35.2153       ^ definitely 1.4528x faster
richards           1439.3209+-117.4325   ^    100.1944+-4.8524        ^ definitely 14.3653x faster
splay               279.3245+-7.1500     ^     97.1257+-17.8935       ^ definitely 2.8759x faster

<geometric>         545.4854+-13.2273    ^     94.3486+-5.6174        ^ definitely 5.7816x faster

------

> 
>         I realize that having a JIT is good for marketing, but it’s better to
>         have a stable and well-maintained interpreter than a decrepit JIT.
>          Right now the 32-bit JIT is basically unmaintained.
> 
> 
>     Indeed these platforms used to be practically abandoned in WebKit. I
>     don't think that is true any more though. We've been working on fixing
>     this and getting mips32 and armv7+thumb2 to pass all the tests. We have
>     achieved that for mips32[1] and we are almost there for armv7[2]. I
>     would appreciate it if you could acknowledge that effort.
> 
>     [1] https://build.webkit.org/builders/JSCOnly%20Linux%20MIPS32el%20Release
>     [2] https://build.webkit.org/builders/
>     JSCOnly%20Linux%20ARMv7%20Thumb2%20Release
> 
> 
> Passing all of the tests does not constitute stability in my book.  You need a
> lot of people using the JIT in anger for a while before you can be sure that
> you did it right.

We happen to have a lot of users on these platforms. We want to bring
their trees closer to upstream, which we think would be better for
everyone. Improving the support on these platforms can also bring more
users and help create and maintain a virtuous circle.

> 
> Also, you need to prove that the JIT is actually a progression.  Last time we
> had such a conversation, you guys had perf regressions from enabling the JIT.
>  So, use cases that needed perf would have been better off with the
> interpreter.

I think you are referring to the armv6 discussion. Indeed the speedup on
armv6 was smaller (I think Caio might have improved that later on), but
the speedups on mips and armv7 are far bigger (see v8spider results
above), and do not have regressions vs no jit.

> 
>             We
>             want to continue this effort to support these platforms. We have
>             been
>             short on resources for that effort, which is why we did not realize
>             early enough that more mitigation was needed for 32-bit platforms.
>             We
>             now have grown our team dedicated to this and we are hopeful that
>             we
>             will avoid that kind of issue in the future.
> 
> 
>         I feel like I’ve heard this exact story before.  Every time we say that
>         there isn’t any effort going into 32-bit, y’all say that you’ll put
>         more effort into it Real Soon Now.  And then nothing happens, and we
>         have the same conversation in 6 months.
> 
> 
>     I'm sorry it took us time to grow our team for this purpose, but that is
>     now a reality since the beginning of this month.
> 
> 
> I’ve heard this before.
> 
> 
>     And beside that, I
>     think you can agree that there has been significant progress on that
>     aspect, we were very far from having a green tree on mips32 about a year
>     ago, when we still had hundreds of test failures.
> 
> 
> I don’t agree that there has been significant progress.  The level of
> maintenance going into those JITs is a rounding error compared to how much work
> is done on ARM64 and x86_64.

I would be happy if we can try to make this discussion productive.
Could you provide clear expectations for you to consider these platforms
to be properly maintained in the future, and so that our contributions
outweigh the burden for you and your team?

We don't want to hinder the development of WebKit. We want to keep it
the awesome Open Source project that it is, with cooperation between
different ports, platforms and use cases. We don't want to be against
you, we want to work with you, like we have been doing for years in our
various contributions to WebKit, and we want this to continue for many
years and to include contributions to JavaScriptCore.

Best regards,

Guillaume