Re: [webkit-dev] asm.js optimization path?
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.commailto: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.orgmailto: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.commailto: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.orgmailto: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
Re: [webkit-dev] asm.js optimization path?
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 at 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:fpi...@apple.com] Sent: Monday, November 24, 2014 8:19 AM To: Baldeva, Arpit Cc: 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.commailto: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.orgmailto: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
[webkit-dev] asm.js optimization path?
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? Thanks Arpit ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] TextureMapperGL stencil bug?
Thanks. I created a bug here - https://bugs.webkit.org/show_bug.cgi?id=135483 and added some more info. The problem can be seen on the classic falling leaves demo. From: Byungseon Shin [mailto:xin...@gmail.com] Sent: Thursday, July 31, 2014 5:10 PM To: Darin Adler Cc: Baldeva, Arpit; WebKit Development Subject: Re: [webkit-dev] TextureMapperGL stencil bug? Please also refer to http://trac.webkit.org/changeset/108696. TextureMapperGL works stack based and endClip restores previous stack's clip state. -- Sun On Fri, Aug 1, 2014 at 1:18 AM, Darin Adler da...@apple.commailto:da...@apple.com wrote: Sounds like you’re probably right. The best way to prove it is to make a test case to demonstrate the problem. It looks like USE(TEXTURE_MAPPER_GL) is currently used as part of the GTK port, so the folks who maintain that port are the most likely to be interested. Please file a bug report http://www.webkit.org/quality/reporting.html. It’s OK to send mail the webkit-dev list if you want to discuss how to fix a bug, but it’s not polite to report a bug by sending mail instead of following the process from the website. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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
[webkit-dev] TextureMapperGL stencil bug?
Hi, Going through the TextureMapperGL implementation, I see that BeginClip advances the bit plane to the next clipStack().setStencilIndex(stencilIndex * 2); However, EndClip does not revert it back before calling clipStack().applyIfNeeded(m_context3D.get()); The applyIfNeeded disables stencil test only if stencilIndex is 1. if (clipState.stencilIndex == 1) context-disable(GraphicsContext3D::STENCIL_TEST); else context-enable(GraphicsContext3D::STENCIL_TEST); There is no place in the code that is attempting to reverse the impact of BeginClip. Isn't a right bit shift required in the EndClip call before the applyIfNeeded call? Otherwise, I don't see how EndClip will disable stenciling test ever. The problem is probably more obvious if you have nested clipping. Note - my observation is based simply on reading the code. Please correct me if I have missed something. Thanks Arpit ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?
Same here. We disable SVG for code size reasons as well. It would be nice to continue to have the top level define for that purpose. Thanks! -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Dan Minor Sent: Monday, September 12, 2011 7:07 AM To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Do you compile with ENABLE_SVG diabled? When doing ports to various embedded systems we often disable SVG to reduce the size of the resulting library. It would be nice to retain the top level ENABLE_SVG define for this purpose. Thanks, Dan On 09/09/2011 05:42 PM, Eric Seidel wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit Cairo port questions
Hi,
I am trying to build the WebKit Cairo port but running into some issues. I
fixed my local compiler errors(mostly by tweaking code to avoid the errors) but
now running into a crash that looks like something inside CFLite.dll.
I built as per instructions here -
http://trac.webkit.org/wiki/BuildingCairoOnWindows . I downloaded the support
packages from the pre bundled copies on that page. I built the debug_cairo
config. After that, I ran the WinLauncher which complained about the missing
CFLite.dll/CFLite_Debug.dll/libcurl.dll. I copied them from the pre built
package to the \WebKit\WebKitBuild\bin directory. Then, I get a crash that
looks as follows(at the end of the email).
Am I doing something wrong here? Is there a last known good version of WinCairo
port?
For the compile issues, I had to (I am sure the correct solution would need to
take into account the WinCairo/Curl stuff but following worked for quick
compilation)
1) Modify the PlatformCertificateInfo constructor to not create
CFURLResponseRef object.
2) Modify CFURLRequestRef STDMETHODCALLTYPE WebMutableURLRequest::cfRequest()
to return 0.
Crash -
CFLite.dll!00471789()
[Frames below may be incorrect and/or missing, no symbols loaded for
CFLite.dll]
WebKit_debug.dll!WTF::RefPtrWebCore::ResourceRawHeaders::operator=(const
WTF::RefPtrWebCore::ResourceRawHeaders o={...}) Line 113 + 0x9 bytes
C++
WebKit_debug.dll!WebCore::ResourceResponseBase::operator=(const
WebCore::ResourceResponseBase __that={...}) + 0x13c bytesC++
WebKit_debug.dll!WTF::RetainPtr_CFURLResponse
*::~RetainPtr_CFURLResponse *() Line 69 + 0x32 bytes C++
cc00()
WebKit_debug.dll!WebCore::ResourceResponse::~ResourceResponse() + 0x1c
bytes C++
WebKit_debug.dll!WebCore::FrameLoader::init() Line 236 + 0x6b bytes
C++
WebKit_debug.dll!WebCore::Frame::init() Line 254 C++
WebKit_debug.dll!WebView::initWithFrame(tagRECT frame={...}, wchar_t *
frameName=0x, wchar_t * groupName=0x) Line 2622 C++
WinLauncher_debug.exe!wWinMain(HINSTANCE__ * hInstance=0x0040,
HINSTANCE__ * hPrevInstance=0x, wchar_t * lpCmdLine=0x00020b7a, int
nCmdShow=1) Line 207 + 0x36 bytes C++
WinLauncher_debug.exe!__tmainCRTStartup() Line 589 + 0x1c bytes
C
kernel32.dll!7c817077()
icuin40.dll!0066006f()
icuin40.dll!00620069()
icuin40.dll!0066006f()
JavaScriptCore_debug.dll!0075006c()
icuin40.dll!0066006f()
JavaScriptCore_debug.dll!0075006c()
JavaScriptCore_debug.dll!JSC::ProgramExecutable::compileInternal(JSC::ExecState
* exec=0xb800, JSC::ScopeChainNode * scopeChainNode=0x) Line 151 +
0xe bytes C++
0fb9c47d()
Thanks.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
