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 <guijem...@igalia.com> wrote: > > Quoting Filip Pizlo (2018-02-19 14:17:44) >> >> On Feb 19, 2018, at 11:43 AM, Guillaume Emont <guijem...@igalia.com> >> wrote: >> >> Quoting Filip Pizlo (2018-02-19 13:05:27) >> >> >> >> On Feb 19, 2018, at 10:53 AM, Guillaume Emont >> <guijem...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
