Which is the fastest way to implement an operation that returns the absolute value of a number?
x=root(x²)
or
if !isPositive(x):
x=x*(-1)
Actually this question can be translated as, how fast is an if (and why please).
My college programing professors always told me to avoid ifs for they are extremely slow, but I always forgot to ask how slow and why. Does anybody here know?
Conditionals are slower than plain arithmetic operations, but much, much faster than something as silly as calculating the square root.
Rules of thumb from my assembly days:
if is doing and compile it to just a bitwise operation that clears the sign bit of the float or double (modern FPUs like x86 with SSE), or a dedicated instruction like legacy x87 fabs that does the same thing on the x87 FPU that doesn't support arbitrary bitwise stuff on floats. –
Thay fabs(x) in C which does compile as efficiently as possible, without worrying the compiler with signed-zero and NaN special-casing. e.g. if (x<0) x = -x; or x = (x<0) ? -x : x; both need to leave negative-zero alone because it compares == 0.0). But anyway, (-1)*x can optimize to just xorps to flip the sign bit. –
Thay There is a great trick to calculate the absolute value of a 2s-complement integer without using an if statement. The theory goes, if the value is negative you want to toggle the bits and add one, otherwise you want to pass the bits through as is. A XOR 1 happens to toggle A and A XOR 0 happens to leave A intact. So you want do something like this:
uint32_t temp = value >> 31; // make a mask of the sign bit
value ^= temp; // toggle the bits if value is negative
value += temp & 1; // add one if value was negative
In principle, you can do it in as few as three assembly instructions (without a branch). And you'd like to think that the abs() function that you get with math.h does it optimally.
No branches == better performance. Contrary to @paxdiablo's response above, this really matters in deep pipelines where the more branches you have in your code, the more likely you are to have your branch predictor get it wrong and have to roll-back, etc. If you avoid branching where possible, things will keep moving along at full throttle in your core :).
value += temp & 1, I suggest the simpler value -= temp, and there is no reason to use an unsigned type for temp. –
Ault (x < 0 ? -x : x) using a conditional move instruction; in that case this trick is no faster than the standard Abs. –
Ault ((value >> 31) | 1) * value wouldn't suffice? multiplication isn't expensive. –
Lally Conditionals are slower than plain arithmetic operations, but much, much faster than something as silly as calculating the square root.
Rules of thumb from my assembly days:
if is doing and compile it to just a bitwise operation that clears the sign bit of the float or double (modern FPUs like x86 with SSE), or a dedicated instruction like legacy x87 fabs that does the same thing on the x87 FPU that doesn't support arbitrary bitwise stuff on floats. –
Thay fabs(x) in C which does compile as efficiently as possible, without worrying the compiler with signed-zero and NaN special-casing. e.g. if (x<0) x = -x; or x = (x<0) ? -x : x; both need to leave negative-zero alone because it compares == 0.0). But anyway, (-1)*x can optimize to just xorps to flip the sign bit. –
Thay Calculating the square root is probably one of the worst things you could do because it is really slow. Usually there is a library function for doing this; something like Math.Abs(). Multiplying with -1 is also unnecessary; just return -x. So a good solution would be the following.
(x >= 0) ? x : -x
The compiler will probably optimize this to a single instructions. Conditions may be quite expensive on modern processors because of the long execution pipelines -the calculations must be thrown away if a branch was misspredicted and the processor started executing the instructions from the wrong code path. But because of the mentioned compiler optimization you need not care in this case.
mov eax, edi; neg eax; cmovl eax, edi; ret and it doesn't require any comments to explain all the bit twiddling. –
Aldis For completeness, here's a way to do it for IEEE floats on x86 systems in C++:
*(reinterpret_cast<uint32_t*>(&foo)) &= 0xffffffff >> 1;
foo, cast to a 32-bit unsigned integer pointer, dereference that and apply a bitmask that preserves all bits except for the (MSB) sign bit –
Piper -1 you won't get 1 but a very large value instead. Lookup 2's complement to understand why. –
Schubert Which is the fastest way to get the absolute value of a number
I think the "right" answer isn't here actually. The fastest way to get the absolute number is probably to use the Intel Intrinsic. See https://software.intel.com/sites/landingpage/IntrinsicsGuide/ and look for 'vpabs' (or another intrinsic that does the job for your CPU). I'm pretty sure it'll beat all the other solutions here.
If you don't like intrinsics (or cannot use them or ...), you might want to check if the Compiler is smart enough to figure out if a call to 'native absolute value' (std::abs in C++ or Math.Abs(x) in C#) will change automagically into the intrinsic - basically that involves looking at the disassembled (compiled) code. If you're in a JIT, be sure that JIT optimizations aren't disabled.
If that also doesn't give you the optimized instructions, you can use the method described here: https://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs .
pabsd is great if you have an array of values, or otherwise can keep your data in vector register only, but neg/cmov is more efficient than copying from integer registers to XMM and back. You should almost always use std::abs and let the compiler auto-vectorize if it wants to, otherwise inline it efficiently. –
Thay The if variant will almost certainly be blindingly fast compared to the square root, since it normally translates to a conditional jump instruction at the machine code level (following the evaluation of the expression, which may be complex, but not in this case since it's a simple check for less than 0).
Taking the square root of a number is likely to be much slower (Newton's method, for example, would use many many if statements at the machine code level).
The likely source of confusion is the fact that if invariably lead to changing the instruction pointer in a non-sequential manner. This can slow down processors that pre-fetch instructions into a pipeline since they have to re-populate the pipeline when the address changes unexpectedly.
However, the cost of that would be minuscule compared to performing a square root operation as opposed to a simple check-and-negate.
The modulo operation is used to find a remainder, you mean absolute value. I modified the question because it should be if !pos(x) then x = x*-1. (not was missing)
I wouldn't worry about the efficiency of an if statement. Instead focus on the readability of your code. If you identify that there is an efficiency problem, then focus on profiling your code to find real bottlenecks.
If you want to keep an eye out for efficiency while you code, you should only worry about the big-O complexity of your algorithms.
If statements are very efficient, it evaluates whatever expression and then simply changes the program counter based on that condition. The program counter stores the address of the next instruction to be executed.
Mulitplication by -1 and checking if a value is greater than 0 both can be reduced to a single assembly instruction.
Finding the root of a number and squaring that number first is definitely more operations than the if with a negation.
The time taken to do a square root is much greater than the time taken to do an conditional. If you have been taught to avoid conditionals because they are slow, then you have been misinformed. They are a good deal slower than trivial operations like adding or subtracting integers or bit shifting - which is why unrolling loops can be of benefit only if you are doing such trivial operations. But in the grand scheme of things conditionals are good and fast, not bad and slow. To do something as complicated as call a function or calculate a square root to avoid a conditional statement is crazy.
Also, instead of (x = x * -1) why not do (x = 0 - x)? Maybe the compiler will optimize them the same, but isn't the second one simpler anyway?
Are you using 8086 assembly? ;-)
; abs value of AX
cwd ; replicate the high bit into DX
xor ax, dx ; take 1's complement if negative; no change if positive
sub ax, dx ; AX is 2's complement if it was negative The standard
: absolute value method works on any register but is much
; slower:
or bx, bx ; see if number is negative
jge notneg ; if it is negative...
neg bx ; ...make it positive
notneg: ; jump to here if positive
(flagrantly stolen)
test same,same, not or same,same for efficiency (Test whether a register is zero with CMP reg,0 vs OR reg,reg?). And unless you're programming for an actual ancient CPU, use cmov instead of a conditional branch. –
Thay You can try to use a single AND operator as a mask.
Here is a pseudocode as an example
i8 num = 10001101 = -13
u8 mask = 01111111 = 127;
i8 res = num & mask = 00001101 = 13
.
I believe this is the fastest way to calculate the absolute value on a computer. Correct me if I'm wrong.
If you are simply comparing the absolute values of two numbers (e.g. you don't need the absolute value of either after the comparison) then just square both values to make both positive (remove the sign of each value), the larger square will be greater than the smaller square.
What is faster is very dependent on what compiler and what CPU you're targeting. On most CPUs and all compilers x = (x>=0)? x:-x; is fastest way to get absolute value, but in fact, often standard functions already offer this solution (e.g. fabs()). It is compiled into compare followed by conditional assignment instruction(CMOV), not into conditional jump. Some platforms lack of that instruction though. Although, Intel (but not Microsoft or GCC) compiler would automatically convert if() into conditional assignment, and even would try optimize cycles (if possible).
Branching code in general is slower than conditional assignment, if CPU uses statistical prediction. if() might be slower in average if operation gets repeated multiple times and result of condition is constantly changing. CPUs like Intel, would start to calculate both branches, and would drop the invalid one, In case of large if() bodies or large number of cycles that might be critical.
sqr() and sqrt() on modern Intel CPUs are single built-in instruction and aren't slow, but they are imprecise, and loading registers would take time as well.
Related question: Why is a CPU branch instruction slow?
Most likely, professor wanted student to do research on this matter, it's semi-provocative question\task that would do only good, if student would learn think independently and look for additional sources.
sqrt is a single instruction on x86 but it is slow-ish, and only available for float/double/long double, not integer. The throughput / latency numbers are similar to (but slower than) FP division: Floating point division vs floating point multiplication. –
Thay abs. It just takes a mov / neg/cmov to do it in 3 uops with 2 cycle latency. –
Thay I'm doing some retro graphics programming in C for 8088/8086 and calling abs() is time consuming so I've replaced it with:
/* assuming 'i' is int; this WILL NOT WORK on floating point */
if (i < 0) {
i = ~i + 1;
}
The reason this is faster is because it essentially trades a CALL in assembly for a JNE. Calling a method changes a couple of registers, pushes several more, pushes arguments onto the stack, and can flush the prefetch queue. Plus these actions need to be reversed at the end of the function and all of this is very expensive to the CPU.
abs to code that compiles at least as efficiently as that. (e.g. neg/cmov on modern x86). Doing the 2's complement bithack yourself isn't useful; you might as well just use i = -i, because x86 has a neg instruction that's faster than NOT / INC (in case you have a naive compiler that doesn't recognize the 2's complement identity and optimize it back to neg or sub). –
Thay For completeness, if you are dealing with floating point numbers, you can always do something like n * sign(n), where sign is a function that returns +1 if the number is positive, -1 if negative. In C this would be something like copysign(1.0, n) or (n > 0) - (n < 0).
Most machines use IEEE 754 as their floating point format these days, so you can clear the sign bit directly:
float fabs(float x) {
char *c = &x;
c[0] &= 7;
return *(float *)c;
}
Given that the abs function likely does this exact thing, your best bet is to use it when available. If you are lucky the function will be a couple of instructions, and will be inlined.
I wonder, if something is wrong with this solution. There is
INT_MINMaybe too much instructions?
My solution
xabs = (x < 0)*(-x) + (x >=0)*x
Old solution
xtest = (x < 0)*x; // xtest = x if is negative, otherwise zero
xabs = (x - xtest) - xtest; // Order of instructions taken into account
Undefined behaviour of negating INT_MIN
A check against undefined behaviour (negation of INT_MIN) can be added,
if your value is not limited in the algorithm somewhere before.
But that makes it a little more complicated.
Maybe, someone finds a simpler logic.
xabs = (x < -INT_MAX)*INT_MAX // x < -INT_MAX < 0 --> xabs = INT_MAX
+ ((x >= -INT_MAX)&&(x < 0))*(-x) // -INT_MAX =< x < 0 --> xabs = -x
+ (x >= 0)*x // 0 <= x --> xabs = +x
Unfortunately, I never did a speed comparison. So I don't know if it is really faster than
if ( x < 0 )
{
if ( x >= -INT_MAX )
{
x = -x;
}
else
{
x = INT_MAX;
}
}
For a list of negative numbers:
if you have zero stored in memory, simply use 0 - x, where x is the negative number.
Or if you do not have zero stored in memory:
x-x-x, where x is the negative number.
Or, with brackets for clarity:
(x) - (x) - (x) => (-n) - (-n) - (-n), where x = -n
i.e. subtract the negative number from itself to get zero, then subtract it from zero.
© 2022 - 2024 — McMap. All rights reserved.