Looked into Cheerp briefly but the commercial licenses made it pretty much a non-starter. If you're going to charge then you should be upfront with your licenses costs rather than hide them until you see who contacts you.
It's good that there is competition, but it speaks for emscripten that Cheerp (formerly known as duetto) had to pick two relatively obscure areas where emscripten+asm.js can be beaten.
The slower startup speed with asm.js enabled, at least in Spidermonkey is because it does Ahead-Of-Time (AoT) compilation. The advantage is that once the binary code is generated, it will never be touched again. Other JS engines might decide to de-optimize and re-compile some code, or go through several 'tiers' and only optimize the hot-running parts, which means slow first-time execution and at worst stuttering at unpredictable times. Both are deadly for apps where a smooth frame update is required.
I wonder why startup speed in V8 is slow though, AFAIK it doesn't do AOT compilation, or is this now the case with the new Turbofan module?
The second area, dynamic memory growth is unfortunate at first glance, but a trade-off for better performance, I wonder if pre-allocating a large chunk of memory is still as much an issue in 64-bit browsers as with 32-bit.
In my experience with Unity HTML 5, Firefox beats the hell out of Chrome, both on startup time and cold performance (they are both great when warmed up).
I'm not too happy that the browser that was first to deprecate native plugins didn't provide usable asm.js as a replacement first.
The "with dynamic memory" part being critical, since that means no asm.js. With asm.js, emscripten is faster.
I get the feeling this is one the one hand pretty cool, but on the other hand poorly timed. Unless WebAssembly never arrives or arrives really late, there's going to be a way to run almost-native code with dynamic memory allocation fairly soon. So it's likely this will soon be relegated to "old-android support".
There are three relevant memory modes for Emscripten to compare with here,
1. Normal output, asm.js, no memory growth. Maximal speed, fixed memory size.
2. Memory growth. As the article mentions, asm.js no longer supports this, but Emscripten does. It just removes the 'use asm'.
3. Split memory. As the article mentions, this is non-asm.js. This supports not just growing and shrinking memory, but allocating each chunk of memory separately, leading to flexibility similar to that of Cheerp.
The article compares 1 and 3, but not 2. In practice, almost all Emscripten users use 1, a small amount use 2, and as far as I know almost no one uses 3. Also, 2 would start up much faster than 1, and run much faster than 3, so it would be an interesting comparison to Cheerp.
Regarding startup time, there are two things that I think should have been measured:
1. Large programs. The largest they test is the Bullet physics library, which is still quite small.
2. Execution of the first few frames. Non-asm.js code, like Cheerp output, is compiled dynamically. This generally means that startup is fast, then the first few frames are very slow, then it eventually gets smooth. The measurements in the blogpost appear to ignore that.
Both of those things - larger programs, and more sophisticated measurements of startup speed - are present in the open source Massive benchmark [1]. It would be interesting to see Cheerp compared to Emscripten on that (and also on the 2nd mode mentioned earlier).
Some additional data about Emscripten code without asm.js mode, corresponding to memory model 2 in your comment. We generated the data on spidermonkey using the --no-asmjs command line switch.
Wasm may make this useless, but this is pretty exciting. After working with a Emscripten module recently I can tell you debugging it is a pain. Wrappers around internal functions. Destroying objects after you are done with them. Memory leaks start becoming a huge issue that were once fringe after thoughts.
Im very excited sbout competition in this space even if it becomes impractical
If it needs to run in the browser you'll have to compile the libraries to JS so that all code runs in the security sandbox. With node.js, it is possible to directly call out into native code. Google has a native messaging feature which allows it to communicate with native applications but these need to have been installed traditionally.
well nobody has been successful at calling out to BLAS/LAPACK from nodejs. I wonder why. is there a certain signature that the functions must expose or something ?
Is it possible to embed llvm into the v8 engine? If so, all we need to do is to compile c/c++ codes into llvm byte codes, then import it as js modules, like this:
`import {LibSass} from './libsass.bin'`.
It is possible, but I am not sure if LLVM is that "open" and "free", so we can make a web standard out of it. I think Web Assembly will be the similar thing (low-level code for a browser).
The better performance then manually written JS comes from the use of asm.js, LLVM's optimizer passes, and a simple linear memory model which 'preserves' spatial locality also present in the natively-compiled C/C++ code (if the programmer paid attention to this)
Passing an URL along from which the code directly runs is the simplest distribution model imaginable, both for the 'publisher' and for the user.
PS: the performance part applies to emscripten and asm.js, not necessarily to Cheerp which uses a different approach
Whoa, your framework looks excellent. I've been looking at the options for making a simple graphical program that can run in native/desktop and in browser without introducing ridiculous bloat, and had already concluded that C++/emscripten was likely the best option, probably using GL. (The close runner-up being Haxe/OpenFL, but it's a bit heavier and kind of an experimental leap.)
I'm still deciding on which libraries to use, and Oryol suddenly seems like a great option, though what I'm making is not a game and is not 3D (basically a score editor). Other options considered were SDL(2) or something more basic like GLFW. But Oryol's killer feature here is that it's specifically designed to result in a lightweight web version. (Though SDL1 also results in small sizes, but that's because the emscripten team put a lot of work into converting SDL calls into browser API calls)
Thanks! But please keep in mind that Oryol is fairly experimental and the API might change on a whim, so it may be a bit painful to use for a real-world project that needs API stability.
I converted legacy code to JS using emscripten because the company had severe constraints on the output of the code. In other words they didn't know why their code did what it did. (grin)
