Rendered at 23:41:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
hatthew 24 minutes ago [-]
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.
socializer 4 hours ago [-]
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.
robofanatic 59 minutes ago [-]
And also generate a shorter version.
mathisfun123 56 minutes ago [-]
Semantic compressor and decompressor
swiftcoder 3 hours ago [-]
Honestly, this just looks like one of those lingo-heavy-but-surface-level blog posts that used to make functional programming spaces so insufferable to everyone on the outside
ahartmetz 1 hours ago [-]
You want to avoid branches in hot paths. If you branch inside the loop, lots of branches. If you branch outside the loop (into different specialized loops), few branches. Big fucking deal.
bool w;
int x[1000];
int y[1000];
for(int i=0;i<1000;i++){
x[i] += y[i];
}
if(w){
for(int i=0;i<1000;i++){
y[i] = 0;
}
}
Slower but prettier with the if pushed down.
mahboi 3 hours ago [-]
These things are so divorced from the reality of programming, even when they involve actual code instead of fancy lingo. Like in Scala, not a pure functional language, tutorials used to find the most convoluted higher-order functional way to do simple things.
bioneuralnet 4 hours ago [-]
Yet another encroachment on traditionally human activity.
moritzwarhier 3 hours ago [-]
I am the
Option<Walrus>
msdz 2 hours ago [-]
I know we’re not supposed to comment just for that, but this might be my single favorite joke comment I’ve ever read here. Good job.
jibalt 2 hours ago [-]
Except that TFA is a bog standard example of traditional human activity and the GP's comment is nonsensical trolling.
jampekka 1 hours ago [-]
I'm continually impressed by the ability of humans to spam low-effort whining about suspected LLM writing in almost every HN thread.
socializer 1 hours ago [-]
It's an LLM-generated article.
jampekka 1 hours ago [-]
How do you know? Doesn't read particularly LLM written to me, and even if it is, it's quite well written.
The author has been blogging about this kind of stuff for over 20 years. I'd be surprised if they suddenly let bots autonomously spam their blog.
raphman 55 minutes ago [-]
Yeah, sounds human-written to me, too. Out of habit I checked with Pangram - which identifies some parts as AI-written. (I think that might be false positives but am not 100% sure.)
rtpg 17 minutes ago [-]
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")
gorgoiler 2 hours ago [-]
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.)
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.
alterom 3 hours ago [-]
I take it you never rewrote a Matlab for loop as a vector/matrix op for insane speedups then :)
dieselgate 2 hours ago [-]
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.
They're one of those good practices that look like bad practice to everyone who just got a CS degree. Seems ex-students are unsettled by asymmetry or want to minimize the number of return statements.
econ 15 minutes ago [-]
Why am I even in this function if it shouldn't happen?
ramesh31 1 hours ago [-]
Particularly for high performance code when branch prediction is taken to account
woadwarrior01 2 hours ago [-]
Swift explicitly has a guard statement for this. Rust's let .. else { ... } is also very similar.
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.
cogman10 3 hours ago [-]
At least in JVM land, it's pretty easy to thwart that optimization. Particularly if the condition is on a mutable yet unchanged in the loop value.
For example:
var map = new HashMap<String, String>();
map.put("foo", "bar");
for (var i : items) {
if ("bar".equals(map.get("foo")) {
doStuff(i);
}
}
Even though `map` isn't mutated, it's hard enough for the JVM to detect and the underlying `get` functions are complex enough that it'll run the `get("foo")` every time, which can be quite expensive.
Maxatar 2 hours ago [-]
Can't speak for C# but in C/C++ the optimization can rarely be applied safely due to aliasing. If any part of the data you're working with involves a char* then C/C++ optimizers refrain from doing these kinds of optimizations because of how difficult it is to guarantee the absence of mutability.
4b11b4 12 minutes ago [-]
this is just a guard on the function definition?
throwawayffffas 2 hours ago [-]
Just the branch predictor gains are probably worth it.
aappleby 3 hours ago [-]
I have always phrased this as "Never do one of something".
narnarpapadaddy 26 minutes ago [-]
“Batch is the primitive”
OutOfHere 2 hours ago [-]
I like it, but to do fizzbuzz in this way, you'd have to separate what's inside the loop into a reused function.
pdpi 2 hours ago [-]
I think it's sort of obvious that the limit to this general rule is when data dependencies between fors and ifs forbid you from pushing things further up/down.
taolson 2 hours ago [-]
Or just use lazy list operations with a single if test at the end:
"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).
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.
The author has been blogging about this kind of stuff for over 20 years. I'd be surprised if they suddenly let bots autonomously spam their blog.
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.
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")
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?
Speed was almost never the reason.
They're one of those good practices that look like bad practice to everyone who just got a CS degree. Seems ex-students are unsettled by asymmetry or want to minimize the number of return statements.
https://docs.swift.org/latest/documentation/the-swift-progra...
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.
For example:
Even though `map` isn't mutated, it's hard enough for the JVM to detect and the underlying `get` functions are complex enough that it'll run the `get("foo")` every time, which can be quite expensive.https://github.com/taolson/Admiran/blob/main/examples/fizzBu...
/s
"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).