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 <[email protected]> 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 <[email protected]> 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev > > >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
