How it works: Compiler Explorer | Hacker News Reader

How it works: Compiler Explorer

xania.org

107 pointsadamnemecek25 comments

Tip: you can get Compiler Explorer to output ASM for almost every triple in existence (with varying results) by relying on the -target option of Clang. i.e., if you specify -target x86_64-w64-mingw32-gnu you can get ASM for windows (remember that the includes are still linux ones!), or if you specify -target x86_64-unknown-freebsd11.1 you can get asm for FreeBSD 11.1.

Matt Godbolt's cppcast appearances have been awesome.

He talks about Compiler Explorer[1] in one and Spectre/Meltdown[2] in another.

[1] http://cppcast.com/2016/01/matt-godbolt/

[2] http://cppcast.com/2018/01/matt-godbolt/

Thank you for creating this nice tool! I am teaching a C++ class, and sometimes I connect to Compiler Explorer in real time to explain how things are translated into low-level operations. I found this approach eye-opening for students, as it removes some of the «magical» aura modern compilers have in the eyes of the class.

> it removes some of the «magical» aura modern compilers have in the eyes of the class.

Reading compiler output after adding -O3 seems to add magical aura in my case :)

Agreed! :-) However, making students see how complex constructs translate into a sequence of simple assembler operations helps a lot in understanding what compilers are all about.

I've found Compiler Explorer to be very useful indeed, for two main use cases: gaining insight into how security mitigations are implemented in different compilers, and for quickly checking my working when reverse engineering tricky C++ compiled code.

Really interesting to see how the tool works behind the scenes.

Thank you for making Compiler Explorer!

I was teaching some workmates a few things about how assembly programming works by looking at compiler output and this was a huge help. :)

Thanks ms for your kind words!

Total aside but I recognised that domain because I used to play the MUD the author hosted ~20 years ago. Odd co-incidence.

Oh wow! Hello from TheMoog hahah. Small world, eh?

It is! For about 6 months in 1999 I had one terminal running telnet to Xania and the other writing code in some bespoke procedual language on HP-UX. One got significantly more use than the other.

This is remarkable - I've never heard of Compiler Explorer before now. I wish we had something like this back in university! Thank you so much for making this incredible tool.

I notice that MSVC is one of the supported compilers. Is he running a Windows VM as well, or did he manage to get the compiler to run under Wine?

It's running under Wine.

I think this view of Docker is pretty common: poor man's virtualization. You'd prefer real VMs but you can't reliably & performantly run nested VMs on public providers. Or can you? What's the current status on AWS/GCP/DigitalOcean/Hetzner?

(tangent here)

I didn't get that from the article. He said that the tooling around Docker is clunky:

But I’ve always felt a bit like the Dockerfile you write is hard to maintain. I have to use some Makefile trickery to prevent having to repeat parts of the Dockerfile amongst each of the containers.

I don't like Docker either, but it's not because I want VMs. I want VMs even less than I want Docker! I want containers that are fast and light.

Basically I want to solve the problems of reproducibility/stability/portability with as little code as possible. VMs a bad way to do that because they involve not just a new user space like Docker, but a new kernel and hypervisor too!

Fun fact: the Vim plugin for my browser gave me the link hint "SSE" for the "<n> comments" link on the front page.

Godbolt's videos about the CPU are very eye-opening too: https://www.youtube.com/user/mattatgodboltorg/videos

That sounds like a lot of work. My armchair-engineer instinct suspects it would be a lot simpler or at least cheaper to run everything in the browser (Emscripten/WASM), and serve static pages from a single node.

Are you suggesting running the compilers in the browser?

But not bare-metal browser (BmB), on Linux of course.

https://bellard.org/jslinux/

So, transpile 8GB of compiler binaries to JavaScript which will inflate it to ~80GB. Now it’s a bandwidth problem.

That is highly exaggerated. Most Linux distributions don't even have such size.

Also, most users don't need support for all languages.

> highly exaggerated

The article says 8GB of compiler binaries, asm.js in my experience is 10x the size of the original binary.

Obviously not everyone needs to download every compiler but even spreading that number between a few hundered compilers means 200+ mb JavaScript downloads.

Am I wrong?

Given how much effort it is to compile and maintain 200 different compilers just for Ubuntu (not to mention some closed-source compilers), this probably is not as simple as you'd think :-)

Reply on news.ycombinator.com