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?
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:fpi...@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 <abald...@ea.com<mailto:abald...@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:fpi...@apple.com] Sent: Monday, November 24, 2014 8:19 AM To: Baldeva, Arpit Cc: webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] asm.js optimization path? On Nov 24, 2014, at 7:56 AM, Baldeva, Arpit <abald...@ea.com<mailto:abald...@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@lists.webkit.org<mailto: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
