Comment by flohofwoe | Hacker News Reader

Comment by flohofwoe | Hacker News Reader

I think this is the first emscripten feature which I don't "get", e.g. not fully understanding the motivation behind it :) Firefox AOT compile time is great, and nothing at all compared to the time it takes to download the code. The real art lies in getting the actual emscripten compiled executable small, not because of emscripten, but because of C++'s tendency to bloat the executable size if one isn't really careful. Also, clang and emscripten's code generation passes have very aggressive dead code elimination, but there can be wrong decisions on the game engine architecture-level which can cause the inclusion of code that might never be called. A native executable that's several dozen MByte's big is a bad thing on any platform, it just doesn't appear as such a problem if it is a part of a 50 GByte game download. To come to and end, I think an emscripten client of up to 5 MByte (gzipped) doesn't really require a fix like emterpreter for its startup time(?), and it's perfectly possible to fit a full 3D game client into such a size with a little care about size optimization.

[edit: fixed a formulation which sounded like code bloat can be blamed on emscripten instead of user-code]

I agree that a moderate or small codebase doesn't need anything like the Emterpreter. At least not for startup speed - see the wiki page for other uses https://github.com/kripken/emscripten/wiki/Emterpreter

But there are some huge multimillion line codebases that you can't really reduce in size to 5MB. That's the startup time problem that the Emterpreter aims to help with.

I see. Guess it's mainly for UE4 then ;) I was surprised how small the Unity demos have been (the biggest was a bit over 3 MByte IIRC for the zombie FPS), guess they have their intermodule-dependencies better under control.

I actually find the bytecode part more interesting then the interpreter part, are you seeing drastically better compression for a bytecode module compared to compressed ASCII asm.js?

Actually, no - while the bytecode is smaller than asm.js, when you compress them both, they end up around the same. The issue is that the bytecode is designed for fast execution, not compressibility, so it contains absolute offsets for jumps, etc. - this lets you just start running the code immediately, but also means it looks like random noise that compresses poorly. And, JavaScript is fairly compressible, as it has less such noise, it's very regular.

However, it does seem likely that a binary format that is designed for compressibility could be smaller. But, it would not be as fast to execute.

Here's a binary format that is designed for compressibility and fast code generation [1]. It's a bit of a pet of mine (I just realised one of the Wikipedia links are to my blog) - it was the PhD dissertation of now professor Michael Franz at UC Irvine, who incidentally had Andreas Gal (now of course at Mozilla...) as PhD student.

SDE effectively compresses a low level syntax tree by building a dictionary that as a sort of sliding window over the tree by adding specialised nodes as well as more general nodes, and the encoding new variations of specialised sub-trees using the new elements in the dictionary and subsequently adding more specialised "instructions".

As a result you both get compression (think a tree variation of Huffman coding) and "hints" to let you re-use partially generated code as templates (e.g. one dictionary entry maps to "assign x to y"; you also add "assign x to _", and later you find a reference to the entry for "assign x to _" + z; now you copy the code for "assign x to <something>" into place and fix it up with the address of z).

The approach has always fascinated me, but it fell in the shadow of the JVM.

[1] https://en.wikipedia.org/wiki/Semantic_dictionary_encoding

Interesting, thanks!

I believe asm.js has been trying to counter concerns people might have when considering using it. Also, it could be that some companies may be trying to join efforts in trying to further the asm.js adoption, like Microsoft adding more support for asm.js. So it could be that they are planning ahead much more now. The asm.js effort could be seen as moving on from a prototype to an actual feature companies may depend on in the soon future.

Also, what makes people more cautious about performance concerns is that mobile network and hardware are still catching up to what people have on the desktop. And since about 8 years ago, mobile has been a big opportunity for many companies, which means that the desktop has been taken for a ride by the mobile devices and that is not going to stop.

Imo a stackbased bytecode has far better code density, which is probably pretty good for browsers.

Erm, it's a big tradeoff. You get better code density, but it takes longer to compile well and is slower to interpret.

.. at a significant cost to execution speed, experience shows. The fastest interpreted "general purpose" language is apparently Lua, which switched from stack to registers to get that speed a while ago.

Reply on news.ycombinator.com