No post body was provided.
Why does this code execute more slowly after strength-reducing multiplications?
121–130 of 155 posts
Re: Why does this code execute more slowly after strength-reducing multiplications?
#122In the post, multiplications and 2 additions are not faster than 2 additions. The post compares (1) loop code that can be vectorized, as loop rounds are independent and do not depend on the result from the previous round, and (2) an "optimization" that makes calculations shorter, but also makes each loop round depend on the result of the previous round, so this cannot be vectorized.
No post body was provided.
Re: Why does this code execute more slowly after strength-reducing multiplications?
#123I doubt repeatedly adding floating point numbers is a good idea. With every addition the sum increases further away from the addend, and with their growing relative difference problems grow as well. Just because the algebra works it doesn't guarantee that the code does, too.
Your points are factually correct, but in practice not a big concern, if your floating point value is much more precise than necessary for the numbers used. E.g. if you use doubles for the range of 32bit integers even adding 1.0 2 billion times to 2 billion still ends up at 4 billion. Even adding 1.0 20 billion times to 20 billion ends up at 40 billion. Now adding 0.1 20 billion times to 2 billion ends up 1908 short…
You're talking about the best case, but we need to take the reasonable worst cases into account, where x + y nearly cancel etc.
Re: Why does this code execute more slowly after strength-reducing multiplications?
#124Earlier quoted context omitted.
If the user provides code where the result should be +0.0 and the compiler emits code that results in -0.0 (and the user has not explicitly enabled relaxed IEEE754 conformance), that's a bug in the compiler.
That is correct. But we were talking about how the == operator compares zeros. According to IEEE 754, -0 == +0 even though their bit patterns are not identical. And, by the way, inf != inf even if their bit patterns are identical.
> But we were talking about how the == operator compares zeros
Well, you were and I wasn't, and it wasn't clear whether you meant to contradict my point. I guess I could've made it more clear that I meant "using == to denote bitwise equality here only" and not "btw, == is bitwise for floats", but either way it should be clear now.
Re: Why does this code execute more slowly after strength-reducing multiplications?
#125Earlier quoted context omitted.
The slower algo will use more instructions as will have to run for more iterations. The faster algo will use wider ALUs that are more power hungry, so it appears a wash. But because less instructions are in flight, less power need to be spent to keep track of them or renaming registers, caches need to powered for a smaller amount of time and so on.
>The slower algo will use more instructions The whole point of this thread is realization of opposite. Slower algo executes only 2 instructions in a loop, but second one directly depends on the result of the first (induces pipeline stall) while the fast version brute forces a ton of instructions at full CPU IPC.
If you look carefully at the generated assembly shown in the article, the vectorized loop actually executes less instructions in total as while an iteration is longer it more than make it up by iterating less times.
Edit: btw, while the fast version has bo loop carried dependencies and it uses 4x SIMD, it us only twice as fast
I wonder if a manually unrolled (with 4 accumulators) and vectorized version of the strength reduced one could be faster still.
The compiler won't do it without fast math.
Re: Why does this code execute more slowly after strength-reducing multiplications?
#126Is this kind of parallelization possible on only compiled language? Or is it also possible for interpreted language like JavaScript?
Re: Why does this code execute more slowly after strength-reducing multiplications?
#127Is this kind of parallelization possible on only compiled language? Or is it also possible for interpreted language like JavaScript?
The same considerations apply, though not always. JavaScript can be JIT compiled, though the JIT might not make the same optimisations as a C compiler. It's running on the same CPU though.
Re: Why does this code execute more slowly after strength-reducing multiplications?
#128First: we need to finally stop the harmful myth that floating point multiplication is slower than addition. This has not been true for a long while.
Second: why are so many people insisting that the loop is auto-vectorised? Is there any evidence to that? Data dependencies alone explain the observed performance delta. Auto-vectorization would have resulted in a higher speedup.
Re: Why does this code execute more slowly after strength-reducing multiplications?
#129I'm running into an interesting result -- on my machine, the fast version runs at the same speed at LEN=1000000 (the default in the sample), but starts running 1.5 times faster at LEN=500000 and ends up twice as fast at LEN=100000 and lower. This is with gcc -O3. Why could this be?
Re: Why does this code execute more slowly after strength-reducing multiplications?
#130I'm running into an interesting result -- on my machine, the fast version runs at the same speed at LEN=1000000 (the default in the sample), but starts running 1.5 times faster at LEN=500000 and ends up twice as fast at LEN=100000 and lower. This is with gcc -O3. Why could this be?
cache size pushing you out to high latency memory