Hello Merlin,
For low-level arithmetic code like this one, with tests and loops
containing very few hardware instructions, I think that helping compiler
optimizations is a good idea.
Do you have any performance data to back that up?
Yep.
A generic data is the woes about speculative execution related CVE (aka
Spectre) fixes and their impact on performance, which is in percents,
possibly tens of them, when the thing is more or less desactivated to
mitigate the security issue:
https://www.nextplatform.com/2018/03/16/how-spectre-and-meltdown-mitigation-hits-xeon-performance/
Some data about the __builtin_expect compiler hints:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0479r0.html
Basically, they are talking about percents, up to tens in some cases,
which is consistent with the previous example.
As I said, helping the compiler is a good idea, and pg has been doing that
with the likely/unlikely macros for some time, there are over an hundred
of them, including in headers which get expanded ("logging.h", "float.h",
"simplehash.h", …), which is a good thing.
I do not see any good reason to stop doing that, especially in low-level
arithmetic functions.
Now, I do not have specific data about the performance impact on a gcd
implementation. Mileage may vary depending on hardware, compiler, options
and other overheads.
--
Fabien.
