[webkit-dev] asm.js optimization path?

[Filip Pizlo]

> On Nov 26, 2014, at 10:36 AM, Baldeva, Arpit <abaldeva at ea.com> wrote:
> 
> Thanks for the detailed response.
>  
> I talked to some other people in our organization (actual users of our webkit port) and they mentioned even the baseline JIT is at least twice as fast for their use case (I understand that benchmarks like Sunspider are much more faster than 2x with JIT support). That is very significant compared to LLInt. As we do not have ability to do runtime JIT,  is it “easy” to just plug in pre-generated baseline JIT code if we can pre-generate them for some JavaScript?

Short answer: it's not possible. 

Long answer: This is remotely doable but it would be a significant undertaking. It would be a rewrite of the most complex part of the JIT (the online caching). 

A lot of the baseline JIT's performance comes from run-time code patching inside our inline cache code. That is, the code that is initially generated is incomplete and we patch it based on runtime information after the code is already running. This involves directly patching in pointers to heap objects. So, if you tried to generate the code ahead of time, you'd need a really comprehensive "linking" story for either making this patching happen somehow or by finding a way to avoid it. I don't know how to fool a system linker into doing this patching, particularly since system linkers run more eagerly than when this patching is supposed to happen. We want to patch after at least one execution of the subject code.

If you tried to avoid the patching entirely then you'd probably get worse performance than the LLInt, so I don't recommend that route. 

Otoh, if you improve the LLInt's inline caching as I recommended, you'd probably see very real speedups. I wouldn't expect a 2x speedup, but then again, I wouldn't be terrible surprised if you ended up with 2x if your workload happens to do the kinds of property accesses that the LLInt's online caches currently don't support. 

>  
> It was also mentioned that Google’s closure compiler can actually do optimizations similar to some of the following suggestions and they saw significant performance boost in some scenarios as a result. Obviously, having it in the engine is always nice to have so I don’t question the need for these optimizations on JavaScriptCore side.
> Thanks
> Arpit
>  
> From: Filip Pizlo [mailto:fpizlo at apple.com] 
> Sent: Tuesday, November 25, 2014 3:24 PM
> To: Baldeva, Arpit
> Cc: WebKit Development
> Subject: Re: [webkit-dev] asm.js optimization path?
>  
> It's definitely possible to make the LLInt faster.  I don't think that type inference would necessarily do it.  But I think that cold-hearted engineering might do it.  We would certainly be happy to review patches that make the LLInt faster.
>  
> I would recommend profiling where you spend your time when running in LLInt mode.  I suspect that the following areas could be improved:
>  
> - Inlining the fast paths for typed array access.
> - Inline caching for prototype accesses.
> - Inline caching for polymorphic accesses.
>  
> I could also imagine a strategy that involves fusing some common bytecode ops.  Traditionally one of the highest sources of overhead in an interpreter is dispatch from one instruction to the next.  Here's a made up example where fusing would be profitable: say you found that your program was doing a lot of op_mul's followed by op_add's.  Then you would likely benefit from an op_muladd, because no you'd have one fewer instruction dispatches on a hot path.  I don't believe anyone has done this kind of investigation, but it might be worth doing, and if we found that there were a handful (maybe less than 20?) of super common idioms, then we could consider fusing those.  This would be both a bytecode transformation and a change to the LLInt itself.  You'd also then have to change the other execution engines to know how to handle those fused ops.
>  
> -Filip
>  
>  
> On Nov 25, 2014, at 3:10 PM, Baldeva, Arpit <abaldeva at ea.com> wrote:
>  
> Okay. Thanks for the input.
>  
> Let me ask a slightly different question (let me know if this should be a different thread). As background info, we are trying to optimize JavaScript execution without JIT support. Due to security restrictions by First Party, we are not allowed to JIT the JavaScript on some platforms. So we are looking for ideas on how to optimize runtime performance.
>  
> One of the idea we have had internally was what if we could AOT compile normal JavaScript (not same as asm.js) that we do not intend to update. I looked athttp://trac.webkit.org/wiki/JavaScriptCore which mentions that type inference/profiling happens in the LLInt/Baseline JIT tier and used in DFG JIT layer. Would it be a bad idea to move/use the type inference in LLInt layer? What if such thing was possible, we preload our JS and make it run say few thousand times before actual execution need (so that we get better performance)?
>  
> Is there any other idea we can pursue for better performance by just using LLInt layer? Or the general thought process is that if you want better javascript performance, JIT support is expected.
>  
> Thanks
> Arpit  
>  
>  
>  
> From: Filip Pizlo [mailto:fpizlo at apple.com] 
> Sent: Monday, November 24, 2014 8:19 AM
> To: Baldeva, Arpit
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] asm.js optimization path?
>  
>  
> 
> On Nov 24, 2014, at 7:56 AM, Baldeva, Arpit <abaldeva at ea.com> wrote:
> 
> Hi,
>  
> I was wondering if JavaScriptCore community ever considered adding optimization path for asm.js (http://asmjs.org/ ) ? I searched webkit bugzilla and did not find any relevant discussions.
>  
> Any opinions in favor/against it? 
>  
> We strive to optimize the full JavaScript language rather than a subset. 
>  
> I would be opposed to any change in this strategy. 
>  
> -Filip
> 
> 
> 
>  
> Thanks
> Arpit
> _______________________________________________
> 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: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141126/d0c52f3e/attachment.html>