[webkit-dev] [jsc-dev] Proposal: Using LLInt Asm in major architectures even if JIT is disabled
Filip Pizlo
fpizlo at apple.com
Thu Sep 20 08:56:45 PDT 2018
I think that we should move to removing JSVALUE32_64, since it doesn’t get significant testing or maintenance anymore. I’d love it if 32-bit targets used the cloop with JSVALUE64, so that we can rip out the 32-bit jit and offlineasm backends, and remove the 32-bit representation code from the runtime.
I’m fine with using asm llint on 64-bit platforms, but using it on 32-bit platforms seems like it’ll be short lived.
-Filip
> On Sep 20, 2018, at 12:00 AM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:
>
> I've just set up MacBook Pro to measure the effect on macOS.
>
> The results are the followings.
>
> VMs tested:
> "baseline" at /Users/yusukesuzuki/dev/WebKit/WebKitBuild/nojit/Release/jsc
> "patched" at /Users/yusukesuzuki/dev/WebKit/WebKitBuild/nojit-llint/Release/jsc
>
> Collected 2 samples per benchmark/VM, with 2 VM invocations per benchmark. Emitted a call to gc() between sample
> measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
> function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
> milliseconds.
>
> baseline patched
>
> ai-astar 1738.056+-49.666 ^ 1568.904+-44.535 ^ definitely 1.1078x faster
> audio-beat-detection 1127.677+-15.749 ^ 972.323+-23.908 ^ definitely 1.1598x faster
> audio-dft 942.952+-107.209 919.933+-310.247 might be 1.0250x faster
> audio-fft 985.489+-47.414 ^ 796.955+-25.476 ^ definitely 1.2366x faster
> audio-oscillator 967.891+-34.854 ^ 801.778+-18.226 ^ definitely 1.2072x faster
> imaging-darkroom 1265.340+-114.464 ^ 1099.233+-2.372 ^ definitely 1.1511x faster
> imaging-desaturate 1737.826+-40.791 ? 1749.010+-167.969 ?
> imaging-gaussian-blur 7846.369+-52.165 ^ 6392.379+-1025.168 ^ definitely 1.2275x faster
> json-parse-financial 33.141+-0.473 33.054+-1.058
> json-stringify-tinderbox 20.803+-0.901 20.664+-0.717
> stanford-crypto-aes 401.589+-39.750 376.622+-12.111 might be 1.0663x faster
> stanford-crypto-ccm 245.629+-45.322 228.013+-8.976 might be 1.0773x faster
> stanford-crypto-pbkdf2 941.178+-28.744 864.462+-60.083 might be 1.0887x faster
> stanford-crypto-sha256-iterative 299.988+-47.729 270.849+-32.356 might be 1.1076x faster
>
> <arithmetic> 1325.281+-2.613 ^ 1149.584+-75.875 ^ definitely 1.1528x faster
>
> Interestingly, the improvement is not so large. In Linux box, it was 2x. But in macOS, it is 15%.
> But I think it is very nice if we can get 15% boost without any drawbacks.
>
>> On Thu, Sep 20, 2018 at 3:08 PM Saam Barati <sbarati at apple.com> wrote:
>> Interesting! I must have not run this experiment correctly when I did it.
>>
>> - Saam
>>
>>> On Sep 19, 2018, at 7:31 PM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:
>>>
>>>> On Thu, Sep 20, 2018 at 12:54 AM Saam Barati <sbarati at apple.com> wrote:
>>>> To elaborate: I ran this same experiment before. And I forgot to turn off the RegExp JIT and got results similar to what you got. Once I turned off the RegExp JIT, I saw no perf difference.
>>>
>>> Yeah, I disabled JIT and RegExpJIT explicitly by using
>>>
>>> export JSC_useJIT=false
>>> export JSC_useRegExpJIT=false
>>>
>>> and I checked no JIT code is generated by running dumpDisassembly. And I also put `CRASH()` in ExecutableAllocator::singleton() to ensure no executable memory is allocated.
>>> The result is the same. I think `useJIT=false` disables RegExp JIT too.
>>>
>>> baseline patched
>>>
>>> ai-astar 3499.046+-14.772 ^ 1897.624+-234.517 ^ definitely 1.8439x faster
>>> audio-beat-detection 1803.466+-491.965 970.636+-428.051 might be 1.8580x faster
>>> audio-dft 1756.985+-68.710 ^ 954.312+-528.406 ^ definitely 1.8411x faster
>>> audio-fft 1637.969+-458.129 850.083+-449.228 might be 1.9268x faster
>>> audio-oscillator 1866.006+-569.581 ^ 967.194+-82.521 ^ definitely 1.9293x faster
>>> imaging-darkroom 2156.526+-591.042 ^ 1231.318+-187.297 ^ definitely 1.7514x faster
>>> imaging-desaturate 3059.335+-284.740 ^ 1754.128+-339.941 ^ definitely 1.7441x faster
>>> imaging-gaussian-blur 16034.828+-1930.938 ^ 7389.919+-2228.020 ^ definitely 2.1698x faster
>>> json-parse-financial 60.273+-4.143 53.935+-28.957 might be 1.1175x faster
>>> json-stringify-tinderbox 39.497+-3.915 38.146+-9.652 might be 1.0354x faster
>>> stanford-crypto-aes 873.623+-208.225 ^ 486.350+-132.379 ^ definitely 1.7963x faster
>>> stanford-crypto-ccm 538.707+-33.979 ^ 285.944+-41.570 ^ definitely 1.8840x faster
>>> stanford-crypto-pbkdf2 1929.960+-649.861 ^ 1044.320+-1.182 ^ definitely 1.8481x faster
>>> stanford-crypto-sha256-iterative 614.344+-200.228 342.574+-123.524 might be 1.7933x faster
>>>
>>> <arithmetic> 2562.183+-207.456 ^ 1304.749+-312.963 ^ definitely 1.9637x faster
>>>
>>> I think this result is not related to RegExp JIT since ai-astar is not using RegExp.
>>>
>>> Best regards,
>>> Yusuke Suzuki
>>>
>>>>
>>>> - Saam
>>>>
>>>>> On Sep 19, 2018, at 8:53 AM, Saam Barati <sbarati at apple.com> wrote:
>>>>>
>>>>> Did you turn off the RegExp JIT?
>>>>>
>>>>> - Saam
>>>>>
>>>>>> On Sep 18, 2018, at 11:23 PM, Yusuke Suzuki <yusukesuzuki at slowstart.org> wrote:
>>>>>>
>>>>>> Hi WebKittens!
>>>>>>
>>>>>> Recently, node-jsc is announced[1]. When I read the documents of that project,
>>>>>> I found that they use LLInt ASM interpreter instead of CLoop in non-JIT environment.
>>>>>> So I had one question in my mind: How fast the LLInt ASM interpreter when comparing to CLoop?
>>>>>>
>>>>>> I've set up two builds. One is CLoop build (-DENABLE_JIT=OFF) and another is JIT build JSC with `JSC_useJIT=false`.
>>>>>> And I've ran kraken benchmarks with these two builds in x64 Linux machine. The results are the followings.
>>>>>>
>>>>>> Benchmark report for Kraken on sakura-trick.
>>>>>>
>>>>>> VMs tested:
>>>>>> "baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit/Release/bin/jsc
>>>>>> "patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit-llint/Release/bin/jsc
>>>>>>
>>>>>> Collected 10 samples per benchmark/VM, with 10 VM invocations per benchmark. Emitted a call to gc() between sample
>>>>>> measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
>>>>>> function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
>>>>>> milliseconds.
>>>>>>
>>>>>> baseline patched
>>>>>>
>>>>>> ai-astar 3619.974+-57.095 ^ 2014.835+-59.016 ^ definitely 1.7967x faster
>>>>>> audio-beat-detection 1762.085+-24.853 ^ 1030.902+-19.743 ^ definitely 1.7093x faster
>>>>>> audio-dft 1822.426+-28.704 ^ 909.262+-16.640 ^ definitely 2.0043x faster
>>>>>> audio-fft 1651.070+-9.994 ^ 865.203+-7.912 ^ definitely 1.9083x faster
>>>>>> audio-oscillator 1853.697+-26.539 ^ 992.406+-12.811 ^ definitely 1.8679x faster
>>>>>> imaging-darkroom 2118.737+-23.219 ^ 1303.729+-8.071 ^ definitely 1.6251x faster
>>>>>> imaging-desaturate 3133.654+-28.545 ^ 1759.738+-18.182 ^ definitely 1.7808x faster
>>>>>> imaging-gaussian-blur 16321.090+-154.893 ^ 7228.017+-58.508 ^ definitely 2.2580x faster
>>>>>> json-parse-financial 57.256+-2.876 56.101+-4.265 might be 1.0206x faster
>>>>>> json-stringify-tinderbox 38.470+-2.788 ? 38.771+-0.935 ?
>>>>>> stanford-crypto-aes 851.341+-7.738 ^ 485.438+-13.904 ^ definitely 1.7538x faster
>>>>>> stanford-crypto-ccm 556.133+-6.606 ^ 264.161+-3.970 ^ definitely 2.1053x faster
>>>>>> stanford-crypto-pbkdf2 1945.718+-15.968 ^ 1075.013+-13.337 ^ definitely 1.8099x faster
>>>>>> stanford-crypto-sha256-iterative 623.203+-7.604 ^ 349.782+-12.810 ^ definitely 1.7817x faster
>>>>>>
>>>>>> <arithmetic> 2596.775+-14.857 ^ 1312.383+-8.840 ^ definitely 1.9787x faster
>>>>>>
>>>>>> Surprisingly, LLInt ASM interpreter is significantly faster than CLoop. I expected it would be fast, but it would show around 10% performance win.
>>>>>> But the reality is that it is 2x faster. It is too much number to me to consider enabling LLInt ASM interpreter for non-JIT build configuration.
>>>>>> As a bonus, LLInt ASM interpreter offers sampling profiler support even in non-JIT environment.
>>>>>>
>>>>>> So my proposal is, how about enabling LLInt ASM interpreter in non-JIT configuration environment in major architectures (x64 and ARM64)?
>>>>>>
>>>>>> Best regards,
>>>>>> Yusuke Suzuki
>>>>>>
>>>>>> [1]: https://lists.webkit.org/pipermail/webkit-dev/2018-September/030140.html
>>>>>> _______________________________________________
>>>>>> webkit-dev mailing list
>>>>>> webkit-dev at lists.webkit.org
>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>> _______________________________________________
>>>>> jsc-dev mailing list
>>>>> jsc-dev at lists.webkit.org
>>>>> https://lists.webkit.org/mailman/listinfo/jsc-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180920/a46fe9d4/attachment.html>
More information about the webkit-dev
mailing list