4 ms·
Bog-standard, humdrum enterprise programming != kernel programming When every branch removed on a mainline path in the kernel saves years of compute time globa
by RandomOpinion 10y ago
Bog-standard, humdrum enterprise programming != kernel programming
When every branch removed on a mainline path in the kernel saves years of compute time globally and every byte removed in the kernel saves terabytes of memory globally, being clever is absolutely the right thing to do. Removing that one branch takes away an expensive pipeline stall[0]. The version akkartik has above adds a extra branch (and expensive pipeline stall) to _each iteration_ of the loop; Linus would probably not be pleased, to put it mildly, if anyone submitted a patch like that.
And the method Linus shows isn't even particularly clever; it's been a common example for handling linked list insertion in C for decades. All these "Linus is being too clever" postings show is that most programmers aren't cut out to be kernel or embedded programmers.
[0] See https://en.wikipedia.org/wiki/Bubble_(computing) https://en.wikipedia.org/wiki/Bubble_(computing) and https://software.intel.com/en-us/articles/avoiding-the-cost-of-branch-misprediction https://software.intel.com/en-us/articles/avoiding-the-cost-.... And, yes, instruction reordering[1] might be able to fill the slots but you don't get to be where Linus is by relying on that. Plus, Linux runs on processors that don't have OOO, like Intel's Atom and microcontrollers.
[1] https://en.wikipedia.org/wiki/Out-of-order_execution https://en.wikipedia.org/wiki/Out-of-order_execution
- ant6n 10y agoBut now you're making argument about performance, not "good taste". Often, performant code is not very tasty.
- RandomOpinion 10y agoAre you seriously arguing that Linus would think cleanly performant code is not in good taste? You're welcome to ask him that directly and see what he says. EDIT: Okay, I'm being excessively snarky there; my apologies. I will say instead that is that "good taste" depends on the context. What's "good taste" for kernel development isn't necessarily the same as "good taste" for enterprise development or the same as "good taste" for app development.
- ant6n 10y agoHaha, getting bullied does not sound very delicious to me.
- K0SM0S 10y agoAs a rookie programmer (but 10 years in IT, loving maths), this was my thought exactly. Basically a matter of field/domain definition, insofar as humans still have to interact with the code. In short: most enterprise code should be elegant and simple, even if verbose (many conditionals, as little nesting as possible, etc) so that a 12 years old can understand it, because in real life you'll get much turnover and lack of means/skill/motivation. Hence, costly maintenance, etc. Writing an open-source kernel consistently for 20+ years is an entirely different problem, and the fact that you use code in both these examples is a distant commonality of the problem sets; it is my experience thus contention that the human factor and real world conditions are paramount to ascribing qualitative assertions such as 'good' or 'tasty'. That is, until machines program themselves or others without human oversight. ;)
- colanderman 10y agoTaste is malleable and relative. One can even entertain different notions of taste. I personally have at least two – "understandable" and "performant" – and they aren't always (but sometimes are) exclusive of each other. I suspect Linus's "taste", given Linux's problem domain, tuned to some combination of performant + testable + reviewable + portable. In the example given, Linus's rewrite meets these requirements; hence his assertion that it is in better taste.
- ant6n 10y agoI feel at this point, the notion of 'good taste' has become even more ill-defined, something very personal. Then the notion is not very useful as a coding guideline.
- aero142 10y agoThere isn't a domain where taste isn't personal. It's always a blend of art and science. Just because you can't define it exactly though, doesn't mean you can't get closer to it by working at it.
- Roboprog 10y agoPretty much nailed it in the first line :-) I prefer the shorter version for being shorter, and for generalizing the update point at the end (and giving it a name), which stresses that there will be an update (delete). Alas, most of my coworkers would prefer the "explicit" version with all of the extra lines. Aside: I sure miss identifiers with underscores in them, rather than MashedTogetherEnterpriseSelfCrockumentingMego :-(
- akkartik 10y agoYes, of course, I'm certainly not cut out to be a kernel programmer. Were the audience in that TED chat kernel programmers? I thought we were discussing "taste", not what it takes to get a patch into the kernel. Linus does work on other projects, you know.