Common misconceptions about compilers

&gt; As an example, in my desktop, it takes ~25min to compile a Debug version of LLVM, but ~23min to compile a Release version.<p>oh I think I know what might cause this: TableGen. The `llvm-tblgen` run time accounts for a good chunk of LLVM build time. In a debug build `llvm-tblgen` is also unoptimized, hence the long run time generating those <i>.inc &#x2F; </i>.def files. You can enable cmake variable `LLVM_OPTIMIZED_TABLEGEN` to build `llvm-tblgen` in release mode while leaving the rest of the project in debug build (or whatever `CMAKE_BUILD_TYPE` you choose).

&gt; The compiler optimizes for data locality<p>&gt; So, we have a single array in which every entry has the key and the value paired together. But, during lookups, we only care about the keys. The way the data is structured, we keep loading the values into the cache, wasting cache space and cycles. One way to improve that is to split this into two arrays: one for the keys and one for the values.<p>Recently someone proposed this on LLVM: <a href="https:&#x2F;&#x2F;discourse.llvm.org&#x2F;t&#x2F;rfc-add-a-new-structure-layout-optimization-pass&#x2F;80596" rel="nofollow">https:&#x2F;&#x2F;discourse.llvm.org&#x2F;t&#x2F;rfc-add-a-new-structure-layout-...</a><p>Also, I think what you meant by data locality here is really optimizing data layout, which, as you also mentioned, is a hard problem. But if it&#x27;s just optimizing (cache&#x27;s) locality, I think the classic loop interchange also qualifies. Though it&#x27;s not enabled by default in LLVM, despite being there for quite a while.

About C&#x2F;C++ compilers, mostly.<p>C++ has terrible template and include compilation problems, for historical reasons.

How about reproducibility?<p>I always took for granted most compilers will generally output consistent binary code given identical inputs. Then the other day I saw a post here about optimization timeouts and such.

&gt; Knowing which paths are hot in any Javascript bytecode is not enough to produce optimized code; you also need to know the types. And you only know the types at runtime. This is the main reason why JIT compilers compile code at runtime.<p>You can often make good guesses statically. Especially if your JavaScript was produced from something like a TypeScript source.

Why does optimal substructure work for code size? Couldn&#x27;t you take a compiled non-minimal function and break each instruction into a function call (with some assumptions about the ISA maybe), then assuming each single-instruction function is minimal by itself, infer the entirety is minimal, contradicting?

Nice write-up and overall very informative blog. Kind of off topic, but are you Stefanos, doing your PhD at UIUC? That&#x27;s my alma mater, I hope you find the academic* environment there stimulating!<p>*Let&#x27;s not talk about the social environment of UC.

<i>&gt; -O3 produces much faster code than -O2</i><p>Also “-Ox gives similar results all the time”. Any optimisation is a gamble, some of them quite unsure gambles. Different cache sizes and management strategies between processing units mean that what might be a small benefit for one could be a detriment when the code is running on another, and even if you specifically tune the optimisations for a given set of chips you are at the mercy of the incoming data which could invalidate any educated guesses made about branch likelihood and so forth.

If you have both an interpreter and compiler, then boostrapping the (self hosted) language is a lot simpler. The interpreter is written in some widely available language like C. The interpreter runs the compiler and standard library code of your language in order to compile that compiler and standard library. After that, those parts execute as native machine code or byte code (with or without JIT).<p>Without the interpreter, you have to ship the compiled versions of those parts, even to someone building your language from scratch. Or perhaps ship an entire prebuilt package of the language.<p>An interpreter creates a third opinion on what code should do, resulting in a documentation-interpreter-compiler triangle, where in a situation in which it is unclear what the right behavior is, weight can be given to the situation that two out of those three pieces agree.<p>Optimized versus unoptimized isn&#x27;t exactly the same, because there is a dependency. If unoptimized translation has a certain behavior, and optimization doesn&#x27;t wreck it (prevalent case), then of course the two are going to agree. Their agreement doesn&#x27;t carry weight against documentation. An interpreter and compiler are almost totally independent, except for where they get the code to share run-time support and library functions.

Re: Why does link-time optimization (LTO) happen at link-time?<p>I think maybe LLVM&#x27;s ThinLTO is what you&#x27;re looking for where whole-program optimization (more or less) happens in middle end.

Good observations but a more accurate title would be common misconceptions about c&#x2F;c++ compilers. I point this out because I think that there is a lot of room for compiler innovation that will come from developing new compilers for new languages and I don&#x27;t want us to continue being anchored in the mistakes of the past.

&gt; For example, minijava-cpp is a MiniJava compiler written in C++ which has some pretty heavy code in it. It compiles in ~0.7s in my laptop, while linking all these separate files takes much longer.<p>I can&#x27;t reproduce this result at all. Using compile.sh it takes my 7950x 0.9s to compile the whole project. A quick meson&#x2F;ninja setup took 0.8s from a clean build directory, and just 0.043s to link using gnu-ld. Using faster linkers yields even better results: 0.025s for gold and 0.013s for mold. I&#x27;m curious how you got your results?<p>&gt; SQLite, too, compiles everything into a single .c program.<p>It takes my computer 25 seconds to compile sqlite when making incremental changes. My work&#x27;s similarly sized C++(!) repo links 3 executables in 0.07s using mold.<p>I&#x27;m having a really hard time seeing how unity builds could possibly be faster. Maybe with an exceedingly terrible linker or spinning rust?

Hey folks, author here. I&#x27;m really happy the article has gotten such attention. I hope it&#x27;s good attention and that you folks learned something! Unfortunately, though, it&#x27;s _very_ hard to keep track of all the comments in HackerNews. So, if you have a comment you&#x27;d like me to reply to and I haven&#x27;t, please either use the Reddit post: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Compilers&#x2F;comments&#x2F;1hapetl&#x2F;common_misconceptions_about_compilers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Compilers&#x2F;comments&#x2F;1hapetl&#x2F;common_m...</a><p>or head over to my website: <a href="https:&#x2F;&#x2F;sbaziotis.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sbaziotis.com&#x2F;</a> for more contact info.<p>Best, Stefanos

If the author is here: the link from the table of contents to &#x27;-O0 gives you fast compilation&#x27; is broken.

&gt;Separate compilation is always worth it<p>&gt;Separate compilation is the idea that you compile a different object file for each source file.22 The reasoning of why this is beneficial is that if you change one source file, you only have to re-compile that one file and &quot;just&quot; link it with the other object files; you don&#x27;t have to re-compile the whole project.<p>That reflects my feelings that linker is bullshit step