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 <[email protected]> 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:[email protected]] > Sent: Monday, November 24, 2014 8:19 AM > To: Baldeva, Arpit > Cc: [email protected] > Subject: Re: [webkit-dev] asm.js optimization path? > > > > On Nov 24, 2014, at 7:56 AM, Baldeva, Arpit <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.webkit.org/mailman/listinfo/webkit-dev > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
