Merging dev.ssa into tip

[Keith Randall]

tl;dr we'll be merging the dev.ssa branch into mainline in the next day or so.

We've been working hard at preparing the SSA compiler for the main Go tree.  The SSA compiler currently generates modestly faster and modestly smaller code than the main branch compiler.  We know a lot of people are concerned about compiler speed, so in addition a bunch of effort has been put into keeping the compiler fast.  We feel we've reached the point where we should merge into the main branch so that we can expose this work to a wider audience.  Work will continue on the SSA compiler - we expect the numbers below to improve as we do that.

Numbers:

SSA compiler (with development consistency checks turned off) is 10% slower than go1.6.

SSA-generated binaries are about 5% smaller than tip-generated binaries.

G01 benchmarks:

name                     old time/op    new time/op     delta

BinaryTree17-8              2.71s ± 0%      2.90s ± 1%   +7.19%    (p=0.000 n=9+9)

Fannkuch11-8                2.41s ± 0%      2.32s ± 0%   -3.94%   (p=0.000 n=9+10)

FmtFprintfEmpty-8          48.1ns ± 1%     46.0ns ± 0%   -4.40%  (p=0.000 n=10+10)

FmtFprintfString-8          161ns ± 0%      165ns ± 2%   +2.55%   (p=0.000 n=8+10)

FmtFprintfInt-8             153ns ± 0%      155ns ± 1%   +1.72%   (p=0.000 n=10+9)

FmtFprintfIntInt-8          251ns ± 0%      258ns ± 0%   +2.43%  (p=0.000 n=10+10)

FmtFprintfPrefixedInt-8     228ns ± 1%      222ns ± 1%   -2.63%  (p=0.000 n=10+10)

FmtFprintfFloat-8           305ns ± 0%      297ns ± 0%   -2.86%   (p=0.000 n=10+9)

FmtManyArgs-8               969ns ± 0%      998ns ± 0%   +3.02%   (p=0.000 n=10+8)

GobDecode-8                8.47ms ± 4%     7.48ms ± 0%  -11.72%  (p=0.000 n=10+10)

GobEncode-8                6.43ms ± 2%     6.02ms ± 0%   -6.42%   (p=0.000 n=10+9)

Gzip-8                      307ms ± 0%      281ms ± 0%   -8.70%    (p=0.000 n=9+9)

Gunzip-8                   40.0ms ± 1%     41.7ms ± 3%   +4.14%  (p=0.000 n=10+10)

HTTPClientServer-8         78.6µs ± 1%     74.7µs ± 1%   -4.91%  (p=0.000 n=10+10)

JSONEncode-8               16.5ms ± 1%     15.6ms ± 1%   -5.82%  (p=0.000 n=10+10)

JSONDecode-8               64.1ms ± 1%     56.9ms ± 0%  -11.10%   (p=0.000 n=10+9)

Mandelbrot200-8            3.75ms ± 0%     4.18ms ± 0%  +11.41%  (p=0.000 n=10+10)

GoParse-8                  3.53ms ± 2%     3.48ms ± 0%   -1.34%  (p=0.000 n=10+10)

RegexpMatchEasy0_32-8      82.6ns ± 1%     72.2ns ± 1%  -12.61%   (p=0.000 n=9+10)

RegexpMatchEasy0_1K-8       255ns ± 1%      243ns ± 0%   -4.41%   (p=0.000 n=10+8)

RegexpMatchEasy1_32-8      81.2ns ± 1%     74.9ns ± 2%   -7.71%   (p=0.000 n=10+9)

RegexpMatchEasy1_1K-8       408ns ± 1%      399ns ± 2%   -2.35%  (p=0.000 n=10+10)

RegexpMatchMedium_32-8      128ns ± 1%      119ns ± 1%   -7.03%   (p=0.000 n=10+8)

RegexpMatchMedium_1K-8     38.6µs ± 1%     38.9µs ± 2%     ~     (p=0.101 n=10+10)

RegexpMatchHard_32-8       2.01µs ± 2%     1.93µs ± 2%   -4.00%  (p=0.000 n=10+10)

RegexpMatchHard_1K-8       60.7µs ± 2%     58.9µs ± 2%   -2.98%  (p=0.000 n=10+10)

Revcomp-8                   477ms ± 1%      459ms ± 7%   -3.89%   (p=0.002 n=9+10)

Template-8                 82.1ms ± 2%     69.6ms ± 3%  -15.22%   (p=0.000 n=10+9)

TimeParse-8                 346ns ± 1%      364ns ± 1%   +5.05%   (p=0.000 n=9+10)

TimeFormat-8                348ns ± 1%      371ns ± 0%   +6.77%   (p=0.000 n=10+9)

(attached are the same numbers viewed with benchviz)

We will leave the development consistency checks on for a while in main branch, but I plan to turn them off for the 1.7 release.

Anyone working on dev.ssa, you have until noon PST to get changes in.  Otherwise, please wait and rebase your changes onto the main branch.

[Russ Cox]

Great news! Thanks.

Russ

[Keith Randall]

dev.ssa has now been merged into tip.  Yay!  The merge was much easier than I thought it would be.

Please report any bugs or performance regressions via the issue system.

We've tested pretty well with all.bash but I'd like people to try any code they have outside the main repo and let me know if things still work.  Positive reports are also welcome.

If you'd like to turn off the SSA compiler, run with GOSSAHASH=x.  (Kind of a hack for now, we'll have a GODEBUG flag set up soon.)

[Brad Fitzpatrick]

Few questions:

1) is disabling SSA going to be an option for Go 1.7 via GODEBUG, or is that just a temporary measure?

2) if 1), we should configure at least one builder using the old compiler backend, so it doesn't regress on amd64. How best to configure it? GOSSAHASH=x for now I guess?

3) please clarify for others what the policy is for other architectures (other than amd64) switching themselves to SSA.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[minux]

On Tue, Mar 1, 2016 at 5:49 PM, Brad Fitzpatrick <brad...@golang.org> wrote:

Few questions:

1) is disabling SSA going to be an option for Go 1.7 via GODEBUG, or is that just a temporary measure?

2) if 1), we should configure at least one builder using the old compiler backend, so it doesn't regress on amd64. How best to configure it? GOSSAHASH=x for now I guess?

3) please clarify for others what the policy is for other architectures (other than amd64) switching themselves to SSA.

What's the policy of new architecture ports? Do we require SSA-based backend

for new ports? If not for now, when do we start to enforce that? (We probably

don't want to maintain two incompatible backends forever so we probably want

to stop accepting new ports still using the old backend some time in the future.)

Given the number of ports (s390x, sparc64, riscv64, mips, and probably more)

that are currently work in progress, I suggest that we wait at least one release

cycle, probably two. Another alternative is that once at least one of the existing

RISC architectures has finished SSA conversion, we start enforcing that for new

ports.

[Keith Randall]

On Tue, Mar 1, 2016 at 3:02 PM, minux <mi...@golang.org> wrote:

On Tue, Mar 1, 2016 at 5:49 PM, Brad Fitzpatrick <brad...@golang.org> wrote:

Few questions:

1) is disabling SSA going to be an option for Go 1.7 via GODEBUG, or is that just a temporary measure?

Yes, disabling via GODEBUG will exist in 1.7.  We'll have to discuss whether we want/need that for 1.8 and beyond.  Maybe for some archs and not others as we grow comfortable with each port.

 

2) if 1), we should configure at least one builder using the old compiler backend, so it doesn't regress on amd64. How best to configure it? GOSSAHASH=x for now I guess?

Sure.

There are a few tricky details, like the two compilers disagree on which nil checks are redundant.  So you can't actually run GOSSAHASH=x ./all.bash and have it pass right now. (See test/nilptr3.go and test/nilptr3_ssa.go).  We'd have to special case that test.

3) please clarify for others what the policy is for other architectures (other than amd64) switching themselves to SSA.

Other architectures can switch as soon as they wish.  I'm planning on cleaning up as many of the x86-isms as I can find in the code base in the next week or two.  Then I will start in on a port, maybe arm, not so much as to actually make a working port as to make sure the infrastructure for starting new ports is useable.

I don't intend that any other ports make the 1.7 cutoff.  I would hope that most make the 1.8 cutoff.

I am hoping to get a room full of porters together at Gophercon.

What's the policy of new architecture ports? Do we require SSA-based backend

for new ports? If not for now, when do we start to enforce that? (We probably

don't want to maintain two incompatible backends forever so we probably want

to stop accepting new ports still using the old backend some time in the future.)

I think we can still accept old-style ports for 1.7.  We probably want to force new ports to use SSA for 1.8.

 

Given the number of ports (s390x, sparc64, riscv64, mips, and probably more)

that are currently work in progress, I suggest that we wait at least one release

cycle, probably two. Another alternative is that once at least one of the existing

RISC architectures has finished SSA conversion, we start enforcing that for new

ports.

That sounds reasonable. 

[Rob Pike]

Nice work, but:

Running make.bash on my MacBook Pro is now 2m37s user vs. 1m49s at tip a day or two before. That's a lot slower, almost a full minute of CPU time. That works out to about 45% slower (157/109 is 1.44). Real time is worse: 67s vs. 43s, about 55%. I know you were comparing to 1.6 and I'm comparing to tip, but 1.6 (and 1.5) were too slow, too.

The compiler still needs significant work on throughput.

-rob

[Keith Randall]

That's because the expensive development consistency checks are still on.

I'll add a compile-time flag to turn those on or off.  I'd like it to default to on for a while just so it will catch problems with the compiler at compile time instead of randomly at runtime.

[Brad Fitzpatrick]

Perhaps the expensive checks should only be on if:

    strings.Contains(os.Getenv("GODEBUG"), "ssacheck=1") || os.Getenv("GO_BUILDER_NAME") != ""

So then you and other SSA hackers get coverage (with ssacheck=1 in your env), and the builders always test it too?

[Keith Randall]

I'm more interested in the check running on code outside the main repo.  That's the one thing I can't do easily myself.

If it weren't for that I'd agree.

Give me 2 weeks with the checks on, and then we'll default them to off.

[Rob Pike]

Sounds good, thanks. I feel compiler speed is more important for Go than for other languages because we started out screaming fast, and there's an implied promise there. Some people are still on 1.4 because of this issue. It's important.

-rob

[Russ Cox]

I have a large data set of compiler speed numbers that I'm tracking, from 1.4 to the present. Once I have code to plot it in a reasonable way, I will check it into x/perfdata and that can be the basis of our first new performance dashboard. (The same data set has binary size too.)

Russ

[Aram Hăvărneanu]

I will do SSA for arm64, probably for 1.8, not 1.7, but who knows. I
will also do SSA for sparc64 for 1.8.

For 1.7, the sparc64 port won't have SSA just yet.

--
Aram Hăvărneanu

[Dan Adkins]

FWIW, going from go1.6 to tip I observed a 20% drop in compile time and a 10% drop in run time on one of my programs. Great job! Compile times are now better than go1.5 and the generated code is better than ever.

-Dan

[Keith Randall]

New ssa-controlling flags are now in.

To turn ssa on and off, use -ssa=1 (the default) and -ssa=0 args to the compiler.  Typically you'll set those using the -gcflags arg to "go build" or with the GO_GCFLAGS environment variable to make.bash.  We can set up a builder with GO_GCFLAGS=-ssa=0 to make sure the old compiler keeps working.

To turn on/off the internal consistency checks, use -d=ssa/check/on and -d=ssa/check/off.  They will default to on for another 10 days or so, then I'll default them to off.

That's just the executive summary.  David added a lot more detailed flags that let you turn on/off individual passes, turn on debugging output, etc.

GOSSAHASH=x is officially deprecated.  Pretend it never existed.  Its 15 minutes of fame is over.