When Compilers Surprise You
Key topics
The art of compiler optimization is on full display in a discussion sparked by a surprising compilation quirk, with commenters weighing in on whether the outcome is truly surprising or just basic optimization. Some argue that the sum of integers question posed by one commenter is a great litmus test for developers, while others dissect the intricacies of floating-point math, revealing that a closed-form solution exists under certain conditions. As the debate unfolds, it becomes clear that the real value lies not in getting the "right" answer, but in understanding the underlying algebraic properties and compiler passes at play. The conversation takes a turn when some commenters call out the original questioner's interview technique, suggesting it's more about showing off than genuinely assessing a candidate's skills.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
54
0-6h
Avg / period
13.4
Based on 107 loaded comments
Key moments
- 01Story posted
Dec 24, 2025 at 8:27 AM EST
14 days ago
Step 01 - 02First comment
Dec 24, 2025 at 9:39 AM EST
1h after posting
Step 02 - 03Peak activity
54 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 26, 2025 at 7:42 PM EST
11 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
The sum of integers is actually a question I ask developers in interviews (works well from juniors to seniors), with the extra problem of what happens if we were to use floating-point instead of integers.
I know compilers can do some crazy optimizations but wouldn't have guessed it'll transform something from O(n) to O(1). Having said that, I dont still feel this has too much relevance to my actual job for the most part. Such performance knowledge seems to be very abstracted away from actual programming by database systems, or managed offerings like spark and snowflake, that unless you intend to work on these systems this knowledge isn't that useful (being aware they happen can be though, for sure).
This kind of question is entirely useless in an interview. It's just a random bit of trivia that either a potential hire happen to have come across, or happens to remember from math class.
You can be surprised about things you know for years.
For example I am surprised every time I think about js coalescing even tougth I know it for decades.
https://x.com/chrisgseaton/status/619885182104043520
https://x.com/chrisgseaton/status/619888649866448896
Anyone who dumbly suggests that loops in source code will result in loops in assembly doesn’t have a clue. Anyone who throws their hands up and says, “I have no idea, but I wonder if there’s some loop invariant or algebraic trick that can be used to optimize this, let’s think about it out loud for a bit” has taken a compiler class and gets full marks. Anyone who says, “I dunno, let’s see what godbolt does” gets an explicit, “hire this one” in the feedback to the hiring manager.
> In fact, it sounds like something you wouldn't expect them to know.
I’d go a step further, I don’t think anyone, no matter how experienced they are, can confidently claim that optimized assembly will or won’t be produced for a given loop. If performance really matters, you have to investigate and confirm that you’re getting good code. You can have an intuition for what you think might happen, and that’s a useful skill to have on its own, but it’s totally useless if you don’t also know how to confirm your suspicions.
For example it can only parallelize code which is inherently parallelizable to begin with, and unless you design your algorithm with that in mind, it's unlikely to be.
My belief is that it's better to be explicit, be it with low-level or high-level abstractions.
I generally focus more on sum of arbitrary data, but I used to also ask about a formulaic sum (linear to constant time) as an example of something a compiler is unlikely to do.
My thinking is that I expect good engineers to be able to do those optimizations themselves rather than rely on compilers.
Also this series is targeted towards more of a beginner audience to compilers, thus its likely to be suprising to the audience, even if not to you.
I barely know anything about compiler optimization, so I have no clue whether a compiler applying this optimization is surprising or something trivial.
For you are essentials.
You and the juniors you hire must have a deeper knoledge than him.
I spend a lot of time looking at generated assembly and there are some more impressive ones.
It would be great if you shared it with the world like Matt does instead of being smug about it.
“basic and essential” are interesting ways to describe the field of compiler optimization research.
Are you suggesting that the discovery and implementation of SCEV in LLVM is basic and essential? Or that summing integers in a range is basic and essential?
https://github.com/llvm/llvm-project/blob/release/21.x/llvm/...
Maybe you have much more experience than Mr Godbolt in compiliers.
If you mean graph coloring restricted to planar graphs, yes it can always be done with at most 4 colors. But it could still be less, so the answer is not always the same.
(I know it was probably not a very serious comment but I just wanted to infodump about graph theory.)
This kind of optimization, complete loop removal and computing the final value for simple math loops, is at least 10 years old.
Seems like the author is both surprised and delighted with an optimization they learned of today. Surely you’ve been in the same situation before.
https://github.com/llvm/llvm-project/blob/release/21.x/llvm/...
https://kulkarniamit.github.io/whatwhyhow/howto/use-vim-ctag...
The idea of good abstractions and such falls apart the moment the target environment itself is not a good abstraction.
If it was 16K lines of modular "compositional" code, or a DSL that compiles in some provably-correct way, that would make me confident. A single file with 16K lines of -- let's be honest -- unsafe procedural spaghetti makes me much less confident.
Compiler code tends to work "surprisingly well" because it's beaten to death by millions of developers throwing random stuff at it, so bugs tend to be ironed out relatively quickly, unless you go off the beaten path... then it rapidly turns out to be a mess of spiky brambles.
The Rust development team for example found a series of LLVM optimiser bugs related to (no)aliasing, because C/C++ didn't use that attribute much, but Rust can aggressively utilise it.
I would be much more impressed by 16K lines of provably correct transformations with associated Lean proofs (or something), and/or something based on EGG: https://egraphs-good.github.io/
gcc was and is an incredible achievement, but it is traditionally considered difficult to implement many modern compiler techqniques in it. It's at least unpleasant, let's put it this way.
https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-chrec... https://github.com/llvm/llvm-project/blob/release/21.x/llvm/...
On the other hand, I find MSVC and especially ICC output to be quite decent, although I have never seen their source code.
Having inspected the output of compilers for several decades, it's rather easy to tell them apart.
https://www.youtube.com/watch?v=bSkpMdDe4g4&t=2640
1. organized data flow analysis
2. recognizing a pattern and replacing it with a faster version
The first is very effective over a wide range of programs and styles, and is the bulk of the actual transformations. The second is a never-ending accumulation of patterns, where one reaches diminishing returns fairly quickly.
The example in the linked article is very clever and fun, but not really of much value (I've never written a loop like that in 45 years). As mentioned elsewhere "Everyone knows the Gauss Summation formula for sum of n integers i.e. n(n+1)/2" and since everyone knows it why not just write that instead of the loop!
Of course one could say that for any pattern, like replacing i*2 with i<<1, but those pattern replacements are very valuable because they are generated by high level generic coding.
And you could say I'm just being grumpy about this because my optimizer does not do this particular optimization. Fair enough!
A hard problem in optimization today is trying to fit code into the things complex SSE-type instructions can do. Someone recently posted an example where they'd coded a loop to count the number of one bits in a word, and the compiler generated a "popcount" instruction. That's impressive.
https://en.wikipedia.org/wiki/Wilf%E2%80%93Zeilberger_pair