[webkit-dev] asm.js optimization path?

[Filip Pizlo]

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 <http://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 <mailto:abaldeva at ea.com>> wrote:
> 
> Hi,
>  
> I was wondering if JavaScriptCore community ever considered adding optimization path for asm.js (http://asmjs.org/ <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 <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141125/31781dae/attachment.html>