When looking at code performance, it's important to remember that conditional branches are almost always cheap inside microbenchmarks, because the CPU can figure out when the same branches get taken on every loop... but far more expensive in the real world. A similar issue applies to cache: Your code might fit inside the L1 cache in your benchmarks, but when it's used in the real world you get cache misses since the rest of the program accesses data too.

> Then, a bit later, we need to very quickly finish populating the structs.

I am finding it extremely hard to envision a circumstance where this is a bottleneck for anything. Care to clarify the context?

I also find the struct layout really odd; why not just move c?

Your benchmarks are also probably broken; branch predictors use global state so will almost certainly predict fine the way you've used things. You need to repopulate a significantly-sized array each time with randomly chosen values. You can't use the same array because it'll be learnt, and you can't use a short array because it'll be predicted globally.

Quick upvote for a well designed mobile friendly site. The last few HN posts I read were awful on mobile.

This is not so much "outsmarting the compiler" as "working with the compiler" - tweaking code to trigger certain optimizations/generate particular output. The missing part, of course, is showing that these optimizations actually help...

How does this wrapper and each variant connect together? I supposed he would include a pointer to the actual struct in the wrapper, but I just see payload (that I'm gonna assume needs to be written to that array with padding in the actual struct).

For me, a wrapper includes the original thing and just wraps stuff around it. How does this work here? May also be a question to the author, I suppose now...

So why wouldn't you just put c before the arr[padding#] chars?

gcc warning: ISO C++ forbids zero-size array ‘payload’ [-Wpedantic]

clang warning: flexible array members are a C99 feature [-Wc99-extensions]

is this still the case?

Outsmarting the compiler: A short story about optimisation:

"Don't."

The end.

(Basically, as the story shows, with this kind of micro-optimization you may or may not beat the compiler but you're almost certainly wasting your time compared with more effective optimization methods, like rethinking the problem.)

This is stupid because it categorically denies the business case for micro-optomization.

Yet, a business case might exist when the library is heavily utilized, or often when a compiler isn't able to produce the correct code.

There are also cases primarily, in finance, where single threaded low-latency distinguishes competing groups. Some of those guys count every nanosecond.

The techniques described here ( and in other places) are universally applicable.

In this case, yes, optimizations don't appear to be giving me much of a win. Although, I'm very glad I checked! There are certainly some very realistic scenarios in which it would be valuable to save this branch.