Re: [webkit-dev] LLInt without JIT

[Arunprasad Rajkumar]

Hello,

LLINT C Loop implementation is a pure JS interpretation mode, so you can't
enable along with JIT. But LLINT with assembly back-end is intended to have
both JIT(baseline & DFG) and interpreter mode simultaneously. The main goal
of LLINT assembly backend is for JIT emulation, so that code running in JIT
can easily fallback(vice versa) to interpreter mode with less or no cost
and also to have a triple tier virtual machine.

PSB, "Filip Pizlo" explained about this very nicely in the current email
thread :)

Regards,
Arun

On 13 March 2013 23:35, Gabor Rapcsanyi  wrote:

>  Hello!
>
> I tried to compile JSC with LLInt CLoop backend and JIT but it didn't work
> for me. I tried it on Mac and Linux as well.
> When I looked into it a little I saw some strange guards like this:
>
> Source/JavaScriptCore/llint/LLIntOpcode.h
>
> #if ENABLE(LLINT_C_LOOP)
>
> #define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
> macro(getHostCallReturnValue, 1) \
> macro(ctiOpThrowNotCaught, 1)
>
> #else // !ENABLE(LLINT_C_LOOP)
>
> #define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
> // Nothing to do here. Use the JIT impl instead.
>
> #endif // !ENABLE(LLINT_C_LOOP)
>
>
> It seems if we have CLoop we don't have JIT.
> So is this configuration supported anyway or we just want to use CLoop
> backend if we don't have JIT support?
>
> Regards,
>   -Gabor
>
>
>  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  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
>>

Re: [webkit-dev] LLInt without JIT

[Gabor Rapcsanyi]

Hello!

I tried to compile JSC with LLInt CLoop backend and JIT but it didn't 
work for me. I tried it on Mac and Linux as well.

When I looked into it a little I saw some strange guards like this:

Source/JavaScriptCore/llint/LLIntOpcode.h

#if ENABLE(LLINT_C_LOOP)

#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
macro(getHostCallReturnValue, 1) \
macro(ctiOpThrowNotCaught, 1)

#else // !ENABLE(LLINT_C_LOOP)

#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
// Nothing to do here. Use the JIT impl instead.

#endif // !ENABLE(LLINT_C_LOOP)


It seems if we have CLoop we don't have JIT.
So is this configuration supported anyway or we just want to use CLoop 
backend if we don't have JIT support?


Regards,
  -Gabor



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 > 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 mail

Re: [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  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  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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] LLInt without JIT

[Filip Pizlo]

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  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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] LLInt without JIT

[Fritz Koenig]

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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev