Print(“lol”) doubled the speed of my Go function
1–10 of 130 posts
Re: Print(“lol”) doubled the speed of my Go function
#2Why is there a "continue" at all in the first code sample?
Edit to add: does removing it make any difference?
Re: Print(“lol”) doubled the speed of my Go function
#3Why is there a "continue" at all in the first code sample? Edit to add: does removing it make any difference?
Good question. As you can see in the comment in the github repo, it has no effect. https://github.com/ludi317/max/blob/master/blog/max_test.go#...
It is there only to match the continue in the second code sample, where it is needed.
Re: Print(“lol”) doubled the speed of my Go function
#4Processor "optimizations" can produce surprising effects. The problem is these optimizations are not programmatically accessible to C (or most modern programming languages) given their simple memory model. Deterministic performance is not easy to obtain. My view is to not bother with such tricks unless absolutely necessary (and be prepared that your changes may actually pessimize performance on a future processor or a compatible processor by a different vendor).
If you are interested in this sort of thing, check out comp.arch!
Re: Print(“lol”) doubled the speed of my Go function
#5Why is there a "continue" at all in the first code sample? Edit to add: does removing it make any difference?
Good question. As you can see in the comment in the github repo, it has no effect. https://github.com/ludi317/max/blob/master/blog/max_test.go#... It is there only to match the continue in the second code sample, where it is needed.
Thanks! In that case, I have to say I'm surprised. I assumed the code generated for the loop would have an instructions that branches, so adding another branching instruction could only hurt (edit: not necessarily a lot), but apparently my intuition is wrong.
I'm curious if the performance difference noted in the article happens on Intel/AMD as well...
Re: Print(“lol”) doubled the speed of my Go function
#6I read it and I still don't get it, can someone (re-)explain what the presence of the print() is doing that is helpful for branch prediction (or any other aspect of the CPU)?
Update: It seems to be the conditional move, see https://news.ycombinator.com/item?id=37245325
Re: Print(“lol”) doubled the speed of my Go function
#7In the Linux kernel, there are unlikely() and likely() macros which indicate to the compiler whether or not a condition is likely using __builtin_expect (which then influences the output assembly into producing code that should make the branch predictor do the right thing more of the time).
Unfortunately, the issue here is that the performance depends on the input and so such hints wouldn't help (unless you knew a-priori you were dealing with mostly-sorted data). Presumably the min-max (and lol) versions perform worse for descending arrays?
Re: Print(“lol”) doubled the speed of my Go function
#8I'm a noob. Looking at the disasm: https://godbolt.org/z/766aPTPc3
It turns a CMOVQLT to a JLT. Is the blog saying CMOVQLT don't have branch predication?
I don't get it.
Re: Print(“lol”) doubled the speed of my Go function
#9I read it and I still don't get it, can someone (re-)explain what the presence of the print() is doing that is helpful for branch prediction (or any other aspect of the CPU)? Update: It seems to be the conditional move, see https://news.ycombinator.com/item?id=37245325
I'm in school, so this may be oversimplified, but if the processor/assembly code is predicting the next result, it gets the result faster. The processor only does this prediction with conditional branches. The extra if for printing or finding the min invoke the prediction with the accuracies stated.
Re: Print(“lol”) doubled the speed of my Go function
#10I read it and I still don't get it, can someone (re-)explain what the presence of the print() is doing that is helpful for branch prediction (or any other aspect of the CPU)? Update: It seems to be the conditional move, see https://news.ycombinator.com/item?id=37245325
I'm in school, so this may be oversimplified, but if the processor/assembly code is predicting the next result, it gets the result faster. The processor only does this prediction with conditional branches. The extra if for printing or finding the min invoke the prediction with the accuracies stated.
> The processor only does this prediction with conditional branches
This sounds... wrong? Unless ARM64 is designed in an absurd way?
I'd love to see the full disassembly; something seems funny here. If it was x86 I would say it's a conditional move causing this, but I don't know what's going on on ARM.