Push ifs up and fors down: The idiom, its algebra, and its limits

I am continually impressed by the ability of LLMs to take trivial ideas and turn them into lengthy and obtuse blog posts with unnecessary analogies.

I've done this for years. Not every time of course but where it makes the code easier to understand and maintain.

Speed was almost never the reason.

What is missing here is any benchmarks backing up this argument for code structure.

Of note, as of C#9 (and maybe prior), the dotnet runtime does this automatically whenever it is deemed safe. https://devblogs.microsoft.com/dotnet/performance-improvemen...

The same technique is applied as an optimization, when deemed safe, in all current gen c compilers (gcc, llvm, etc).

I'm very confused why neither measurements nor references to when this is done automatically in most modern languages is included in the article.

Just the branch predictor gains are probably worth it.

Didn’t see it mentioned in the article but isn’t leading with if-statement called a “guard clause”. I like that pattern but it’s just general best practice I thought.

I have always phrased this as "Never do one of something".

I like it, but to do fizzbuzz in this way, you'd have to separate what's inside the loop into a reused function.

TL;DR in one sentence:

"the loop runs without a branch, and is a candidate for vectorization".

That's it, that's the article. This matters a lot in huge-scale / scientific computing / HPF, where if you can express something as an operation on vectors on matrices, you win big (those ops parallelize well, can be run on GPUs, clusters, what have you).

[dead]