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.
Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
11–20 of 23 posts
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#12Maybe I'm being dense, but why would someone want to write c++ code and transpile it to JavaScript?
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 w…
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)
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#13Earlier quoted context omitted.
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 w…
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 librarie…
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.
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#14There 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).
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#15It'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 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.
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#16Is 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'`.
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#17Is 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).
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#18Question: 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...
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#19Maybe 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)
Re: Cheerp 1.2 – C++ to JavaScript: faster than Emscripten with dynamic memory
#20Question: 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.