51–56 of 56 posts
I optimized tight loop of network packets forwarding code with "__builtin_expect" and "inline" to get rid of at most all the branch delays and able to get > 10X increase in performance.
Wonder if same method can be used with "go"....
Can 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?
This is regarding a JWT[0] which is often used for authentication. Server-side code which takes a different amount of time depending on what bits are set in the JWT (or any similar authentication token) can be probed by repeating the operation with different values. Think of lockpicking—if you can move a pin and hear a click or feel more or less resistance, you know you've poked something critical in the core. [0] ht…
Does go support "__builtin_expect" similar to gcc? I optimized tight loop of network packets forwarding code with "__builtin_expect" and "inline" to get rid of at most all the branch delays and able to get > 10X increase in performance. Wonder if same method can be used with "go"....
I'd say it probably doesn't exist. Even if it _did_ exist, the Go compiler authors would reserve it for internal use only, like they do with most other Go compiler directives.
Earlier quoted context omitted.
This must be some strange new definition of "branchless" with which I'm not previously familiar; the generated code is full of branches, conditional or otherwise. I don't think invoking some other tool to put branches into your code qualifies you as branchless. Have you compared your parser to simdjson-go? I haven't looked specifically at the go rewrite, but I hear it's decent. I was very excited to do branch free co…
I apparently had a fundamental misunderstanding of the meaning of branchless. That's embarrassing. As for simdjson-go, I did benchmark it. rjson outperformed simdjson-go in most benchmarks, but simdjson-go was about 3% faster reading citm_catalog.json. https://github.com/WillAbides/rjson#simdjson Edit: I see on your bio that you are one of the simdjson authors. I hope you will indulge a question about it. I am genera…
The use of parallelism in simdjson is the use of SIMD instructions, not multiple cores. So the answer is "no" to the second question.
Earlier quoted context omitted.
I apparently had a fundamental misunderstanding of the meaning of branchless. That's embarrassing. As for simdjson-go, I did benchmark it. rjson outperformed simdjson-go in most benchmarks, but simdjson-go was about 3% faster reading citm_catalog.json. https://github.com/WillAbides/rjson#simdjson Edit: I see on your bio that you are one of the simdjson authors. I hope you will indulge a question about it. I am genera…
I'm not sure I believe your benchmarks, honestly. They are way slower than the C++ version. But I don't really have a horse in the race as simdjson-go is its own thing. Still, I'm mildly surprised that a byte-by-byte parser is the same speed as a SIMD approach, and usually when someone tells me this, the answer is usually that they buggered up the benchmarking. I would suggest comparing your numbers to the simdjson p…
https://old.reddit.com/r/golang/comments/mlhvx0/i_wrote_yet_...
Earlier quoted context omitted.
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.
depends how deep the pipeline is - with a long pipeline, a pipeline flush as a result of an incorrect predict can stall for tens of cycles.