6 ms·
Which one is faster? (C code) Return: see if abs(num) > x. /logical comparison/ int greater_abs(int num, int x){ return (num > x) || (num+x < 0); } /squared
by huachimingo 4y ago
Which one is faster? (C code)
Return: see if abs(num) > x.
/logical comparison/
int greater_abs(int num, int x){
return (num > x) || (num+x < 0);
}
/squared approach/
int greater_abs2(int num, int x){
return num*num > x;
}
See it by yourself, with (and without) optimizations:
https://godbolt.org/ https://godbolt.org/
What would happen if x is a compile-time constant?
- WalterGR 4y agoNo idea. How frequently am I calling `abs`?
- jjice 4y agoIf you write math heavy code, probably a lot more than if you're writing web apps. Depends on what kind of software you write.
- WalterGR 4y agoGot it. Well if that were the case, I’d use a profiler to see if spending time on optimizing ‘abs’ would realistically be worth it.
- deleted 4y ago[deleted]
- throwaway744678 4y agoI don't know which one is faster, but I know that one is not correct (squared approach).
- saghm 4y agoWouldn't the second one also potentially be incorrect due to overflow?
- pjscott 4y agoYes. Suppose that both numbers are positive, that x>num, and that x+num is bigger than INT_MAX. In that case we hit signed integer overflow, which is undefined behavior. If signed integer overflow happens to wrap around, which it might, then the result could be negative and the function would return the wrong result. Or anything else could happen; undefined behavior is undefined. In practice, just writing "abs(num) > x" gives quite good machine code, and it does so without introducing hard-to-see bugs.
- deleted 4y ago[deleted]
- dhosek 4y agoYour squared approach is wrong: greater_abs2(3, 4) returns true but should return false.
- zasdffaa 4y agoDepends. In the first it will depend on the branch predictor which will depend on the relative expected magnitudes of num and x In the 2nd, which I assume should be { return num*num > x * x; } then it depends on the micro-arch, as it's one basic block so no branches and assuming a deep pipeline on x64, one multiplier (pipelined), probably this is faster for 'random-ish' num and x.
- deleted 4y ago[deleted]
- dahart 4y agoMath & logic are rarely the bottleneck over memory & allocation bottlenecks, right? Does Godbolt assume x86? Does the answer change depending on whether you’re using an AMD or NVIDIA GPU, or an Apple, ARM or Intel processor? Does it depend on which instruction pipelines are full or stalled from the surrounding code, e.g., logic vs math? Hard to say if one of these will always be better. There are also other alternatives, e.g. bitmasking, that might generate fewer instructions… maybe “abs(num) > x” will beat both of those examples?
- masklinn 4y ago> Does Godbolt assume x86? Godbolt uses whatever compilers, targets, and optimisations you ask it to. It is, in fact, a very useful tool for comparing different compilers, architectures, and optimization settings.
- dahart 4y agoAh, yes, thank you, it looks awesome! It doesn't have GPU options (which is fair, since this is standard C++). But I see now I could have figured out the answer to my question in just a few seconds. :)
- slavik81 4y agoCompiler Explorer does have GPU options, actually. It has well-established CUDA support and I have been meaning to help add HIP support.
- deleted 4y ago[deleted]
- astrange 4y agoMost questions like these have no answer because if any of the parameters is known (which it usually is) it’ll get folded away to nothing.