[webkit-dev] Disabling the 32-bit JITs by default.
Filip Pizlo
fpizlo at apple.com
Mon Feb 19 18:58:31 PST 2018
Would this be acceptable:
- 32-bit JIT gets disabled on macOS, iOS, and our Windows port, so those JITs get no testing on those platforms.
- code can stay in trunk so long as someone has a bot for it (we won’t).
- someone will have to step up to maintain the 32-bit JITs - like MIPS and ARMv6, we won’t keep them building or working.
How does that sound?
-Filip
> On Feb 19, 2018, at 5:12 PM, Guillaume Emont <guijemont at igalia.com> wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180219/d935d8be/attachment.html>
More information about the webkit-dev
mailing list