
Cheerp 1.1 – C++ for the Web with fast startup times, dynamic memory - ingve
http://leaningtech.com/cheerp/blog/2015/06/17/Cheerp-1.1/
======
moonchrome
I'm not convinced this is the correct way to solve the problem of porting C++
to web.

AFAIK emscripten can grow heap now and the security implications seem
irrelevant to me (you're still inside of a managed memory pool you're not
going to do anything that JS code can't do already) - maybe it can allow for
more XSS opportunities but I'm not a security expert, seems to me there are
much easier ways to do XSS than exploiting bugs in compiled C++ code.

While allocating heap objects trough JS objects might allow VM to reduce
fragmentation it's going to put big pressure on the GC (which is a big
downside).

With WebAssembly coming up this approach will get even worse in terms of
performance

~~~
ploxiln
I think the point about security is that a C++ program compiled to use a
virtual memory array in javascript could be subverted (to do something the
programmer and user did not intend) with a buffer overflow etc. the same way a
C++ program compiled and running natively could be subverted. With this
translation-to-js-objects kind of transpiling, the result is more like java -
less arbitrary code execution, more "unhandled exception".

------
mwcampbell
I wonder if it would be worthwhile to use Cheerp's approach to compile C++ to
Dex bytecode for Android. Given that ART compiles Dex bytecode ahead of time
to native code, what would performance be like? Yes, Android has the NDK, but
apparently working with that is quite painful. And compiling C++ code to Dex
bytecode would reduce package sizes, since it would no longer be necessary to
ship binaries for ARM and x86, in 32-bit and 64-bit flavors.

------
viperscape
I'm certainly ignorant on this, but why are we stuck with JavaScript? Seems
like such a huge crutch, something people have been working to fix, or avoid,
yet here we are still with it. Doesn't it make more sense to adopt the ffi
model to gain access to things like sockets, files, canvas that the browser or
even OS provides access to; similar to how you would program for mobile native
apps. I don't understand the hold up of why we are stuck in this situation.

~~~
ant6n
I'd say most of this is due to the issue of adoption. You can come up with a
standard for native code, but if you can only run it in one browser that's
basically useless. Even if all browser suddenly implemented some new native
standard, then all existing browser instances that can't/won't be updated
can't access your new shiny website.

Another issue is that native code, assuming that it's secure, is still not
portable across different architectures. So you still end up having to have
some sort of VM anyway to ensure portability.

That's basically where asm.js comes in. It's a static subset of javascript
that allows it to be compiled, it becomes a VM. But since it is javascript, it
will work on all existing browsers, they don't need to support a new standard.
It'll just be slower.

------
amelius
Could this compile to Google's NativeClient? And how much faster would it be
then?

------
bobmichael
This is cool, but the website is not very accessible: I found it really hard
to read a dark grey font on a black background.

------
IshKebab
Wouldn't it make more sense to improve Emscripten's huge TypedArray array so
it can grow and shrink, or be chunked. Or maybe even implement a "virtual"
TypedArray that you can just allocate as the full size of virtual memory.

~~~
ant6n
I wonder why it's an issue to allocate 2GB of zeros anyway. With virtual
memory, it should all map to the same zeroed page until they get written. And
With transparent huge page support, it should only allocate few such pages
until they get written.

~~~
DiThi
Because many browsers are still 32 bit even in 64 bit systems. That means they
get 2GB of virtual space in total. And frequently they don't have 256 MB of
aligned and continuous virtual memory (and I suffered the pain of trying to
develop a web application that uses 128 MB for months, in the end we ditched
the C++ part).

~~~
ant6n
That's fair, I guess. Although I thought browsers like chrome run every window
in a different process, thus each has their own virtual memory.

I guess the browsers should specialize on very large typed arrays, because
with asm.js etc they will most likely be very sparse (e.g. allocate 2gb of
zeros, use 50mb).

------
ausjke
Looks great, what is the biggest difference/advantage in comparison to
emscripten?

~~~
moonchrome
Maybe scroll down to "How is Cheerp different from Emscripten?" ?

~~~
azakai
Note though that the blogpost is 5 months old, and the comparison is out of
date. For example, as also noted in other comments, Emscripten can handle
memory as either

1\. Singleton fixed typed array (what most users use; the fastest)

2\. Singleton growable typed array (aka asm.js memory growth; still not
optimized in all browsers, though)

3\. Split memory, in which each chunk of memory can be allocated separately,
which allows fully dynamic memory usage the way C and C++ do natively
(allocating and freeing pages to the OS),
[https://github.com/kripken/emscripten/wiki/Split-
Memory](https://github.com/kripken/emscripten/wiki/Split-Memory) (but the
flexibility makes it harder for JS engines to optimize)

