[HN Gopher] Compiler Explorer
___________________________________________________________________
Compiler Explorer
Author : disadvantage
Score : 306 points
Date : 2022-10-16 15:50 UTC (7 hours ago)
(HTM) web link (godbolt.org)
(TXT) w3m dump (godbolt.org)
| photochemsyn wrote:
| It's great that you can now get RISC-V output. IMO RISC-V is the
| most pleasant way to learn assembly-level programming. For anyone
| interested here's a nice resource:
|
| https://riscv-programming.org/book.html
| nevi-me wrote:
| A bit unrelated, I've been learning ARM64 assembly out of the
| convenience of having an ARM machine. It's also been pleasant,
| I've been planning on learning RISC-V next. The only device I
| have access to though is the ESP32C3, so I don't know how far
| I'll go with it.
|
| Outside of decompiling some code on Godbolt, peeking into the
| assembly on VS Code, I've also been practising with Rust's
| inline assembly, quite pleasant.
| seabass wrote:
| Is there a trick to make the typescript compiler run? All the
| other examples seem fine out of the box. No matter what I write,
| the ts compilation fails.
| b3morales wrote:
| A small tip when visiting godbolt: you can use the name of the
| language you're interested in as a subdomain, to get a page
| immediately set up for that language, rather than starting with
| the default C++. For example https://erlang.godbolt.org or
| https://rust.godbolt.org
| charcircuit wrote:
| https://clang.godbolt.org resolves but doesn't seem to do
| anything.
| b3morales wrote:
| I'm not sure how many languages have alternative compilers
| available, but I suppose you could make that a feature
| request: to have a direct way to choose the compiler with the
| a subdomain too. https://clang.c.godbolt.org Or maybe it
| would make more sense in the path:
| https://c.godbolt.org/clang
| kupopuffs wrote:
| Now, is clang a language? Hmm
| [deleted]
| saagarjha wrote:
| It has "lang" in its name!
| mattgodbolt wrote:
| It only works for languages, not compilers. _almost_
| everything *.godbolt.org resolves to Compiler Explorer (I
| have some other projects at this domain), but *.compiler-
| explorer.com and *.godbo.lt always point at CE.
| camel-cdr wrote:
| Another tip, specifically for mobile users: try
| https://godbolt.org/noscript
| sylware wrote:
| WOW!
|
| There is a noscript/ basic (x)html version AND it does handle the
| _canonical_ gcc aka the last C compilable gcc (4.7.4).
|
| Many of the optimization tricks hidden deep into those massive
| and complex software will be yours now.
| shortlived wrote:
| I just discovered goldbolt aka compiler explorer via this
| excellent podcast episode: https://corecursive.com/to-the-
| assembly/
| slavik81 wrote:
| I've used Compiler Explorer for many years as a C++ developer.
| When I started working in HIP, I really missed having Compiler
| Explorer in my toolbox. I've been on leave for the past couple
| months and I took the opportunity to make some contributions
| outside my normal work. Consequentially, full support for
| compiling HIP to AMDGPU assembly was merged last week.
|
| Here's an example: https://godbolt.org/z/qjsErWzcs
| mattgodbolt wrote:
| For which we thank you very much for your help!!
| usefulcat wrote:
| Awesome tool. I do mostly c++ all day and I use this almost
| daily, and certainly weekly. I think it's really improved my feel
| for what the compiler will do with different constructs.
| motgilk wrote:
| It's an excellent tool. Would be nice if it showed you the full
| linker output too, of the final binary.
| xfgusta wrote:
| I'd like to share a command-line tool to interact with Compiler
| Explorer that I made: https://github.com/xfgusta/cexpl. It's
| written in Python and it's available on PyPI.
| choeger wrote:
| When I was still programming in C++ that tool was _the_ method to
| discuss compiler internals and language semantics with
| colleagues. Just setup a minimal example and share it with your
| colleagues. Impressive and sad at the same time. Impressive for
| obvious reasons. Sad, because the language is so confabulated
| that there is no easy concise way to talk about its semantics.
| jeffbee wrote:
| I also use it for this purpose, however I have come to hate the
| way other people use it for this. I have a colleague who has
| really no idea what he's talking about with respect to machine
| performance, and who did not have the requisite knowledge of
| how to peep at the assembly code of a given function with the
| standard tools like objdump, who now loves to send everyone
| godbolt links in slack, along with his suppositions about which
| function will be faster, based entirely on vibes (mostly,
| instruction count). This drives me up the wall. I wish there
| was some minimum height needed to ride godbolt.
| jcranmer wrote:
| Using Compiler Explorer to see how different compilers
| interpret the same code, or understanding the generated ABI,
| or if various pragmas are or are not working, etc., is a very
| good use of it--I suspect most compiler developers at this
| point more or less have a tab of Compiler Explorer
| permanently open at this point.
|
| > I have a colleague who has really no idea what he's talking
| about with respect to machine performance, and who did not
| have the requisite knowledge of how to peep at the assembly
| code of a given function with the standard tools like
| objdump, who now loves to send everyone godbolt links in
| slack, along with his suppositions about which function will
| be faster, based entirely on vibes (mostly, instruction
| count).
|
| This, however, just _no_.
| nickysielicki wrote:
| objdump sucks, source annotations via coloring makes it at
| least 5x faster to read assembly, I don't care how smart you
| are or how fluent you are in assembly. If your colleague is
| wrong for other reasons, that's orthogonal.
| nibbleshifter wrote:
| Side by side (or coloured, or whatever) source -> assembly
| annotations is also a really, really efficient way to learn
| some more assembly.
|
| Write program -> compile -> disassemble w/ some mapping ->
| make notes -> repeat.
|
| Eventually your brains pattern recognition starts to allow
| you to do neat things with disassembles of programs without
| source code.
| mattgodbolt wrote:
| I go to some pain in my talks to say "instruction count is
| not a good proxy for performance", but unfortunately folks do
| still use it. It's handy to say "hey, there's no loop in this
| output" or "this loop does 3 multiplies; the alternative does
| two and an add" or similar. It's a mixed blessing to have
| brought the compiler output to the masses, I can only hope it
| starts a useful learning process!
| MauranKilom wrote:
| Assuming that "caring about performance" = "you are in a
| tight loop": Here's a tool that simulates/visualizes
| instruction flow and data dependencies over multiple loop
| iterations.
|
| https://uica.uops.info/
|
| Paste in assembly code, check "Trace Table" and run, then
| "Open Trace". Not sure if it will help with your annoying
| colleague, but it gives a much more concrete idea about how a
| processor will execute any given code.
|
| Or, if you want to channel their energy into something
| slightly more direct, there's also https://quick-bench.com/
| which allows easy micro-benchmarking. Still not guaranteed to
| be relevant to any real-world scenario, but more data-driven
| than "vibes".
| vnorilo wrote:
| How $lang maps to assembly is half the picture: how assembly
| maps to CPU is the other half. We shouldn't blame ignorance
| of the latter on a tool for exploring the former.
|
| I do totally get how some people learn just enough to be
| annoying. Generally I still think that's not a good reason to
| gatekeep them.
| mwcampbell wrote:
| It's hard to measure performance in realistic situations;
| it's easy to measure code size. I recently found myself
| wasting time doing micro-optimizations, encouraged by the
| feedback loop of measuring and reducing code size (in my
| case, not with Compiler Explorer, but with "cargo bloat",
| since I was working on a Rust project.)
| sitkack wrote:
| I know you know this but instructions are basically free in
| the face of memory access and random memory access is the
| worst. Linear scans over contiguous memory (per thread)
| generally optimizes performance.
|
| Instruction counts are only useful if everything is
| guaranteed to be in registers.
| throwawy6969 wrote:
| curiousgal wrote:
| Do you all not need to understand assembly to advance the
| discussion?
| jfoutz wrote:
| yes but there's real value in exploration. I haven't touched
| c or assembly for a long time. here's a cold read.
| push rbp
|
| this is going to take the contents of rbp and push it onto
| the top of the stack - this will probably also change the
| stack pointer mov rbp, rsp
|
| move goes left <-, like a = 5, not 5 = a. so, copy the
| updated stack pointer into rbp mov
| DWORD PTR [rbp-4], edi
|
| now, I'm not 100% sure, but I believe this guy puts edi just
| under the value we pushed to the top of the stack
| mov eax, DWORD PTR [rbp-4]
|
| Take that value, and put it into eax, I'm not 100% sure why
| it's not just mov eax edi. imul eax,
| eax
|
| integer multiply, this is the part that does the double.
| pop rbp
|
| restore rbp (which we messed with) ret
|
| and we're done.
|
| there are at least three holes in my understanding - but
| those three are not _that_ hard to track down.
|
| 1, does the stack pointer actually auto increment? (I think
| it does) 2, imul overflow and setting sign flags and such. -
| that shouldn't be hard to run down.
|
| 3, what is the c calling convention? it looks like the
| argument is top of stack, but also in edi - is that shuffling
| really needed? I think there's a bucket of implicit behavior
| there that's kinda scary.
|
| I would _hope_ unless linking to a library, whatever called
| this, just did the imul eax eax.
|
| My understanding may be deeply flawed, but explaining my
| assumptions and my understanding does two things.
|
| 1, it helps me learn.
|
| 2, it helps others re-evaluate their assumptions and possibly
| see from a different viewpoint.
|
| I'm not saying spam compiler lists. But a clear and well
| thought out question can certainly advance discussion. It
| forces people to formalize their assumptions.
| umanwizard wrote:
| The default godbolt page runs the compiler with no flags,
| which means without any optimizations. This explains why
| the code unnecessarily shuffles stuff to the stack and
| back. Unoptimized clang/llvm output spills everything to
| the stack, and register allocation is an optimization.
|
| With -O3, the code is: imul edi, edi
| mov eax, edi ret
|
| Yep, the calling convention for x86-64 on Linux and macOS
| passes the first six integer arguments in rdi, rsi, rdx,
| rcx, r8, and r9, and then spills to stack.
| Sharlin wrote:
| And Win64 in rcx, rdx, r8, and r9.
|
| Having originally learned the basics of assembly on the
| chronically register-deprived x86, it took me a while to
| get used to the fact that standard CCs now pass things in
| registers (and rsi and rdi in particular, retaining their
| ancient names while being completely general-purpose
| these days).
| atq2119 wrote:
| FWIW, the stack grows downwards and push decrements the
| stack pointer.
| dtgriscom wrote:
| ... having trouble parsing this...
| umanwizard wrote:
| Assembly is not that hard to learn to read.
| einpoklum wrote:
| No, because:
|
| 1. You can figure out things about the assembly even without
| understanding assembly (e.g. lines of source translating into
| 0 lines of output vs many lines of output).
|
| 2. You have labels.
|
| 3. You can figure out some of the assembly on your own. Say:
| `mov %r1 %r2` - it probably moves what's in entity %r1 into a
| similar entity %r2, or vice-versa. etc.
|
| 4. You can see what the executable outputs
|
| 5. and most importantly: You can read compiler warnings and
| errors...
| whateveracct wrote:
| You can also RTFM and simply .. learn assembly.
| elromulous wrote:
| Seriously asking, how is it even possible to submit this to hn at
| this point? When one submits a previously submitted link, doesn't
| it just alias to the previous submission?
| josephcsible wrote:
| That only happens if the previous submission was recent enough.
| 5e92cb50239222b wrote:
| A decent interview with the creator in podcast form.
|
| https://cppcast.com/matt-godbolt-compiler-explorer/
| c-cube wrote:
| There's also 2's complement, a podcast by the author and a
| friend of his. It's pretty nice.
| https://www.twoscomplement.org/
| dang wrote:
| Related:
|
| _Compiler Explorer_ -
| https://news.ycombinator.com/item?id=24066570 - Aug 2020 (48
| comments)
|
| _Compiler Explorer_ -
| https://news.ycombinator.com/item?id=18671993 - Dec 2018 (44
| comments)
|
| _RMSbolt - An implementation of the Godbolt compiler-explorer
| for Emacs_ - https://news.ycombinator.com/item?id=18104167 - Sept
| 2018 (9 comments)
|
| _Compiler bug in MSVC?_ -
| https://news.ycombinator.com/item?id=16142512 - Jan 2018 (2
| comments)
|
| _C compiler undefined behavior: calls never-called function_ -
| https://news.ycombinator.com/item?id=15147335 - Sept 2017 (83
| comments)
|
| _GodBolt: Enter C, get Assembly_ -
| https://news.ycombinator.com/item?id=13182726 - Dec 2016 (151
| comments)
|
| _Compiler Explorer - now with side-by-side compiler comparison_
| - https://news.ycombinator.com/item?id=12627295 - Oct 2016 (6
| comments)
|
| _Compiler Explorer_ -
| https://news.ycombinator.com/item?id=11671730 - May 2016 (38
| comments)
|
| _Interactive C++ Assembly Explorer_ -
| https://news.ycombinator.com/item?id=9861294 - July 2015 (8
| comments)
|
| _See What Your C Function Compiles To_ -
| https://news.ycombinator.com/item?id=9808870 - June 2015 (2
| comments)
|
| _C /C++ Fiddle_ - https://news.ycombinator.com/item?id=7593109 -
| April 2014 (40 comments)
|
| _Interactively watch how your C++ gets compiled._ -
| https://news.ycombinator.com/item?id=4020814 - May 2012 (1
| comment)
| mattgodbolt wrote:
| Right...we turn up here every few months. Always grateful for
| the PR, of course :)
| kolbe wrote:
| Do you earn anything from this site? Even if you do, I can't
| imagine it's much relative to an Optiver salary. Why do you
| do it?
| RobotToaster wrote:
| It's interesting to see what the different levels of compiler
| optimisation produce.
| prasadi wrote:
| dorongrinstein wrote:
| Thank you Matt Godbolt for creating such a wonderful tool. You're
| as cool as they get!
| skybrian wrote:
| I didn't realize until today that Godbolt was someone's name. I
| had thought it was a whimsically named compiler tool. :)
| ainar-g wrote:
| I've only found out recently, thanks to the C++ Iceberg.
|
| https://fouronnes.github.io/cppiceberg/
|
| (Entries are clickable.)
| therein wrote:
| I hadn't realized it until I started working with him back in
| the day and saw his name on Slack.
|
| Wrote him a message and told him how much we appreciated his
| work at my previous workplace and how we used it all the time
| to settle debates about C++ code.
|
| Wonderful guy, back then he was very pleasantly surprised
| that people actually used his website.
| mattgodbolt wrote:
| It still surprises me too! I need to change my name to Matt
| Compiler-Explorer :D
| ChrisMarshallNY wrote:
| I've used Godbolt for years.
|
| The story that I heard, was that he was arguing with someone
| about some compiler optimization, and created the site to prove a
| point.
| tialaramex wrote:
| There's a CPPCon talk - which I'm sure somebody else can
| remember and link - where Matt explains how this started. IIRC
| He was initially wondering whether C++ iterators are _actually_
| the same price as the C-style for loops you 'd once have used
| instead with an index counting up or a pointer increasing. If
| it was _slower_ then in Matt 's industry that's useless, but if
| it's the same speed then the improved clarity of what you mean
| is valuable.
|
| Obviously the results will be identical but because the
| iterators _look_ fancy (and are easier to think about) maybe
| there 's some object getting constructed, it might be a _lot_
| heavier - right? Nope, same machine code. Matt initially did
| this much more manually, the Godbolt web site is just that same
| idea getting further enriched over time.
|
| This is even more striking for something like Rust's iterators
| that don't look at _all_ like it 's just the C-style for loop,
| there's a call to _make_ the iterator IntoIterator::into_iter()
| and then repeated calls to its next() method, sounds expensive
| - but nope, once again the optimiser can see what 's going on
| here and emit the same machine code. Having a tool like Godbolt
| to confirm (or sometimes refute) the belief that these things
| are actually the _same_ is really useful, as _even after
| confirming that optimisation is needed_ if the proposed
| "optimisation" doesn't change the machine code it wasn't an
| optimisation, just making the program needlessly harder to
| understand.
| Simran-B wrote:
| It's the CppCon 2017 talk with the title "What has my
| compiler done for me lately? Unbolting the compiler's lid".
|
| The Compiler Explorer backstory starts here:
| https://youtu.be/bSkpMdDe4g4?t=4m57s
| JadeNB wrote:
| > This is even more striking for something like Rust's
| iterators that don't look at all like it's just the C-style
| for loop, there's a call to make the iterator
| IntoIterator::into_iter() and then repeated calls to its
| next() method, sounds expensive - but nope, once again the
| optimiser can see what's going on here and emit the same
| machine code.
|
| > Having a tool like Godbolt to confirm (or sometimes refute)
| the belief that these things are actually the same is really
| useful, as even after confirming that optimisation is needed
| if the proposed "optimisation" doesn't change the machine
| code it wasn't an optimisation, just making the program
| needlessly harder to understand.
|
| I'm not sure I understand this. Wouldn't you expect higher-
| order code to be easier to optimise, since it comes closer to
| telling the compiler what you want to do, so that the
| compiler can figure it out, rather than forcing the compiler
| to divine the big-picture intention of a bunch of low-level
| instructions?
|
| And, if high-level code generates exactly the same machine
| code as low-level code, isn't that an argument in _favour_ of
| high-level code--it lets you code declaratively, saying what
| you mean--rather than _against_ high-level code? An
| optimisation might be optimising for intelligibility, not
| just run-time ... and, while an experienced low-level C
| programmer might find the low-level code more readable,
| surely the non-expert maintenance programmer who comes
| afterwards will be grateful not to have to recognise the low-
| level patterns but rather have them spelled out in high-level
| code?
| generichuman wrote:
| > Wouldn't you expect higher-order code to be easier to
| optimise, since it comes closer to telling the compiler
| what you want to do, so that the compiler can figure it
| out, rather than forcing the compiler to divine the big-
| picture intention of a bunch of low-level instructions?
|
| Optimization is an NP-hard problem. What compiler backends
| do these days is mostly to pattern match known optimizable
| code blocks. Some of the other optimizations are an
| approximation of the actual solution. The order of
| optimization type being made also affects the result.
|
| So in a perfect world where we could solve NP-hard
| problems, higher-level code (with more constraints put on
| it -- as in Rust traits, not C++ templates) would be easier
| to optimize. But since we don't live in that utopia, nope.
| saagarjha wrote:
| Perfect optimization is at the very least Turing
| complete.
| p1necone wrote:
| > I'm not sure I understand this. Wouldn't you expect
| higher-order code to be easier to optimise, since it comes
| closer to telling the compiler what you want to do, so that
| the compiler can figure it out, rather than forcing the
| compiler to divine the big-picture intention of a bunch of
| low-level instructions?
|
| This assumes a "sufficiently smart compiler", whereas if
| you write the exact low level basic for loop (or unroll it
| manually or whatever) you want you can be confident that
| even a pretty dumb compiler is still going to output
| something close to optimal.
|
| It just seems like most compilers are "sufficiently smart"
| for this sort of thing nowadays (and have been for quite
| some time). But it's not always the case, and the code you
| think would obviously be optimized by the compiler isn't
| always. So it pays to check these things if you're writing
| code for something where potentially eking out extra
| performance really matters.
| justshowpost wrote:
| Its better than the others but also very unprofessional as the
| other web stuff. It DOES link but its absolutely impossible to
| view generated map. People are just hyping about codegen related
| microoptimizations but don't care about layout at all.
|
| Very typical for today's world where javascript coder counts as
| software engineer.
| TobyTheDog123 wrote:
| First ran across this when looking into Carbon - it's a very cool
| tool!
| mattgodbolt wrote:
| Wow - we're on Hacker News again! Hello all, and thanks for the
| link and discussion! While we're here, we recently made some
| stats public: https://stats.compiler-explorer.com/ (spot the
| Hacker News spike!)
|
| General stuff: we're always looking for help; everything's open
| source on GH: https://github.com/compiler-explorer/ (the base
| project, our cloud setup, all our build scripts, etc). The most
| valuable way to help us is with issues and PRs, or hang out on
| our Discord (https://discord.gg/zNNgyRKh). Then spread the word,
| and last we welcome sponsors on GH
| (https://github.com/sponsors/mattgodbolt) or Patreon
| (https://www.patreon.com/mattgodbolt).
| chrisaycock wrote:
| And for those who haven't read it yet, here's Matt's own
| article in _ACM Queue_ :
|
| https://queue.acm.org/detail.cfm?id=3372264
| Genbox wrote:
| Hi Matt. Thank you for such an excellent project.
|
| I'm pretty sure you already know of sharplab.io. A lot of us C#
| devs prefer it over Compiler Explorer for a bunch of reasons,
| but the main one is really the speed.
|
| My guess is that Sharplab gets it speed because it hooks
| directly into the JIT compiler itself. There is no overhead
| from touching disk or the linker.
| andyayers wrote:
| IIRC with .NET 7 we will be able to improve this as we can
| now dump the jit-generated assembly from official builds.
|
| .NET 7 will be officially released in a month or so.
|
| Currently C#/F#/VB support in Compiler Explorer relies on
| prejitting which has various issues.
| mattgodbolt wrote:
| Hi Genbox, thanks for the kind words. I've never heard of
| sharplab.io - the speed of C# compilation is not very high on
| the priorities of CE right now (though we have some issues
| filed, and some (stale) PRs to help). We welcome help
| improving it!
|
| If you're talking about the speed of other languages than C#,
| then most of the time is in the compilers itself, not the
| fairly limited pre- and post-processing we do. We have a
| pretty sophisticated setup (at least, I think it is...) for
| handling the 1,500 compiler/language combinations, hundreds
| of libraries etc (around 2TB of data), but there's always
| tradeoffs between fast start-up time, manageability and
| simplicity of adding new compilers, and the run-time
| performance of running the compilers etc.
| dataflow wrote:
| Confused, how is this related to C++ compilers?
|
| Edit: Oh wow I didn't realize the website does other
| languages, thanks!
| vips7L wrote:
| Godbolt does more than C++. I often share Java byte code
| snippets from there
| mattgodbolt wrote:
| Why does it have to be related to C++ compilers? Compiler
| Explorer supports a number of languages, including C#:
| $ curl -sL https://godbolt.org/api/languages Id
| | Name csharp | C# fsharp | F#
| vb | Visual Basic go | Go
| c | C c++ | C++ fortran
| | Fortran assembly | Assembly circle
| | C++ (Circle) circt | CIRCT hlsl
| | HLSL cppx | Cppx crystal |
| Crystal dart | Dart erlang |
| Erlang carbon | Carbon hook |
| Hook cppx_blue | Cppx-Blue cppx_gold
| | Cppx-Gold mlir | MLIR cuda
| | CUDA C++ analysis | Analysis python
| | Python racket | Racket ruby
| | Ruby typescript | TypeScript Native d
| | D ada | Ada cpp_for_opencl | C++
| for OpenCL openclc | OpenCL C llvm
| | LLVM IR cpp2_cppfront | Cpp2-cppfront rust
| | Rust ispc | ispc java |
| Java kotlin | Kotlin nim |
| Nim pony | Pony scala |
| Scala solidity | Solidity clean
| | Clean pascal | Pascal haskell
| | Haskell ocaml | OCaml swift
| | Swift zig | Zig $
| the_only_law wrote:
| Thank you for making one of the coolest tools I found in the
| web in years.
| caramelcream wrote:
| Compiler Explorer is such a wonderful tool. It made examining and
| comparing compiler outputs so much easier and now pretty much
| everyone interested in optimizations is using it.
___________________________________________________________________
(page generated 2022-10-16 23:00 UTC)