cmd/compile: go1.7beta2 performance regressions

[ajstarks]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?

go 1.6.2, go1.7beta2

1. What operating system and processor architecture are you using (go env)?

linux/arm64, linux/arm

1. What did you do?

run the standard go1 benchmarks

1. What did you expect to see?

little to no performance regression

1. What did you see instead?

see:
https://gist.github.com/ajstarks/fa05919377de73a552870ce9e45e4844 for linux/arm64 (pine64)
https://gist.github.com/ajstarks/c937a1a80e76b4692cb52c1d57a4494d for linux/arm (CHIP)

regressions occur on GobEncode, GobDecode, JSONEncode, and JSONDecode

[josharian]

I'm away from my arm(64) machines for a couple of weeks. Help bisecting would be lovely.

[ajstarks]

benchviz for Pine64
pine64.pdf

[ianlancetaylor]

CC @randall77

[cherrymui]

@quentinmit and I are looking at this. We found that it also slows down on linux/386, and linux/amd64 with -ssa=0, with GobDecode, JSONDecode and Template being the most significant. Gzip is getting faster, though. So, probably it is not the compiler?

[josharian]

Could be the runtime, or it could be front-end compiler changes. I think there were near zero 386 or arm-specific fixes this cycle, so it might be worth comparing the generated code to rule out the compiler (perhaps after some profiling to pinpoint the change).

[josharian]

Al those packages use reflection. Could it be related to the type reworking?

[quentinmit]

Reflection is definitely part of the puzzle. Here's the state of our investigation so far:

• Template: ~22% performance hit on arm32, arm64, and 386. Largest hit due to http://golang.org/cl/20968. @RLH is trying to use VTune to pin down the slow code.
• Revcomp: ~30% performance hit on 386 only. Entirely due to http://golang.org/cl/20901. @dr2chase is looking at this.
• GobDecode: ~10% performance hit on arm32, arm64, and 386. Very noisy, no obvious culprit.
• JsonDecode: ~30% performance hit on arm32, arm64, ~15% on 386. Less noisy, still no obvious culprit.
• Gzip: ~20% performance hit on arm32, arm64. Still need to bisect (not as easy as bisecting on 386).

[RLH]

The slow version contains a call to this routine that the faster version
does not contain. This accounts for aroutne 3% of the total time. It is the
only routine that stood out in the top 20 routines.
inst retired| cpu_clk unhalted
reflect.(_name).name 3.3% 2.9% type.go 0x8166a40 go1-template-bad
reflect.(_name).name

On Tue, Jun 21, 2016 at 2:50 PM, Quentin Smith notifications@github.com
wrote:

Reflection is definitely part of the puzzle. Here's the state of our
investigation so far:

• Template: ~22% performance hit on arm32, arm64, and 386. Largest hit
  due to http://golang.org/cl/20968. @RLH https://github.com/rlh is
  trying to use VTune to pin down the slow code.
• Revcomp: ~30% performance hit on 386 only. Entirely due to
  http://golang.org/cl/20901. @dr2chase https://github.com/dr2chase is
  looking at this.
• GobDecode: ~10% performance hit on arm32, arm64, and 386. Very
  noisy, no obvious culprit.
• JsonDecode: ~30% performance hit on arm32, arm64, ~15% on 386. Less
  noisy, still no obvious culprit.
• Gzip: ~20% performance hit on arm32, arm64. Still need to bisect
  (not as easy as bisecting on 386).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16117 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AA7Wn6TQ1oaw8NNBTuIsKaDeSjMWq_SXks5qODKDgaJpZM4I5NAI
.

[ianlancetaylor]

CC @crawshaw

[ianlancetaylor]

@RLH Is it easy for you to find the significant callers of reflect.(*name).name?

It's possible that the significant callers are from code that is looking for a specific name, which we could probably speed up somewhat by doing things like checking the length before building the string we return.

[dr2chase]

I have an existence proof that code alignment can cost you 10% on Revcomp.