Hacker News Reader

Comment by zegl | Hacker News Reader

I've been wanting to test out the LLVM IR to WebAssembly compilation, but I've been too lazy (or impatient) to compile LLVM from source. Nice to see that it's now enabled by default!

View on HN

There truly is nothing to it. I just built it for the first time on this fresh install of Ubuntu. You can just copy and paste the lines from the getting started page.[1] Here's my .bash_history:

  $ git clone https://github.com/llvm/llvm-project.git
  $ cd llvm-project
  $ mkdir build && cd build
  $ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm
  $ make -j4

Took < 40 min on an old laptop.

[1] https://clang.llvm.org/get_started.html

It doesn't matter much when you build only once, but more people need to be aware of Ninja for builds. Both cmake and meson can target it, and it is much faster for incremental builds.

I never understand this. Surely 'make' itself uses an almost irrelevantly low amount of CPU compared to compiling?

That being said: have used Ninja with Cmake. Damn fast.

It's not so much how much CPU each takes up, but that 'make' will waste some time recompiling stuff that doesn't need to be recompiled. Ninja is better about reusing stuff compiled the first time to make the second compilation faster but still accurate.

Isn't the point of `make` that it doesn't build stuff that doesn't need to be rebuilt? Am I missing something?

I guess make and ninjia use different algorithm to compute the targets that does not beed to rebuild.

The problem is with how make checks which files have changed and the related I/O latency, plus the fact that pretty much everybody uses recursive make. The overhead of recursive make initialization plus the forced serialisation of builds is the main cause of slow make.

Consider the Linux kernel as a contrast, which doesn't suffer from slow make because a lot of investment was made into a non-recursive make system.

The fact that makefile generators like CMake tend to generate recursive makefiles is a shame.

Last time I tried on a not super new laptop, it couldn't link. It really needs 8GB of RAM last time I tried.

Something was wrong with your setup. I've built clang in the past on a VM with only 3GB physical + 3GB of virtual RAM/swap allocated.

Recently? It was a 4GB laptop that ran out of memory while linking back in Oct '18.

Does this mean wasm is effectively just another ISA to compile to and emscripten is no longer needed?

If you need really small functions, yes. emscripten is providing all the libc functions, WASM loading code and binding generators. You will probably need some of that when porting existing libraries or applications to the web!

Well, you generally need a libc when compiling for any platform, so that shouldn't be too special?

You don't inherently need a libc for wasm. That is, libc is usually the API for the platform; wasm doesn't have such a thing really. Your wasm module says "hey, these are the functions I expose, and these are the functions that I am planning to call from the environment" and it's the host's job to wire that up properly. In the browser, that means when you instantiate a wasm module, you need to provide all the required functions, and then you can call the exposed functions from JS. Outside the browser, what things you can call and will be called is defined by the host.

A libc can be useful inside of wasm for existing C or C++ code (or whatever) that is built for another platform, so that you can more easily compile to wasm as well. But it's an option, not required.

Well, I meant that if you want to cross compile general code, you might want malloc, printf etc...

I'm not sure the primary appeal of wasm is treating it as a low level target (even if that is possible and sometimes useful).

You can get that stuff without a libc, if you’re not literally compiling C or C++. If you are, you’re right, though.

You don't necessarily need it. You could have some math focused code you want to call from JS.

That is a good question, but as I understand it (from reading only) emscripten does a few other things, such as convert opengl calls to webgl, as well as use special integrated versions of SDL and GLFW so that native programs that use those libraries can be compiled directly.

Both of those would include input and I think audio is dealt with in a similar way.

It's a bit more complex than that. emscripten tries to provide a full environment; it adds a runtime with features like a libc. It also produces some HTML and JavaScript to load up the wasm, etc. The new wasm target gives you none of that. This means smaller binaries for some things, but it's harder to get existing desktop codebases up and running.

(In Rust, we've had this new target for a while, and it's where we're putting in all of our development efforts. We still technically support the emscripten target as well.)

No, it is not needed any more. I have a demo here: https://github.com/PetterS/clang-wasm

But be prepared to work without libc if you don't use emscripten. Writing a malloc is fun though!

Nice demo, thanks.

It's funny how technology go in waves. This reminds me more of programming microcontrollers than writing Web stuff, and yet this is the hot new thing!

> too lazy (or impatient) to compile LLVM from source

You can use llc from the release tarballs.

Reply on news.ycombinator.com