Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: Performance degradation from 1.7.5 to 1.8 #19819
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
Thanks for the report.
go1.8 at this point is done. It would be important to know if the performance regression persist in the current master branch (soon-to-be go1.9).
Can you re-run your benchmarks on tip? Comparing go1.7.5 vs go1.8 vs tip would help understand if there's something that needs to be fixed for go1.9.
The code around the Sincos calls is definitely shifted around, but it isn't doing anything weird. For instance, it is now doing (lat1+lat2)/2 after the Remainder call instead of before it.
There are a few extra loads. The 1.7 code did (lat1+lat2)/2 and (lat1-lat2)/2 together, so the loads of lat1 and lat2 were shared. The 1.8 code computes those two things on different sides of a function call, so it must reload lat1 and lat2. Not optimal, but I'm not sure why that would cause the performance difference you're seeing.
Sincos is implemented in assembly on amd64 which is why you didn't see anything different just calling Sincos in a loop. (The assembly hasn't changed since at least 1.7.)
The fact that Sincos in the profiles goes from 410 sec to 473 sec is strange, given that the Sincos code itself didn't change. 1.8 is doing the (lat1+lat2)/2 divisions later, maybe causing the code that uses the result in Sincos to stall?
One thing I definitely noticed, apart from the bug in this CL, is that we're doing x/2 using an actual division instead of doing x * .5. I'll open a separate bug for that.
p.s. just saw we have a math.satan. Awesome.