[webkit-dev] LLInt without JIT

[Fritz Koenig]

Awesome, thanks for the detailed response.

I did not realize that going to the assembly backend would not produce
a substantial improvement.  But after you explanation, I can see the
reasons.

I'll do some more testing to see the impact.  If I see it to
be worthwhile and I can fix it, I'll submit a patch, otherwise a bug.


On Fri, Mar 8, 2013 at 11:28 PM, Filip Pizlo <fpizlo at apple.com> wrote:

> Yes.  You can use the assembly LLInt backend without using the JIT.
>  That's how I was running it when I first wrote it.
>
> I think that the code in Platform.h is being conservative, in the sense
> that it assumes that if ENABLE(JIT) is not set then you're compiling for a
> target that the LLInt wouldn't have a backend for.  This makes sense, if
> you think about it: ENABLE_JIT is defined to 1 if we detect that we are on
> a hardware/OS configuration that the JIT knows how to handle, and the LLInt
> has backends for strictly fewer platforms than the JIT has backends for:
> JIT supports x86 (32 and 64), ARM (traditional and THUMB2), MIPS, and SH4;
> while the LLInt currently only supports x86 (32 and 64), ARM THUMB2, and
> MIPS.  In short, requiring the JIT to use LLInt assembly backends is not a
> strong requirement of the LLInt; it's just an artifact of Platform.h's
> logic.
>
> On hardware/OS configurations where ENABLE(JIT) is set, and the LLInt is
> compiled to assembly, it is still possible to run with the JIT disabled.
> The JIT ends up being disabled at run-time in that case. We often use this
> for testing - you can set the JSC_useJIT environment variable to 'false'
> and then you're running in a LLInt-only mode. This allows for quickly
> checking if a bug is due to the JITs, or not.
>
> But I would also note that the purpose of the LLInt assembly backends is
> _not_ performance of the LLInt itself, but for performance of the
> triple-tier system as a whole.  What those assembly backends give us is the
> ability to run the LLInt using the same ABI that the JSC JITs use; this in
> turn allows us to do two things: (1) zero-cost OSR from the LLInt to the
> baseline JIT, and (2) perform every JS function call assuming
> opportunistically that the callee has been JITed; if it isn't then the
> machine code entrypoint that the callee reports is just the shared LLInt
> entrypoint.  That entrypoint, in turn, doesn't really have to do anything
> special - it just loads the callee from the callee stack frame, loads the
> bytecode pointer from the callee, and indirect-jumps into the first
> bytecode instruction.  We wouldn't be able to do either (1) or (2) easily
> with a C (or C++) interpreter. I mean, we could do it, but JIT->interpreter
> calls would be more expensive (because of the need to set up a C
> interpreter stack frame). And OSR would take more effort - it wouldn't be
> possible for the LLInt to just jump straight into JITed code like it does
> now.
>
> In summary, I don't expect the LLInt cloop backend to be any slower than
> the LLInt assembly backends. Last I checked, it wasn't slower. I would
> assume that a decent C compiler will take the LLInt cloop code and do
> sufficient optimizations that it ends up generating roughly the same
> assembly code that the LLInt assembly backends generate. So, I wouldn't
> devote too much effort to switching from the cloop to the assembly backends
> unless you had evidence that (a) it would actually be faster on the
> benchmarks you care about; or (b) you wanted to take advantage of the
> LLInt's ability to rapidly tier-up to one of the JSC JITs. It is because of
> (b), not (a), that JSC's triple tier configuration uses the LLInt assembly
> backends instead of cloop.
>
> But if you have reason to believe that the LLInt assembly backends will be
> better for your purposes then I think all it will take is hacking
> Platform.h appropriately. If this turns out to be hard, then you should
> file a bug, or even better, I would love to see a patch from you to improve
> the logic in Platform.h to make this use case easier.
>
> Hope this helps!
>
> -Filip
>
>
>
> On Mar 8, 2013, at 4:59 PM, Fritz Koenig <frkoenig at google.com> wrote:
>
> LowLevelInterpreter.asm is processed to create LLIntAssembly.h for the
> built platform.  It appears that if there is no jitting configured[1], this
> will always create the C Loop.
>
> Is there any way of using the assembly backends to create LLIntAssembly.h
> when not jitting?
>
> [1]: Source/WTF/wtf/Platform.h:815 /* If the jit is not available, enable
> the LLInt C Loop: */
>  _______________________________________________
> 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/20130311/7841bb3d/attachment.html>