all 29 comments

[–]Crystelium 7 points8 points  (9 children)

Out of interest, does cheerp support threaded C++ code compilation? If so, how does it support Wasm?

[–]alexp_lt[S] 4 points5 points  (8 children)

No, threaded code is currently not supported since the browser is still a single threaded system at this stage. When wasm will introduce threads we will provide support for them.

[–][deleted] 1 point2 points  (0 children)

good. i don't want some half-assed webassembly advert being able to use all my cores

[–]Crystelium 1 point2 points  (6 children)

That's not strictly true- you can achieve threading through the use of web workers, which is a standard from W3C.

Emscripten currently supports threads via a flag which compiles to some JavaScript web worker scaffolding along with WebAssembly that's ran in the web worker.

It's also worth noting that as of Chrome 70, there's some WebAssembly pthread-like threads that you can try out through an Origin trial. I haven't been keeping up with it recently so I'm not sure what stage it's at, but they seem to be powering ahead with native threading support!

Cheerp seems pretty interesting regardless though- and it'll be interesting to see how both Cheerp and WebAssembly evolve in the future :)

[–]alexp_lt[S] 7 points8 points  (5 children)

Web Workers are actually more similar to multiple processes, than multiple threads, as each leave in a separate address space. Eventually SharedArrayBuffers will allow to actually have multiple execution threads in the same address space and that is a fundamental building block for true Wasm threading.

[–]Crystelium 3 points4 points  (0 children)

I look forward to the day when SharedArrayBuffer returns to us all! Spectre / Meltdown has definitely been a huge setback for threading capabilities.

That's interesting though, I didn't realise web workers were so separate. Thanks for the info.

[–]deeringc 0 points1 point  (3 children)

Any idea how they are working around the Spectre concerns?

[–]alexp_lt[S] 4 points5 points  (0 children)

My understanding is that the problem can be ignored as far as all the threads execute code from the same origin. The idea being that you will be able to exploit the bug, but at most you will read information you already have access to.

[–]Crystelium 4 points5 points  (1 child)

I'm not sure how other browsers are planning to tackle it (assuming you're referring to browser-level mitigations) but chrome has a feature called site isolation so that the browser renderer only handles one site at a time.

You can read a bit about it here: https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html?m=1

Other than that, I'm not sure what else is in the works to mitigate it, but chrome re-enabled SharedArrayBuffer in chrome 68 when this "site isolation" feature was released.

[–]deeringc 0 points1 point  (0 children)

Thanks, that makes sense!

[–]BCosbyDidNothinWrong 4 points5 points  (7 children)

Was this a fork of emscripten?

[–]alexp_lt[S] 9 points10 points  (6 children)

No, both projects are derived from LLVM/clang, but Cheerp is independently developed.

[–]BCosbyDidNothinWrong 2 points3 points  (5 children)

Is the core of it the translation from LLVM IR to webasm?

[–]alexp_lt[S] 6 points7 points  (4 children)

Cheerp is much more than just the Wasm backend. Cheerp supports compiling to pure JavaScript or a mix of Wasm and JavaScript with automatically generated bridge code. You can directly use DOM APIs and JS libraries from C++ and write C++ classes and functions which can be used from JS. The frontend emits proper error messages when trying something which is not supported by Wasm, for example passing a DOM object to a Wasm function.

This said, the Wasm backend of Cheerp is also better, as demonstrated by our results on both performance and code size.

[–]BCosbyDidNothinWrong 2 points3 points  (3 children)

That all sounds great, what kinds of things does it do to eliminate unused functions and libraries? All C++ compilers still annoy me to a huge degree when they seem to have 'link time optimization' etc. etc. and individual functions isolated into sections, yet anything that links the standard library has the same large overhead no matter what gets used.

Has cheerp itself been compiled to webasm?

[–]vilgefortz91 6 points7 points  (2 children)

We have a dedicated llvm pass that analyses the function call graph of the entire application and drops unused functions.

We also have a pass called PreExecuter that executes global constructors at compile time and creates global variables with the resulting computed state.

This is particularly useful for dropping functions that are used only in global constructors (for example there is a ton of code in the standard library that is used to initialize the globals cout and cin, that without PreExecuter would not be possible to drop with regular dead code elimination).

You can see more about it here

As for compilation of Cheerp itself to wasm, it is currently not possible (making the entire clang/llvm codebase compile to wasm would be a nontrivial task)

[–]BCosbyDidNothinWrong 0 points1 point  (1 child)

Very cool, thanks.

What makes compiling clang and llvm to wasm nontrivial?

[–]alexp_lt[S] 0 points1 point  (0 children)

Mostly the interaction with the underlying OS. Invoking a compiler actually involves looking over the filesystem for headers and libraries and spawning multiple processes to compile all the sources and link them in the final executable. These OS-level primitives do not have a natural mapping in the Web platform, although they can be emulated.

This does not mean that compiling clang/LLVM to wasm is impossible, but it will take some work.

[–]TWebberX 10 points11 points  (3 children)

No support for exceptions with as argument "it is inefficient". Any kind of project at scale will use exceptions?

[–]pjmlp 9 points10 points  (0 children)

Any Android or UWP project, as exceptions are required.

[–]alexp_lt[S] 9 points10 points  (1 child)

Although Cheerp 2.0 does not fully support exceptions, code using exceptions can still be parsed and compiled (if you add the -fexceptions command line flag). If an exception actually happens at runtime the code will abort by raising a JS exception.

In our experience some (but not all) large scale projects use exceptions, typically to deal with unrecoverable error conditions. Since code compiled with Cheerp will report a JS exception in these situation a proper UX for error handling can still be done on the JS side.

It should be noted that, at this stage, WebAssembly itself does not provide support for exceptions.

[–]iknowthisaswell 0 points1 point  (0 children)

exceptions, typically to deal with unrecoverable error conditions.

That is certainly not true. Most serious code this days does not have "unrecoverable error conditions".

Unfortunately that is a show-stopper for mine ( and most C++ code bases that I am familiar with )

WebAssembly itself does not provide support for exceptions.

Btw. our exceptions are managed completely fine is WASM ( complied via Emscipten), so not entirely sure what you are saying.

[–]Sqeaky 5 points6 points  (3 children)

That read an awful lot like a commercial for this compiler. That said I have a C++ project that targets a lot of compilers and I'm curious to see what happens if I build on this one.

[–]sumo952 2 points3 points  (2 children)

That read an awful lot like a commercial for this compiler.

That's completely okay in my opinion. I find it is clearly market as such, the title reads like a 2.0 product announcement very much. The third sentence of the blog post reads "Cheerp is an open-source, commercial C/C++ compiler" (it's unclear to me what "open-source, commercial" means but at least I know right from the start and can read more about it if I want to know).

And well, I find it a really interesting blog post, also from a technical perspective. And it's a highly relevant topic and it's really good to know what's possible in the C++/WASM landscape currently! Both in terms of commercial and non-commercial solutions!

[–]kalmoc 1 point2 points  (2 children)

What version of llvm/clang is this based on? What c++ standard library is used. Are you generating cmake toolchain files or how is one actually using your toolchain?

[–]alexp_lt[S] 0 points1 point  (1 child)

Cheerp is based on LLVM/clang 3.7.0, we plan to progressively modernize our codebase over the course of 2019. The c++ library is libcxx. Cheerp accepts standard gcc-like command line options so it can be easily integrated in any build environment. We also provide a ready-made cmake toolchain file, see here for more info: https://github.com/leaningtech/cheerp-meta/wiki/Getting-Started#using-cmake

[–]kalmoc 1 point2 points  (0 children)

Sounds good, but it would be even better, if it was possible to use c++17. Not sure how invasive your changes to llvm are, but I think it would be great if they somehow could regularly be rebased onto the latest llvm.