41–50 of 109 posts
The compiler should detect that the two expressions are strictly equivalent and generate whatever code it believes is the fastest.
Any idea why it is this way?
Earlier quoted context omitted.
I find it interesting that there are developers out there that know to look at these nuances when respond to Stack Overflow questions. I'm been developing professionally for 10 years and probably went over branch prediction in my computer architecture class in college (I'm guessing I did, if I didn't then I never encountered it at all!). The person who answered the multiple question dove into byte code...but also ans…
That person works in financial services, which I'm guessing is basically some form of automated trading. It is an industry where every cycle counts (so much so, that often times light speed latency between two edges is something you need to consider when placing servers). He probably has actual experience with branch prediction. He probably dabbled or had experience with angular in other jobs (he worked at google app…
Has anyone tried this with Go?
I don't see how generating different code for the same mathematical expression can be a good thing. The compiler should detect that the two expressions are strictly equivalent and generate whatever code it believes is the fastest. Any idea why it is this way?
Also what good will it bring? What if the canonical expression triggers the slow path? Now you have no means to change it into the fast version.
Further, in the case of floating point operations, operation order matters for rounding. And with integer operations, the actual form used can be important for preventing overflow (of intermediate results).
Earlier quoted context omitted.
Did you read TFA? The author did that (though using GCC), and the reason the optimizer does what you see is undefined behavior due to signed integer overflow.
> does what you see is undefined behavior Just to be clear, undefined behavior means the standard allows implementations to do what they they feel is the right thing to do under that scenario, and the outcome will still comply with the standard.
Earlier quoted context omitted.
That person works in financial services, which I'm guessing is basically some form of automated trading. It is an industry where every cycle counts (so much so, that often times light speed latency between two edges is something you need to consider when placing servers). He probably has actual experience with branch prediction. He probably dabbled or had experience with angular in other jobs (he worked at google app…
The author of that answer wrote y-cruncher, which has been used to set world records in the number of digits of pi calculated. So I'm not surprised at all to see that they how know branch prediction works.
Can’t tell if clever joke, or typo
Earlier quoted context omitted.
The author of that answer wrote y-cruncher, which has been used to set world records in the number of digits of pi calculated. So I'm not surprised at all to see that they how know branch prediction works.
> they how know branch prediction works. Can’t tell if clever joke, or typo
I don't see how generating different code for the same mathematical expression can be a good thing. The compiler should detect that the two expressions are strictly equivalent and generate whatever code it believes is the fastest. Any idea why it is this way?
fn main() {
let a: i8 = 125;
let b: i8 = 3;
let c: i8 = (a + b) / 2;
let d: i8 = b + ((a - b) / 2);
println!("{} {}", c, d);
}
Here's another example using floating point numbers:
fn main() {
let mut total1: f32 = 0.0;
let mut total2: f32 = 0.0;
let mut counter1: f32 = 0.0;
let mut counter2: f32 = 100.0;
for _ in 0 .. 10001 {
total1 += counter1;
total2 += counter2;
counter1 += 0.01;
counter2 -= 0.01;
}
println!("{} {}", total1, total2);
}
So it's an issue of the optimizer; as is often the case, it unrolls too aggressively and shoots itself in the foot, all the while missing out on various other opportunities. In my experience, loop unrolling should basically never be done except in extremely degenerate cases; I remember not long ago someone I know who also optimises Asm remarking "it should've died along with the RISC fad". The original goal was to re…
Earlier quoted context omitted.
It is a good answer, but my favorite by far is an answer about branch prediction to explain why processing a sorted array is faster than unsorted: https://stackoverflow.com/q/11227809/938695
I find it interesting that there are developers out there that know to look at these nuances when respond to Stack Overflow questions. I'm been developing professionally for 10 years and probably went over branch prediction in my computer architecture class in college (I'm guessing I did, if I didn't then I never encountered it at all!). The person who answered the multiple question dove into byte code...but also ans…