Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory | Hacker News Reader

Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory

blog.leaningtech.com

110 pointsmultimillion21 comments

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.

> 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?

Correct, Turbofan does a lot more up-front compilation for asm.js. There is also work in v8 to do full asm.js validation and AOT using that info,

https://bugs.chromium.org/p/v8/issues/detail?id=4203

> I wonder if pre-allocating a large chunk of memory is still as much an issue in 64-bit browsers as with 32-bit.

On 64-bit it's mostly a non-issue, yeah, you can allocate a single 1GB+ chunk fairly easily.

There have also been big improvements on 32-bit Chrome over the last year,

https://code.google.com/p/chromium/issues/detail?id=394591

https://code.google.com/p/chromium/issues/detail?id=533580

But again, this is mostly a non-issue on 64-bit, and 64-bit is rapidly becoming the norm anyhow.

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".

The progress being made on WebAssembly so far is impressive:

https://www.youtube.com/watch?v=5W7NkofUtAw

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).

[1] http://kripken.github.io/Massive/

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.

Startup time: https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv...

Execution time (small benchmarks): https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv...

Execution time (larger benchmarks): https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv...

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

Question: can js call out to native libraries as well ? I'm wondering why BLAS/LAPACK is not callable from JS.

there are all these questions about how to use LAPACK from js.. and none seem to work right.

[1] http://stackoverflow.com/questions/21990243/use-emscripten-w...

[2] https://github.com/software-engineering-amsterdam/MLitB/issu...

[3] https://github.com/karpathy/convnetjs

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 ?

I don't know unfortunately. Here's an old discussion on the emscripten discussion group, may be this contains helpful information: https://groups.google.com/forum/#!searchin/emscripten-discus...

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).

Maybe I'm being dense, but why would someone want to write c++ code and transpile it to JavaScript?

I assume this is to port existing C++ code to JS? That's what Emscripten is supposed to do anyway.

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)

In short, portability, better performance than manually written Javascript and simple distribution:

These demos run in the browser, and natively on iOS, Android, Windows, Linux, OSX with the smallest size and best performance on each platform compiled from the same C++ code: http://floooh.github.io/oryol/, http://floooh.github.io/voxel-test/, http://floooh.github.io/virtualkc/

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.

Reply on news.ycombinator.com