Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
blog.leaningtech.com
Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
1–10 of 23 posts
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#2I 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".
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#3Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#4The "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 suppor…
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#5Im very excited sbout competition in this space even if it becomes impractical
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#6The 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.
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#7Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#8Maybe I'm being dense, but why would someone want to write c++ code and transpile it to JavaScript?
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#9Maybe I'm being dense, but why would someone want to write c++ code and transpile it to JavaScript?
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
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#10It'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…
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.