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

socializer

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.

wallstop

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.

ninalanyon

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.

aappleby

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

alterom

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).

OutOfHere

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

dieselgate

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.

throwawayffffas

Just the branch predictor gains are probably worth it.

gorgoiler

Erm, no? You write f(w: Walrus) -> Walrus and then let the caller handle Walrus|None and Iterable[Walrus] however they wish! And if someone decides the codebase needs an abstraction over (and therefore specific functions to handle) Iterable[Walrus|None] then you check the weather and suggest they take a break and go for a stroll. (You check the weather to see if you should lend them your brolly.) What am I missing?

hatthew

Are we talking about this from the perspective of CS (algorithm optimization) or SE (code design)? From an SE perspective, make a flatmap function that explicitly handles Collection<Optional<Walrus>>. The implementation doesn't matter. If your language/framework already has a compatible flatmap function, make a single frobnicate(Optional<Walrus>) function that returns whatever value is necessary for flatmap(frobnicate) to discard them. From a CS perspective, doing a filter from Collection<Optional<Walrus>> to Collection<Walrus> is probably a bad idea. If your collection is small, nothing matters. If your collection is large, you probably don't want to spend time making a new copy of it. If your filter just returns a view rather than a hard copy, then there is no optimization benefit and you should just do whatever makes the most sense from an SE perspective. If frobnicate is cheap then you're paying the branch prediction failure tax anyway regardless of when you frobnicate, and if frobnicate is more expensive then your should probably parallelize and have each thread handle unpacking the Optional. Either way, you probably don't want to spend time making a copy. These are all generalizations based on hypotheticals and there are certainly a lot of exceptions, but broadly speaking I don't see a strong argument here. If optimization matters then optimize based on your own profiling of your situation, and if optimization doesn't matter then design your functions based on what features and paradigms are available/common in your area.

ivanjermakov

Save some time and read the original post instead: https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...

rtpg

I've always believed the opposite: get conditionals deep in your code so that the higher level control flow is regular. But I suppose my greater philosophy for making code that avoids bugs is that you have a couple things that are done when dealing with data: - distribution - deciding And you want to avoid distribution and deciding being mixed together in the same spot. "Distribution" can be for loops but also breaking up some data based on some key into N bistinct buckets "Deciding" is where you're looking at the data more closely to make some decision (like "is this a big customer or a small customer") Distribution often involves decision making, but if you mix them all in one spot you can obfuscate your decision points. Splitting it up just makes things "obviously" right or "obviously" wrong. Perf stuff is another discussion of course, but in practice most things are not at a scale where it matters. by_category = defaultdict(list) for d in data: by_category[category(d)].append(d) for category, per_category_data in by_category.items(): do_thing(category, per_category_data) I really value code patterns that make mistakes obvious, or at least makes it harder to stuff a mistake in somewhere. Some patterns are harder to describe in this model though. (I do like the advice of having a consistent vocabulary for working on collections as a principle though, I just find that top-level conditional use tends to quickly get you into "... why is this method not called" territory, which is a more annoying problem than "why is this slow")

4b11b4

this is just a guard on the function definition?

sigbottle

Is the idea that "accidental casework" should be moved up, whereas the "reusable bulk ontology" should be moved down? There's very high-leverage abstractions that completely constrain a space. An example is a good definition - you can't think of something outside to compare it to, it just is. These things survive for a long time since they define it. But if you're trying to do that philosophy super deep into a program, you're probably violating a bunch of invariants subtly. Of course, there is no good separation at the end of the day as we all know from spaghetti codebases :)

andy_ppp

Idiomatic Elixir does this with pattern matching on function parameters so you end up with things like the following, raw if statements are discouraged because of this: def classify(:ok) def classify({:error, reason}) def classify([first | rest]) def classify(%{name: name, age: age}) when age >= 18 def classify(%{name: name, age: age}) when age < 18

Chinjut

Push lists of 0 or 1 up, but push lists of 0, 1, 2, 3, or etc, down?