4 ms·
This is very cool, and great to read more interesting research from Mozilla. However in this article I notice something curious: normal asm.js kicks off and sho
by AshleysBrain 12y ago
This is very cool, and great to read more interesting research from Mozilla. However in this article I notice something curious: normal asm.js kicks off and shortly after reaches top speed by around 700ms. emterpreter gets going by 200ms, but takes another 1200ms to reach top speed by 1400ms. Why is it not another 700ms? Isn't it just doing the same work as asm.js but in the background while running with emterpreter?
Non-blacklisted emterpreter looks slow enough (5fps ish on that graph?) to simply not be useful for some use cases, like a game engine - it's not going to be remotely playable like that. Therefore emterpret => asm.js actually significantly increases the startup time. Playable by 1400ms is worse than playable by 700ms. But I guess this is all preliminary and improvable though!
- azakai 12y agoThere are a few reasons why full speed is reached later when starting up in the emterpreter and swapping in asm.js later: * Compiling asm.js can use multiple CPU cores, so doing just that is faster than doing it while the emterpreter is running on (at least) one core. * I believe, but am not sure, that compiling on a background thread is done at lower priority than stuff on the main thread. * Swapping asm.js code in can only be done in between frames. At 10fps for example, that means around a 100ms delay just for that, and possibly more depending on the state of the browser's event queue.