[deleted]
The 8-Byte Two-Step
11–20 of 34 posts
Re: The 8-Byte Two-Step
#12Earlier quoted context omitted.
Doubly agreed -- similar patterns appear elsewhere to avoid off-by-one errors and bitmasking is fairly intuitive to anyone regularly working at that level. I was surprised at the author not recognizing this idiom, but you have to learn it sometime! I was further stunned by the seeming naivety of the author's align_2() implementation, but then it does get the job done, eventually. My naive approach would've been rough…
Hi, author here. My align_2 implementation is indeed very naive. Part of that was to show just how much overhead a naive implementation could add, in this case 3 orders of magnitude. I'm also new to systems programming. This article should serve as a reminder to experienced hackers that idioms are often only obvious _after_ they've been explained. My last 4 years were spent working on a distributed database; I could…
The key being "once you understand it." I look forward to sending this around to make sure folks "get it" -- that which I grasp intuitively is magic for them[1], and kernel hacking is rarely the deep topic people imagine it to be. I doubt I have the right perspective to explain this as clearly, and if I could, I lack the time to do so as deeply.
[1]Their words, heard within the past month.
Re: The 8-Byte Two-Step
#13[deleted]
Author here, I won't get to it today but I would like to try the method you describe. I realize that benchmarking is a very tricky thing having followed Brendan Gregg's work the last couple of years. This is why I also ran my baseline benchmark which simply performed a ret. I learned years ago from tuning cars that absolute numbers are less interesting than relative. That said, I am a total newb at low-level stuff like this and I would not be surprised if I messed something up. I'll be curious to use your method and see how it compares.
Re: The 8-Byte Two-Step
#14TLDR: round a number N up to the nearest multiple of M
Re: The 8-Byte Two-Step
#15TLDR: round a number N up to the nearest multiple of M
... where M is a power of 2.
Re: The 8-Byte Two-Step
#16Another great article from that site:
Re: The 8-Byte Two-Step
#17Maybe you shouldn't care about cycles, but using a loop for something that can be done without branches is a definite cognitive overhead. If we want to avoid bit twiddling, how about this: (mqhp->mq_maxsz + MQ_ALIGNSIZE - 1) / MQ_ALIGNSIZE * MQ_ALIGNSIZE; I would expect a compiler to emit the same instructions as the original, but at worst you would have an add and two shifts rather than jumps or complex float operat…
Provided everything is unsigned, this should result in something somewhat similar. I think this form also makes it clearer what's going on.
Assume MQ_ALIGNSIZE is a power of two. Then if N is the power, MQ_ALIGNSIZE is 1>NConsider x>>NAnother way of putting that would be x&~((1I suppose it's possible a compiler could transform this, or the divide-and-multiply version, into the add-then-and version, given enough things that are compile-time constants. But personally if I knew the alignment would be a power of two - which it pretty much always is - I'd just write the code I want. Life is usually simpler that way.
Re: The 8-Byte Two-Step
#18This is really neat, thanks for the thorough explanation.
I have banned myself from using printfs to figure out things like this. Instead I would use a debugger and breakpoints to view the live variables in their different data formats.
In GDB, that's p/t for binary and p/d for decimal.
Re: The 8-Byte Two-Step
#19The floating point version is dangerous and broken on platforms that have 64-bit ints. (Not sure what happens with ceil and negative numbers, it probably works, but I'd have to try it). And while not an issue here, since this looks like it's user-space code, it's bad to use floats in a systems programming environment (floats are often in registers that can't be modified or maybe even referenced in kernel contexts without some save/restore shenanigans).
The loop version works poorly for large queue sizes, and if I saw this in production code I'd replace it immediately.
I'd be okay with a division and re-multiplication (likely going to be optimized by the compiler, through it's foolish to depend on this).
I don't see any problem with the mask/not/and solution. This has been a programming idiom for decades, and should be no more mysterious than (say) a doubly-linked list.
Re: The 8-Byte Two-Step
#20The floating point version is dangerous and broken on platforms that have 64-bit ints. (Not sure what happens with ceil and negative numbers, it probably works, but I'd have to try it). And while not an issue here, since this looks like it's user-space code, it's bad to use floats in a systems programming environment (floats are often in registers that can't be modified or maybe even referenced in kernel contexts wit…
I agree, the mask/not/and is standard within systems contexts. It need not be cognitive overhead, not to be elitist but if you don't have a copy of hacker's delight or the ability to understand constructs like this, you have no business writing systems-level code.