runtime: go 1.10beta2 Benchmarks slower on Mac (possibly related to time) #23419
Comments
|
Is this an appropriate use of github issues? Not at all a minimal reproducible test case, sorry :( But is very reproducible. My own investigation saw a lot of pprof time inside the time package. |
Yes. |
bradfitz
added
NeedsInvestigation
|
We should at least understand the difference before shipping Go 1.10, but no promises on fixing it this late in the cycle. Have you run the CPU profiler on the worst cases there (like |
ianlancetaylor
changed the title
|
We did change the Darwin time code in 1.10, for High Sierra (#22037). That may have made it slower, though I would expect that it would only matter for benchmarks that are dominated by timing calls. Please do attach some profiling data. Thanks. CC @aclements |
How do I do that? I don't see a way to attach files to github issues. Here is some top30 output And with go1.10 |
|
Sure looks like time, but that's pretty extreme. time.Now went from 13.31% cumulative to 99.75%. The new code that you're in (specifically the assembly for time.now lowercase) is: https://go-review.googlesource.com/c/go/+/67332/5/src/runtime/sys_darwin_amd64.s I wonder if it can get stuck for too many iterations in this part: @rsc, do you remember if that CL was that much slower for you? |
|
@cep21 Which version of Darwin are you using? Are you running it on a physical machine or some sort of VM? |
Running on my physical mac (MacBook Pro) |
|
@cep21 I'm trying to reproduce it. The instructions seem incomplete because I also need to download test dependencies ( If I just ignore it, I get results which are much better on tip: Go 1.9.2: Go tip c13e0e8 Full benchcmp: This is on a MacBook Pro 2016 (Core i7). |
|
The package |
|
Ok new reproduce steps |
|
@rasky is tip the same as beta2? If not, what do you see on beta2? |
|
Thanks. As in my edited comment above, it works much better on tip for me. My tip is just one day newer than beta2. Go 1.9.2 profile: Go tip profile: |
|
(no difference with Go 1.10beta2, just double checked) |
|
So, results seem to make sense. I run High Sierra. High Sierra broke Go's You're running Sierra (I assume so given your Darwin version), so Go 1.9.2 is fast for you just like Go 1.10 is fast on my High Sierra. The question is: why Go 1.10 is slow for you... it shouldn't be. I don't have Sierra handy right now, I'll need some help. Let's see if the version detection works: can you please try compiling Go from source, after modifying this line to an absolute jump ( |
Magic! Working much better. Changing to a JMP makes the benchmarks between tip and go 1.9 comparable, with tip slightly better. |
|
Nice. What is the output of this program on your Mac? package main
import (
"fmt"
"unsafe"
)
func main() {
var commpage uintptr = 0x7fffffe0001e
version := *(*uint16)(unsafe.Pointer(commpage))
fmt.Printf("Commpage version: %d\n", version)
} |
|
It'll be I'll prepare a fix tomorrow. |
rasky
added
NeedsFix
|
@rasky, thanks! |
|
Change https://golang.org/cl/87655 mentions this issue: |
|
@cep21 it would be great if you could test this patch, as I don't have Sierra available. |
|
@rasky I applied the patch. Benchmark numbers are back down. |
What version of Go are you using (
go version)?go version go1.10beta2 darwin/amd64Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?What did you do?
Ran my benchmarks on go 1.9 and go 1.10
What did you expect to see?
Little or no change in timings
What did you see instead?
Differences by up to 600%
To reproduce:
I ran benchmarks for go 1.9 and go 1.10. There is the result of benchcmp
The text was updated successfully, but these errors were encountered: