The surprising cleverness of modern compilers

http://lemire.me/blog/2016/05/23/the-surprising-cleverness-of-modern-compilers/

by kiyanwang • 10 years ago

144 83 10 years ago

danso• 10 years ago

We test people’s intelligence in room, disconnected from the Internet, with only a pencil. But my tools should get as much or even more credit than my brain for most of my achievements. Left alone in a room with a pencil, I’d be a mediocre programmer, a mediocre scientist. I’d be no programmer at all. And this is good news. It is hard to expand or repair the brain, but we have a knack for building better tools.

Reminds me of what Kasparov said in his essay analyzing the rise of "centaurs" in chess competitions:

http://www.nybooks.com/articles/2010/02/11/the-chess-master-...

Programming yourself by analyzing your decision-making outcomes and processes can improve results much the way that a smarter chess algorithm will play better than another running on the same computer. We might not be able to change our hardware, but we can definitely upgrade our software.

edit: fixed the errant double-copy-paste

mjlee• 10 years ago

Did you mean to quote the same passage twice?

dTal• 10 years ago

Hey, thanks for linking this. What an entertaining, insightful piece of writing!

_yosefk2• 10 years ago

Indeed, Clang/LLVM did a stellar job here. It'd be interesting to know how (in part to understand what situations can one expect this sort of thing to happen; for instance, I'd be surprised if IEEE floating point emulation code would be compiled to a hardware floating point instruction - though perhaps I underestimate the optimization passes at work here!)

TorKlingberg• 10 years ago

I bet there is a specific optimization that recognizes common patterns for counting the number of set bits and replaces it with popcntq. There is no popcnt() function built into C, so everyone who needs it uses one of a few common implementations.

ninjabeans• 10 years ago

This sounds the most plausible.

psuter5• 10 years ago

Indeed: https://github.com/llvm-mirror/llvm/blob/ae889d36724efb174e8...

pcwalton• 10 years ago

Yes. Many compilers, including LLVM, have an "idiom recognizer" (in LLVM parlance) that detects memsets, memcpys, population counts, etc. and turns them into calls to the optimized implementations.

acqq2• 10 years ago

It'd be interesting to know how

Do you mean how this things are implemented in general or how come that this particular function was reduced to one instruction? The answer to later wrote gjm11 here: https://news.ycombinator.com/item?id=11764800 (it was to make LLVM good at some benchmark!)

The answer to former is: once the sorce code ins transformed to some intermediary form, a lot of optimizations simply look for the "best match" for different patterns and then replace the matched intermediary form sequence with the replacement sequence. Once you have an infrastructure in your compilers, it's typically not so hard to add one more "replace this with that" to get this result to win the benchmark.

mzs• 10 years ago

Site is slow, here is the bug report:

https://llvm.org/bugs/show_bug.cgi?id=1488

Too bad it won't optimize in the face of clever code like this:

http://www.hackersdelight.org/hdcodetxt/pop.c.txt

spoiler• 10 years ago

Just a side-comment: I never actually needed to count bits, but this technique illustrated in the post is quite clever! I had to stop for a second to understand what it actually does: Essentialy, each iteration will remove the least significant high bit from the number (or the right-most bit, if you represent the number LTR). and then continue to do so until there's no high bits left (or the number is zero)!

It's so simple, but to be honest, I don't think I would come up with it without putting in some mental effort.

rosstex• 10 years ago

I teach Data Structures at UC Berkeley, and this is one of our most challenging problems each year: find a one-line expression to get the least significant bit of a number. x & (x-1)! It exploits some very interesting magic of binary numbers.

kevinwang2• 10 years ago

Why not (x & 1) ?

carl_dr• 10 years ago

Doesn't that give you numbers which are a power of two? ie, x&(x-1) is zero if x is a power of two?

xentronium• 10 years ago

Clarification: clear (not get) the least significant bit.

psuter5• 10 years ago

There is a classical page full of such things [1]. Not so long ago researchers looked into how to come up with such tricks automagically using program synthesis [2].

[1] https://graphics.stanford.edu/~seander/bithacks.html

[2] http://www.eecs.berkeley.edu/~sseshia/pubdir/synth-icse10.pd...

lisper14• 10 years ago

There is an often-missed elephant in the compiler optimization living room in the form of poor language design leading to a tremendous amount of wasted human effort. First, effort is demanded of the programmer to write the clever optimized C code in the first place, and then effort is demanded of the compiler writers to recognize the clever optimized C code and compile it down to the native instruction that does the Right Thing.

All of this effort could be eliminated simply by adding a function to the standard library called bitcount. This would make life easier for both the programmer, who could now count bits by calling bitcount, and the compiler writers, who no longer have to write and maintain code that recognizes clever hacks.

This (counting bits) is not an isolated incident either. There is an entire field of academic endeavor devoted to this sort of thing, focusing particularly on recognizing common idioms involved in vector and array processing. All of this could be eliminated at a stroke through better language design. Instead, an entire academic field dons the ball-and-chain of a poorly designed language and then pats itself on the back for getting to the finish line panting and sweating, and people like me who say, "Um, why not just take off the extra weight and use a better designed language?" get marginalized at best and vilified at worst.

adrianN• 10 years ago

Better language design unfortunately doesn't eliminate the other elephant in the room: legacy code. Compilers do provide intrinsics for some of these hacks, counting bits for sure. But old code doesn't use them and yet the compiler should create optimal instructions.

lisper14• 10 years ago

Trying to make legacy code run faster through horrible compiler hacks rather than fixing the legacy code is a deal with the devil. The net result of that strategy is a horrible pile of hacks, many of which are there fore no reason other than to undo the deleterious effects of previous hacks. The long-term cost of maintaining all that complexity is far greater than the cost of just doing the Right Thing in the first place. Nowadays there is absolutely no excuse for continuing to use languages with built-in design compromises that were put in simply because the compiler had to fit in 64k of RAM. People keep doing it because doing the Right Thing front-loads the cost. But another name for "front loading costs" is "making an investment" which is generally considered a Good Thing in other walks of life. But for some reason, not in software.

sliverstorm• 10 years ago

Option A: Maybe it's acceptable for legacy code to be compiled less-optimally? If it was fast enough on a Pentium 4, it should run fine on modern chips even without some optimizations

Option B: How often is legacy code recompiled, anyway?

Option C: Why not compile legacy code with legacy compilers? Sure the hack was removed upstream, but that doesn't stop you from using a copy of gcc circa 1995

Option D: If it needs to be maximally fast, and is routinely recompiled on a wide range of systems with a variety of compilers (e.g. Linux kernel), maybe it's worth rewriting.

cremno• 10 years ago

Please don't bait other users by inviting them to downvote you or announce that you expect to get downvoted.

https://news.ycombinator.com/newsguidelines.html

lisper14• 10 years ago

Ironically, I see you're getting downvoted, but you shouldn't be because you're right: I violated HN guidelines, so I edited my comment to remove the offending passage. Thanks for pointing this out.

mikeash2• 10 years ago

gcc and clang both provide a builtin for this, __builtin_popcount. There are a bunch of other useful things like that too:

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

Of course, that doesn't save you from writing the long version if you need portable code, but it's a step in the direction you describe.

psuter5• 10 years ago

Make sure to use __builtin_popcountl to count bits in a uint64_t, or you may miss half of them (yes it happened to me).

lisper14• 10 years ago

it's a step in the direction you describe.

Well, sort of. This is not about any one particular optimization. This is about the general pattern of having one human take a high-level concept (like counting bits) and reducing it to a low-level implementation, and then having a second human writing a compiler which tries to reverse-engineer the work that the first human did in order to figure out that they were trying to count bits so that it can emit code that actually does the Right Thing.

So yes, __builtin_popcount does improve the situation a little bit, but it perpetuates a whole host of other problems. For example:

1. It has the wrong name. The right name for a function that counts bits is "bitcount", not "popcount" (and certainly not __builtin_popcount!) The __builtin is there because C doesn't have a proper name spacing system, and so using __builtin_popcount perpetuates that problem in the same way that clever compiler optimizations perpetuate other bad aspects of C's design.

2. __builtin_popcount only works on unsigned ints. If you want to count bits in anything else (a string, say, or a bignum) you're back to square 1.

To really fix this problem you need a general mechanism for expressing high-level concepts that a compiler can now about and optimize directly. For that, C is completely hopeless. You need a new language.

greg7mdp• 10 years ago

That's the whole point, even from the long version, clang figured out that it was doing a popcount and emited a single popcntq instruction. Nice!

_RPM2• 10 years ago

Pop count returns the number of set bits. So it most useful for figuring out if a number is a power of two. If there are more than 1 "set" bits, then it is NOT a power of two. However, a non portable way of determining how many bits are in a object would be this expression, assuming 8 bits are in a byte. `sizeof(object) * 8`

trishume• 10 years ago

Rust does exactly this in many cases. All the integer types have methods like 'count_ones' for popcount and 'trailing_zeros' for ctz, things that are intrinsics in other languages. See http://doc.rust-lang.org/1.8.0/std/primitive.u64.html#method...

kibwen• 10 years ago

Though note that these methods are really just thin abstractions over intrinsics, since Rust doesn't want to stabilize intrinsics directly for reasons of compiler backend portability. For example, the `count_ones` method currently resolves directly to LLVM's `ctpop` intrinsic, defined at https://github.com/rust-lang/rust/blob/master/src/libcore/in... .

greglindahl2• 10 years ago

Your point on vectors and array processing is not a good one: Some significant numerical algorithms can be easily expressed with nested loops, and are a pain to express with array operations. Fortran has both, and some of the best compilers turn array operations into loops, to ensure that they get both forms right.

Maybe you could spend more time understanding other points of view, rather than feeling marginalized or vilified?

lisper14• 10 years ago

Some significant numerical algorithms can be easily expressed with nested loops

Like for example?

Just to clarify, I'm (obviously) not suggesting that nested loops be eliminated from the language, or that common optimizations on nested loops be eliminated from compilers. But having specialized code to recognize a clever idiom for counting bits is IMHO going way too far.

It's true that I'm not intimately familiar with numerical algorithms, so I could be wrong about this, but my impression is that the number of "significant numerical algorithms" that can be easily expressed as nested loops is not that large: dozens, not hundreds. Unless I'm wrong about that, I stand by my position that the best way to handle these is to enumerate them and then allow them to be expressed directly.

amelius• 10 years ago

One big problem I see, is that these tricks make the compiler unpredictable in terms of performance. Add a line somewhere in the middle, and the compiler might no longer recognize the construct, and suddenly your code runs 10x slower. Try debugging that :)

JBReefer• 10 years ago

Yeah, you can't print that halfway through and get the killer performance (not that printf is fast)

DerekL• 10 years ago

There's a proposal to add them to the C++ standard, but I don't know its current status. “A constexpr bitwise operations library for C++”: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n386...

SilasX2• 10 years ago

Great thinking! So that way, if you need to leftpad a string, you could just import the well-maintained leftpad function ...

gravypod• 10 years ago

The principle is sound. Would you rather there be 500 non standard implementations of left-pad or should there be one fast and optimized implementation of left pad?

The only issue that leftpad demonstrated was that there was NO method for dependency resolution of removed libraries.

psuter5• 10 years ago

Seems to be a built-in, extremely specific use case: https://github.com/llvm-mirror/llvm/blob/ae889d36724efb174e8...

I suppose it makes sense, given: 1) popcount is very common in bit-manipulating programs, 2) there is no standard popcount in ISO C, 3) it potentially saves 100+ instructions.

(Edit: I see a comment on Lemire's blog already points to that.)

pera• 10 years ago

I was not aware of the popcnt[1] instruction. It's quite amazing how LLVM can recognize that code, thanks for the link!

[1] https://en.wikipedia.org/wiki/SSE4#POPCNT_and_LZCNT

outworlder• 10 years ago

What does that mean? It means that C is a high-level language.

For this specific example, isn't the reasoning backwards? The machine instruction is clearly the "high level" here, if you disregard the fact that it is, in fact, a machine instruction, thus there can be no "lower level" (ignoring microcode, an implementation detail).

Of course, you cannot say that, in general, C is lower level than X64 assembly. However, just to illustrate, replace the popcntq instruction with some Scheme function, and try arguing that it is at a "lower" level. The argument won't work. In fact, people would think you were talking about a "decompiler", instead.

EGreg• 10 years ago

Yes tools are a big part of augmenting intelligence. However!! The biggest thing that computers have over humans is the replicability of programs.

A human, somewhere, figures out a correct solution or a better algorithm, then it gets propagated and replicated.

A self-driving car "learns" something in its experience on the road. That information is propagated using a pre-existing system. Now all self-driving cars eventually improve and outperform typical humans.

Watson collects disease incidence rates and diagnoses from around the world, so the "big data" eventually allows it to make decisions that a single doctor would not be abls to make.

It's the easy copying of bits that makes this possible.

A photo in the 1960s could be imperfectly reproduced, on a newfangled "copy machine". Before that, photos were set up and printed using huge printing presses. The more copies are made of a photo is reproduced, the more likely it is to survive the destruction of the physical media it is embedded in.

But in the past, making perfect copies was very expensive. Today, the copying of bits is what has brought the price down of copying information. And this is the key to the intelligence revolution.

Humans were able to zoom ahead because of language. It provided ways of propagating information and copying it. Although the copies were imperfect, it is what made every generation smarter than the last.

Anyway, the "easy copying" is a feature of a platform. The humans are still the ones banging away at the platform. And that's why open source beatthe proprietary software. The same reason why science made progress -- anyone anywhere can make an incremental improvement, that is then recognized and propagated according to some political system in place.

And that is what produces the explosion in intelligence.

The things we can improve now are the political systems that govern which information is propagated. Should they be centralized? Decentralized? Who determines what goes in? How to deal with versions and dependencies?

The fact that we keep reinventing the same things (NoSQL) going in circles (thin client / thick client, JS framework fads) locking out users (Apple, MS Secure Boot) and bloating our computer languages (C++, JS, PHP, etc.) are just symptoms that we haven't figured out the best ways to keep moving forward.

gjm112• 10 years ago

One of the comments on that article links to this https://llvm.org/bugs/show_bug.cgi?id=1488 which rather suggests that this surprisingly specific optimization was added in order to speed up some calculations in one of the SPEC benchmarks.

(The benchmark in question is code from a chess program called Crafty, which represents a chess position as a bunch of 64-bit bitmaps. Unsurprisingly, 64-bit popcount is quite often useful for this.)

treerex• 10 years ago

Compiler vendors have been doing stuff like this (recognizing specific code patterns from common benchmarks) for 30 years, back in the days when there was real competition amongst C compilers (Borland vs. Zortech, for example.)

gjm112• 10 years ago

Yup. But the HN discussion of this one seemed to be treating it as an instance of compilers being terribly clever to benefit their actual users, rather than yet another benchmark hack.

pklausler• 10 years ago

The problem with this kind of idiom recognition is that it must be conservative. That rules out lots of cases involving floating-point arithmetic and memory references.

In the particular example of population count: this has been a hardware instruction on many processors since the early 60's. It is a crying shame that it's not part of the modern C language or standard library.

flamedoge• 10 years ago

it gets hard to benchmark “algorithms”

The cleverest of all C compilers that I know do not even attempt to rewrite algorithm to a "smarter" one (they're not there.. yet). All this does is translate popcount algorithm to a hardware instruction, which one would presume affects the performance linearly.

The surprising cleverness of modern compilers

Related Stories