Branchless Coding in Go
mattnakama.com
Branchless Coding in Go
1–10 of 56 posts
Re: Branchless Coding in Go
#2> we have to use if to convert bools into bits.
What if you can use the unsafe package?
Re: Branchless Coding in Go
#3I thought TEST did a subtract, setting the appropriate flags and discarded the result?
Re: Branchless Coding in Go
#4Instead of a "minimum wait", could you implement a random wait? Some random number of ns/ms between calls. Something that's enough to make any timing attack measurements unusable?
Re: Branchless Coding in Go
#5Instead of a "minimum wait", could you implement a random wait? Some random number of ns/ms between calls. Something that's enough to make any timing attack measurements unusable?
Random waits only increase the number of measurements an attacker needs to make, they do not eliminate the side-channel leakage. Intuitively the attacker can take many measurements and average them out to eliminate the randomness introduced by the waits, then extract the bits of information from the side channel.
Re: Branchless Coding in Go
#6Usual disclaimer: The branch predictor is one of the things that will make your program slower, so keep it in mind, but it's the memory stupid(!) so if the powers that be want a faster program in a few days focus on memory layout and cache usage first.
Re: Branchless Coding in Go
#7Instead of a "minimum wait", could you implement a random wait? Some random number of ns/ms between calls. Something that's enough to make any timing attack measurements unusable?
I never got round to trying it but I was wondering whether you could generate a Cauchy-distributed wait as a way of breaking badly written benchmarks/timing gadgets (i.e. the mean is indeterminate)
Re: Branchless Coding in Go
#8I wrote a mostly branchless json parser in go using ragel to generate most of the code.
https://github.com/WillAbides/rjson
The generated code isn't much to look at, but it is certainly fast.
https://github.com/WillAbides/rjson/blob/main/object_handler...
Re: Branchless Coding in Go
#9Usual disclaimer: The branch predictor is one of the things that will make your program slower, so keep it in mind, but it's the memory stupid(!) so if the powers that be want a faster program in a few days focus on memory layout and cache usage first.
yes, thank you. improving cache efficiency is by far the biggest single thing you can do to increase performance. if the code and data for both outcomes of an 'if' are in L1 cache, that 'if' is never going to be slow.
Re: Branchless Coding in Go
#10Can anyone explain the “why does this matter” paragraph where the author seems to suggest that using branches in our program is a security risk?
I know that branch speculation can be used as an attack vector if our program is the aggressor - but does simply using branches in some way make us more likely to be the victim?