[llvm-dev] WebKit B3 (was LLVM Weekly - #110, Feb 8th 2016)
Andrew Trick via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 17 09:12:01 PST 2016
> On Feb 16, 2016, at 8:28 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> On 16 Feb 2016, at 15:47, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> Can you say anything about the reasoning for having both? Do you see warmish code that the splat compiler is worthwhile? I'm used to interpreters and splat compilers being positioned as an either-or choice. When do you decide to promote something to the splat compiler, but not the "tier 3” compiler?
I’m not a WebKit developer either, but I think David’s explanation is right on the mark. A JVM would not typically bother with both.
> The baseline JIT is around an order of magnitude faster than the interpreter, but consumes memory for the generated code and does not give a user-noticeable speedup for code that is executed only once. The baseline JIT and the interpreter both use the same stack layout (this was one of the motivations for replacing the old C++ interpreter with one written in JSC’s custom macro assembly), so it’s comparatively cheap to move from the interpreter to the baseline JIT.
> Finally, WebKit / JSC runs on a lot of mobile devices (iPhones up to MacBooks Pro) where power consumption is a vital design consideration. It is very important in these situations not to speculatively burn cycles optimising code where the user won’t notice the difference, because they will notice if their battery doesn’t last as long.
> These constraints don’t exist in server workloads and are even quite rare on the desktop. Few people care if their desktop app takes a couple of seconds to start (and, if they do, they won’t mind if the second time it starts a lot faster because it has cached the generated code). If a web page takes a couple of seconds to load, then a lot of people will close the tab before it finishes.
>  https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
More information about the llvm-dev