> On Nov 26, 2014, at 10:36 AM, Baldeva, Arpit <[email protected]> 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:[email protected]] > 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 <[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 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]> 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
