emscripten

Note though that the blogpost is 5 months old, and the comparison is out of date. For example, as also noted in other comments, Emscripten can handle memory as either 1. Singleton fixed typed array (what most users use; the fastest) 2. Singleton growable typed array (aka asm.js memory growth; still not optimized in all browsers, though) 3. Split memory, in which each chunk of memory can be allocated separately, which allows fully dynamic memory usage the way C and C++ do natively (allocating and freeing pages to the OS), https://github.com/kripken/emscripten/wiki/Split-Memory (but the flexibility makes it harder for JS engines to optimize)

Emscripten has an option to chunk the typed array, https://github.com/kripken/emscripten/wiki/Split-Memory In that mode, memory allocation is basically like in C and C++: each block can be allocated and freed independently. Of course, this does have a performance cost, so it's a tradeoff.

Whats the benefit of this compared to using https://github.com/kripken/emscripten ?

I'm not an LLVM expert, but Swift is an LLVM frontend, so once it's open source, I think it should work for the various backends? Right now the issue is library support - swiftc can already just spit out LLVM IR: https://github.com/kripken/emscripten/issues/2427 The stdlib would be included in the open source release. Linux boxes would fulfill "non-Apple product" though. Unixy programming languages like Swift and Python have always been weird on Windows.

I found some bugs and commented on the original pull request for the pthread support. https://github.com/kripken/emscripten/pull/3266. In my opinion, the pthread support itself works well now. But the biggest problem of the implementation is that SharedArrayBuffer, the pthread support calls for, is implemented only in Firefox currently. One of the purpose to use emscripten is made an application cross-platform web application. You can get a "non-webbish" code runs only in Firefox with pthread-supported emscripten as of now. I'm looking forward to other browsers with SharedArrayBuffer support, especially Mobile Safari.

Actually there so much more you can emulate: https://github.com/jsmess/jsmess https://github.com/dreamlayers/em-dosbox https://bitbucket.org/tsone/em-fceux and others https://github.com/kripken/emscripten/wiki/Porting-Examples-...

Silverlight should have never been. HTML5 tech is the way forward and has been for years now. The fact that all of these demos work at the speeds that they do is proof: https://github.com/kripken/emscripten/wiki/Porting-Examples-...

> If I want to implement NaCL execution, I only need to support a (sane) bytecode What makes asm.js "insane" by comparison? The syntax? There's a bytecode for asm.js too if you want it. https://github.com/kripken/emscripten/wiki/Emterpreter > If I want to implement asm.js, I have to implement a full JavaScript JIT (if I want decent performance). This is Hard. Writing a compiler that gets decent performance for LLVM is also Hard. (Go look at the size of the x86 backend alone in LLVM.) If you were writing an asm.js engine from scratch with no support for any JS other than Emterpreter bytecode, asm.js is probably even a bit easier than supporting PNaCl, due to the lack of types and no SSA. But honestly, the amount of work you need to parse a different bytecode doesn't matter much compared to the amount of work you need to do to write a good

Issue seems to come from Emscripten https://github.com/kripken/emscripten/issues/3171

Another interesting technical detail is that the nethack code contains a lot of synchronous stuff, which is generally hard to port to the web (where events must be short-lived). To get around that, the port uses Emscripten's emterpreter-async option to build (as you can see here: https://github.com/coolwanglu/BrowserHack/blob/master/build.... ). That runs the application in a little interpreter designed for Emscripten output; the interpeter is capable of pausing and resuming code, so synchronous code isn't a problem. More details on emterpreter here: https://github.com/kripken/emscripten/wiki/Emterpreter

You could probably do it with Emscripten. https://github.com/kripken/emscripten

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.

> which requires compiling in your own malloc dlmalloc is cross compiled for you. I might be mincing words, but you make it sound like you have to bring your own allocator. Not so. > makes it hard not to massively waste memory by overallocating a huge buffer. Non issue. there are compiler flags `-s TOTAL_MEMORY=X` and `-s TOTAL_STACK=X`. Of course, you have to play around with these values otherwise you might not have enough space. I'm working on memory profiling tools to visualize the state of the heap in emscriptenized code [0] and getting them merged upstream. [1] The docs could be better on those flags. > Therefore I greatly prefer optimisations which speed up 'asm.js-like code', rather than the all-or-nothing optimisation one gets from firefox. Why must they be mutually exclusive? It's a straw man to paint it like we can only ha