
Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory - multimillion
http://blog.leaningtech.com/2016/02/cheerp-12-c-to-javascript-with-faster.html
======
vvanders
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.

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

~~~
reitzensteinm
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.

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

~~~
rl3
The progress being made on WebAssembly so far is impressive:

[https://www.youtube.com/watch?v=5W7NkofUtAw](https://www.youtube.com/watch?v=5W7NkofUtAw)

------
azakai
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/](http://kripken.github.io/Massive/)

~~~
apignotti
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...](https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv-5BXKP3KwjNDzibkkpWf7Aw/pubchart?oid=347599584&format=interactive)

Execution time (small benchmarks):
[https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv...](https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv-5BXKP3KwjNDzibkkpWf7Aw/pubchart?oid=1317532347&format=interactive)

Execution time (larger benchmarks):
[https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv...](https://docs.google.com/spreadsheets/d/17fFM1YqhMV2-O0ZdymEv-5BXKP3KwjNDzibkkpWf7Aw/pubchart?oid=1403631519&format=interactive)

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

------
sandGorgon
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...](http://stackoverflow.com/questions/21990243/use-emscripten-
with-fortran-lapack-binding)

[2] [https://github.com/software-engineering-
amsterdam/MLitB/issu...](https://github.com/software-engineering-
amsterdam/MLitB/issues/1)

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

~~~
flohofwoe
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.

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

~~~
flohofwoe
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...](https://groups.google.com/forum/#!searchin/emscripten-
discuss/BLAS/emscripten-discuss/4Qt1OXKCKrk/KPFXhalxpeAJ)

------
Wenris
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'`.

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

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

~~~
flohofwoe
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/oryol/),
[http://floooh.github.io/voxel-test/](http://floooh.github.io/voxel-test/),
[http://floooh.github.io/virtualkc/](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

~~~
pierrec
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)

~~~
flohofwoe
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.

