<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">I would recommend profiling where you spend your time when running in LLInt mode. I suspect that the following areas could be improved:</div><div class=""><br class=""></div><div class="">- Inlining the fast paths for typed array access.</div><div class="">- Inline caching for prototype accesses.</div><div class="">- Inline caching for polymorphic accesses.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-Filip</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 25, 2014, at 3:10 PM, Baldeva, Arpit <<a href="mailto:abaldeva@ea.com" class="">abaldeva@ea.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class="">Okay. Thanks for the input.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class="">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.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class="">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 at<a href="http://trac.webkit.org/wiki/JavaScriptCore" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://trac.webkit.org/wiki/JavaScriptCore</a><span class="Apple-converted-space"> </span>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)?<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class="">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.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class="">Thanks<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class="">Arpit <o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(31, 73, 125);" class=""> </span></div><div class=""><div style="border-style: solid none none; border-top-color: rgb(225, 225, 225); border-top-width: 1pt; padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>Filip Pizlo [<a href="mailto:fpizlo@apple.com" class="">mailto:fpizlo@apple.com</a>]<span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Monday, November 24, 2014 8:19 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Baldeva, Arpit<br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [webkit-dev] asm.js optimization path?<o:p class=""></o:p></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""> </span></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><br class="">On Nov 24, 2014, at 7:56 AM, Baldeva, Arpit <<a href="mailto:abaldeva@ea.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">abaldeva@ea.com</a>> wrote:<o:p class=""></o:p></p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Hi,<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I was wondering if JavaScriptCore community ever considered adding optimization path for asm.js (<a href="http://asmjs.org/" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://asmjs.org/</a><span class="Apple-converted-space"> </span>) ? I searched webkit bugzilla and did not find any relevant discussions.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Any opinions in favor/against it?<span class="Apple-converted-space"> </span><o:p class=""></o:p></div></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class=""> </span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class="">We strive to optimize the full JavaScript language rather than a subset. <o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class=""> </span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class="">I would be opposed to any change in this strategy. <o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class=""> </span></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class="">-Filip<o:p class=""></o:p></span></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class=""><br class=""><o:p class=""></o:p></span></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thanks<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Arpit<o:p class=""></o:p></div></div></blockquote><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class="">_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">webkit-dev@lists.webkit.org</a><br class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a></span></div></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>