Go 1.14 Release Candidate 1 is released

[Carlos Amedee]

Hello gophers,

We have just released go1.14rc1, a release candidate version of Go 1.14.
It is cut from release-branch.go1.14 at the revision tagged go1.14rc1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.14rc1
is by using the go command:
$ go get golang.org/dl/go1.14rc1
$ go1.14rc1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.14rc1

To find out what has changed in Go 1.14, read the draft release notes:
https://tip.golang.org/doc/go1.14

Cheers,
Carlos and Dmitri on behalf of the Go team

[Kaveh Shahbazian]

"Goroutines are now asynchronously preemptible."

Very nice!

"A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases. This means that programs that use packages like syscall or golang.org/x/sys/unix will see more slow system calls fail with EINTR errors. Those programs will have to handle those errors in some way, most likely looping to try the system call again."

How does this affects projects like Docker?

[Ian Lance Taylor]

I expect that Docker already checks for EINTR where required, so there
shouldn't be much effect at all. Note that checking for EINTR was
always required; what is new in 1.14 is that failing to check for
EINTR is more likely to appear as a problem.

But please do let us know if Docker doesn't work well with 1.14.

Ian

[Andrey Tcherepanov]

Sorry to mention, but for me https://tip.golang.org/doc/go1.14 returns "template: main:846: unexpected EOF"

Not sure if this is because it is work in progress, or too many people trying to hit this site after announcement.

Andrey

[Michael Ellis]

On Wednesday, February 5, 2020 at 6:12:21 PM UTC-5, Andrey Tcherepanov wrote:

Sorry to mention, but for me https://tip.golang.org/doc/go1.14 returns "template: main:846: unexpected EOF"

Not sure if this is because it is work in progress, or too many people trying to hit this site after announcement.

I'm seeing the same problem. 

[amr]

I'm seeing the same problem, also.

[Ian Lance Taylor]

On Wed, Feb 5, 2020 at 3:40 PM amr <amra...@gmail.com> wrote:
>
> I'm seeing the same problem, also.

Sorry about that. It's been fixed.

Ian

[Manlio Perillo]

Is there some overhead due to preemption?

About EINTR, I suspect that some programs will have problems.

As an example

https://github.com/golang/go/issues/22838

The issue was reported for MacOS, but technically every signal, including SIGSTOP, can  interrupt a syscall.

Thanks

Manlio

[Dax McDonald]

Hello,

Hit a small snag while using Go 1.14.

Running go1.14beta1 build main.go on our project, github.com/rancher/rio results in 

go: github.com/StrongMonkey/linkerd2@v0.0.0-20191021165729-976fad67457a: parsing go.mod: go.mod:3: usage: go 1.23

It looks like we are hitting https://github.com/golang/go/issues/36319 but the go.mod file in the fork seems to require 1.12.9 which makes me think it is a different issue.

https://github.com/StrongMonkey/linkerd2/blob/webhook/go.mod

I wasn't sure if this rose the level of being an actual bug or just incorrect usage of the go.mod file. This does not happen with Go 1.13.4

Please let me know if this isn't the right place to post this.

On Wednesday, February 5, 2020 at 12:43:47 PM UTC-7, Carlos Amedee wrote:

[Ian Lance Taylor]

On Wed, Feb 5, 2020 at 11:33 PM Manlio Perillo <manlio....@gmail.com> wrote:
>
> Is there some overhead due to preemption?

Sure, but measurements show that performance is better with this
approach, especially at scale.

> About EINTR, I suspect that some programs will have problems.
> As an example
> https://github.com/golang/go/issues/22838
>
> The issue was reported for MacOS, but technically every signal, including SIGSTOP, can interrupt a syscall.

Go installs all signal handlers with SA_RESTART set, so most cases
will not see an EINTR error. And the Go standard library already
checks for EINTR every place that it needs to. The issue you mention
is not a problem on most systems; apparently on macOS SA_RESTART
doesn't work for SIGTSTP.

That said, as the release notes say, some programs that make direct
system calls are going to see more EINTR errors than they did before.
EINTR was already a possibility; it's just more common now.

Ian

[Ian Lance Taylor]

On Thu, Feb 6, 2020 at 9:51 AM Dax McDonald <dax...@gmail.com> wrote:
>
> Hit a small snag while using Go 1.14.
> Running go1.14beta1 build main.go on our project, github.com/rancher/rio results in
>

> go: github.com/StrongMonkey/link...@v0.0.0-20191021165729-976fad67457a: parsing go.mod: go.mod:3: usage: go 1.23

>
> It looks like we are hitting https://github.com/golang/go/issues/36319 but the go.mod file in the fork seems to require 1.12.9 which makes me think it is a different issue.
>
> https://github.com/StrongMonkey/linkerd2/blob/webhook/go.mod
>
> I wasn't sure if this rose the level of being an actual bug or just incorrect usage of the go.mod file. This does not happen with Go 1.13.4
>
> Please let me know if this isn't the right place to post this.

The file https://github.com/StrongMonkey/linkerd2/blob/master/go.mod
is using an invalid syntax. It says "go 1.12.9", but the format is
"go MAJOR.MINOR". So "go 1.12" would be OK but "go 1.12.9" is not. I
assume that someone wrote that line manually.

Ian

[Klaus Post]

Hi!

I am seeing a generally negative impact of Go 1.13 -> 1.14-RC1 in terms of speed.

Running benchmarks in my deflate package - and removing the "no change" entries:

name                        old time/op    new time/op    delta

DecodeDigitsSpeed1e5-12        903µs ± 0%     940µs ± 1%  +4.14%  (p=0.008 n=5+5)

DecodeDigitsSpeed1e6-12       8.97ms ± 0%    9.40ms ± 1%  +4.80%  (p=0.008 n=5+5)

DecodeDigitsDefault1e4-12     93.2µs ± 0%    95.0µs ± 1%  +1.97%  (p=0.008 n=5+5)

DecodeDigitsDefault1e5-12      855µs ± 0%     882µs ± 2%  +3.15%  (p=0.008 n=5+5)

DecodeDigitsDefault1e6-12     8.58ms ± 0%    8.94ms ± 2%  +4.28%  (p=0.008 n=5+5)

DecodeDigitsCompress1e4-12    93.3µs ± 0%    94.6µs ± 1%  +1.37%  (p=0.016 n=4+5)

DecodeDigitsCompress1e5-12     976µs ± 0%     992µs ± 1%  +1.60%  (p=0.008 n=5+5)

DecodeDigitsCompress1e6-12    9.85ms ± 0%    9.97ms ± 1%  +1.21%  (p=0.016 n=4+5)

DecodeTwainSpeed1e4-12        93.7µs ± 0%    98.0µs ± 2%  +4.60%  (p=0.008 n=5+5)

DecodeTwainSpeed1e5-12         896µs ± 0%     902µs ± 0%  +0.68%  (p=0.008 n=5+5)

DecodeTwainDefault1e4-12      93.0µs ± 0%    95.1µs ± 1%  +2.32%  (p=0.008 n=5+5)

DecodeTwainDefault1e5-12       832µs ± 0%     840µs ± 0%  +0.88%  (p=0.008 n=5+5)

DecodeTwainDefault1e6-12      8.17ms ± 0%    8.22ms ± 0%  +0.68%  (p=0.008 n=5+5)

DecodeTwainCompress1e4-12     90.4µs ± 1%    93.1µs ± 1%  +2.99%  (p=0.008 n=5+5)

DecodeTwainCompress1e5-12      790µs ± 0%     802µs ± 0%  +1.55%  (p=0.008 n=5+5)

DecodeRandomSpeed1e4-12        288ns ± 2%     305ns ± 1%  +5.91%  (p=0.008 n=5+5)

DecodeRandomSpeed1e5-12       2.30µs ± 2%    2.24µs ± 1%  -2.40%  (p=0.008 n=5+5)

_tokens_EstimatedBits-12       651ns ± 0%     707ns ± 2%  +8.67%  (p=0.008 n=5+5)

EncodeDigitsConstant1e4-12    28.4µs ± 0%    29.4µs ± 0%  +3.41%  (p=0.016 n=5+4)

EncodeDigitsConstant1e5-12     307µs ± 0%     314µs ± 2%  +2.41%  (p=0.008 n=5+5)

EncodeDigitsConstant1e6-12    2.70ms ± 0%    2.77ms ± 1%  +2.47%  (p=0.008 n=5+5)

EncodeDigitsSpeed1e5-12        966µs ± 0%     988µs ± 0%  +2.34%  (p=0.008 n=5+5)

EncodeDigitsSpeed1e6-12       9.07ms ± 1%    9.22ms ± 1%  +1.67%  (p=0.032 n=5+5)

EncodeDigitsDefault1e5-12     1.63ms ± 0%    1.65ms ± 1%  +1.17%  (p=0.008 n=5+5)

EncodeDigitsCompress1e5-12    3.70ms ± 1%    3.64ms ± 1%  -1.65%  (p=0.008 n=5+5)

EncodeDigitsCompress1e6-12    40.1ms ± 0%    39.4ms ± 2%  -1.61%  (p=0.008 n=5+5)

EncodeDigitsSL1e5-12           955µs ± 0%     992µs ± 1%  +3.79%  (p=0.008 n=5+5)

EncodeDigitsSL1e6-12          9.34ms ± 0%    9.99ms ± 1%  +6.92%  (p=0.008 n=5+5)

EncodeTwainConstant1e4-12     37.6µs ± 2%    38.9µs ± 2%  +3.51%  (p=0.008 n=5+5)

EncodeTwainConstant1e5-12      337µs ± 0%     345µs ± 1%  +2.38%  (p=0.008 n=5+5)

EncodeTwainSpeed1e4-12         101µs ± 0%     102µs ± 0%  +0.62%  (p=0.024 n=5+5)

EncodeTwainSpeed1e5-12         955µs ± 0%     968µs ± 1%  +1.35%  (p=0.008 n=5+5)

EncodeTwainSpeed1e6-12        8.92ms ± 1%    9.09ms ± 1%  +1.94%  (p=0.032 n=5+5)

EncodeTwainDefault1e4-12       152µs ± 1%     160µs ± 1%  +4.69%  (p=0.008 n=5+5)

EncodeTwainDefault1e5-12      1.44ms ± 1%    1.49ms ± 1%  +3.69%  (p=0.008 n=5+5)

EncodeTwainDefault1e6-12      13.7ms ± 1%    14.2ms ± 2%  +3.43%  (p=0.008 n=5+5)

EncodeTwainCompress1e4-12      267µs ± 1%     272µs ± 2%  +1.97%  (p=0.008 n=5+5)

EncodeTwainCompress1e5-12     4.76ms ± 0%    4.81ms ± 0%  +1.11%  (p=0.008 n=5+5)

EncodeTwainCompress1e6-12     52.4ms ± 0%    53.0ms ± 1%  +1.04%  (p=0.008 n=5+5)

EncodeTwainSL1e4-12            101µs ± 1%     105µs ± 1%  +4.48%  (p=0.008 n=5+5)

EncodeTwainSL1e5-12            925µs ± 1%     949µs ± 1%  +2.59%  (p=0.008 n=5+5)

EncodeTwainSL1e6-12           8.86ms ± 1%    9.24ms ± 0%  +4.28%  (p=0.008 n=5+5)

`_tokens_EstimatedBits` is a microbenchmark and will probably be easier to identify. I will add an issue for that.

Running benchmarks on my zstd package gives a less clear, but still trending towards a performance loss:

name                                        old time/op    new time/op    delta

Decoder_DecoderSmall/kppkn.gtb.zst-12         5.76ms ± 1%    5.87ms ± 2%   +1.98%  (p=0.016 n=5+5)

Decoder_DecoderSmall/geo.protodata.zst-12     1.53ms ± 0%    1.62ms ± 1%   +5.86%  (p=0.008 n=5+5)

Decoder_DecoderSmall/plrabn12.txt.zst-12      19.1ms ± 0%    18.7ms ± 1%   -2.25%  (p=0.008 n=5+5)

Decoder_DecoderSmall/lcet10.txt.zst-12        14.4ms ± 1%    13.6ms ± 0%   -5.65%  (p=0.008 n=5+5)

Decoder_DecoderSmall/html_x_4.zst-12          2.94ms ± 2%    3.00ms ± 0%   +2.21%  (p=0.008 n=5+5)

Decoder_DecoderSmall/paper-100k.pdf.zst-12     473µs ± 1%     511µs ± 1%   +7.94%  (p=0.008 n=5+5)

Decoder_DecoderSmall/fireworks.jpeg.zst-12     485µs ± 2%     511µs ± 4%   +5.29%  (p=0.008 n=5+5)

Decoder_DecoderSmall/html.zst-12              1.65ms ± 1%    1.71ms ± 1%   +4.01%  (p=0.008 n=5+5)

Decoder_DecoderSmall/comp-data.bin.zst-12      191µs ± 1%     206µs ± 1%   +7.70%  (p=0.008 n=5+5)

Decoder_DecodeAll/plrabn12.txt.zst-12         2.21ms ± 1%    2.19ms ± 1%   -0.95%  (p=0.032 n=5+5)

Decoder_DecodeAll/lcet10.txt.zst-12           1.63ms ± 1%    1.65ms ± 0%   +1.20%  (p=0.008 n=5+5)

Decoder_DecodeAll/alice29.txt.zst-12           726µs ± 0%     741µs ± 1%   +2.06%  (p=0.008 n=5+5)

Decoder_DecodeAll/paper-100k.pdf.zst-12       26.2µs ± 2%    28.3µs ± 3%   +8.14%  (p=0.008 n=5+5)

Decoder_DecodeAll/comp-data.bin.zst-12        11.7µs ± 1%    12.1µs ± 3%   +3.21%  (p=0.016 n=5+5)

Encoder_EncodeAllSimple/default-12             496µs ± 1%     491µs ± 1%   -0.85%  (p=0.008 n=5+5)

Encoder_EncodeAllSimple4K/fastest-12          28.6µs ± 1%    29.1µs ± 1%   +1.75%  (p=0.008 n=5+5)

RandomEncodeAllDefault-12                     4.73ms ± 1%    4.82ms ± 1%   +1.82%  (p=0.016 n=5+5)

RandomEncoderFastest-12                       4.30ms ± 3%    4.24ms ± 1%   -1.34%  (p=0.032 n=5+5)

Snappy_ConvertXML-12                          14.1ms ± 0%    13.9ms ± 0%   -1.55%  (p=0.008 n=5+5)

But there are some quite big regressions in there, definitely not what I expected.

Finally, the S2 benchmark assembly disabled is seeing some variance, some rather big losses (mostly encoding) and some rather big wins (mostly decoding, which is mostly memcopy).

name                                          old time/op    new time/op     delta

DecodeS2Block/0-html/block-better-12            13.9µs ± 1%     13.6µs ± 0%   -2.45%  (p=0.016 n=5+4)

DecodeS2Block/2-jpg/block-better-12             1.27µs ± 0%     1.24µs ± 1%   -1.78%  (p=0.008 n=5+5)

DecodeS2Block/4-pdf/block-better-12             2.72µs ± 2%     2.65µs ± 1%   -2.72%  (p=0.008 n=5+5)

DecodeS2Block/5-html4/block-better-12           40.2µs ± 4%     37.7µs ± 2%   -6.20%  (p=0.016 n=5+5)

DecodeS2Block/6-txt1/block-better-12            60.4µs ± 1%     63.0µs ± 2%   +4.26%  (p=0.008 n=5+5)

DecodeS2Block/8-txt3/block-better-12             162µs ± 5%      155µs ± 0%   -4.65%  (p=0.008 n=5+5)

DecodeS2Block/9-txt4/block-12                    161µs ± 1%      157µs ± 0%   -2.62%  (p=0.008 n=5+5)

DecodeS2Block/9-txt4/block-better-12             224µs ± 1%      216µs ± 1%   -3.55%  (p=0.008 n=5+5)

DecodeS2Block/10-pb/block-12                    10.7µs ± 0%     10.6µs ± 1%   -1.43%  (p=0.008 n=5+5)

DecodeS2Block/10-pb/block-better-12             12.1µs ± 0%     11.8µs ± 0%   -1.90%  (p=0.008 n=5+5)

DecodeS2Block/11-gaviota/block-12               51.9µs ± 1%     51.2µs ± 0%   -1.36%  (p=0.032 n=5+5)

DecodeS2Block/12-txt1_128b/block-12             18.0ns ± 1%     17.6ns ± 0%   -2.22%  (p=0.000 n=5+4)

DecodeS2Block/12-txt1_128b/block-better-12      18.3ns ± 1%     17.7ns ± 0%   -3.07%  (p=0.016 n=5+4)

DecodeS2Block/13-txt1_1000b/block-12            73.1ns ± 2%     70.2ns ± 0%   -4.02%  (p=0.008 n=5+5)

DecodeS2Block/13-txt1_1000b/block-better-12      183ns ± 5%      174ns ± 1%   -4.92%  (p=0.008 n=5+5)

DecodeS2Block/14-txt1_10000b/block-12           1.45µs ± 1%     1.40µs ± 0%   -3.08%  (p=0.008 n=5+5)

DecodeS2Block/14-txt1_10000b/block-better-12    3.48µs ± 1%     3.68µs ± 0%   +5.86%  (p=0.008 n=5+5)

DecodeS2Block/15-txt1_20000b/block-12           4.36µs ± 0%     4.54µs ± 0%   +4.08%  (p=0.008 n=5+5)

DecodeS2Block/15-txt1_20000b/block-better-12    8.54µs ± 0%     8.27µs ± 0%   -3.20%  (p=0.008 n=5+5)

EncodeS2Block/0-html/block-12                   26.6µs ± 0%     26.4µs ± 0%   -0.65%  (p=0.008 n=5+5)

EncodeS2Block/0-html/block-better-12            46.3µs ± 1%     46.6µs ± 0%   +0.71%  (p=0.016 n=5+5)

EncodeS2Block/1-urls/block-better-12             567µs ± 0%      573µs ± 0%   +1.00%  (p=0.008 n=5+5)

EncodeS2Block/2-jpg/block-better-12             4.61µs ± 3%     4.44µs ± 1%   -3.76%  (p=0.008 n=5+5)

EncodeS2Block/3-jpg_200b/block-12                282ns ± 2%      274ns ± 0%   -2.83%  (p=0.008 n=5+5)

EncodeS2Block/5-html4/block-better-12           59.1µs ± 1%     61.1µs ± 0%   +3.40%  (p=0.008 n=5+5)

EncodeS2Block/6-txt1/block-12                   96.2µs ± 0%     97.1µs ± 0%   +0.98%  (p=0.008 n=5+5)

EncodeS2Block/6-txt1/block-better-12             165µs ± 0%      169µs ± 1%   +2.44%  (p=0.016 n=4+5)

EncodeS2Block/7-txt2/block-12                   80.7µs ± 0%     81.9µs ± 1%   +1.55%  (p=0.016 n=4+5)

EncodeS2Block/7-txt2/block-better-12             148µs ± 0%      152µs ± 1%   +2.26%  (p=0.016 n=5+4)

EncodeS2Block/8-txt3/block-12                    270µs ± 0%      276µs ± 1%   +1.96%  (p=0.008 n=5+5)

EncodeS2Block/8-txt3/block-better-12             434µs ± 0%      441µs ± 0%   +1.72%  (p=0.016 n=4+5)

EncodeS2Block/9-txt4/block-12                    356µs ± 2%      346µs ± 1%   -2.84%  (p=0.008 n=5+5)

EncodeS2Block/10-pb/block-better-12             40.2µs ± 0%     41.2µs ± 2%   +2.49%  (p=0.008 n=5+5)

EncodeS2Block/11-gaviota/block-12               80.7µs ± 0%     81.7µs ± 0%   +1.30%  (p=0.008 n=5+5)

EncodeS2Block/11-gaviota/block-better-12         128µs ± 0%      131µs ± 6%   +2.45%  (p=0.008 n=5+5)

EncodeS2Block/13-txt1_1000b/block-12             607ns ± 2%      598ns ± 0%   -1.52%  (p=0.024 n=5+5)

EncodeS2Block/14-txt1_10000b/block-12           5.49µs ± 2%     5.06µs ± 1%   -7.79%  (p=0.008 n=5+5)

EncodeS2Block/15-txt1_20000b/block-12           12.3µs ± 1%     12.9µs ± 4%   +4.84%  (p=0.016 n=5+5)

EncodeS2Block/15-txt1_20000b/block-better-12    27.2µs ± 0%     28.7µs ± 2%   +5.40%  (p=0.008 n=5+5)

DecodeSnappyBlock/0-html/s2-snappy-12           17.0µs ± 0%     16.8µs ± 0%   -1.09%  (p=0.008 n=5+5)

DecodeSnappyBlock/1-urls/s2-snappy-12            197µs ± 1%      199µs ± 1%   +1.04%  (p=0.032 n=5+5)

DecodeSnappyBlock/2-jpg/s2-snappy-12            1.26µs ± 1%     1.25µs ± 1%   -1.08%  (p=0.032 n=5+5)

DecodeSnappyBlock/3-jpg_200b/snappy-12          29.7ns ± 9%     26.9ns ± 0%   -9.42%  (p=0.008 n=5+5)

DecodeSnappyBlock/3-jpg_200b/s2-snappy-12       28.0ns ± 2%     26.8ns ± 1%   -4.07%  (p=0.008 n=5+5)

DecodeSnappyBlock/5-html4/s2-snappy-12          70.5µs ± 2%     68.2µs ± 1%   -3.26%  (p=0.016 n=4+5)

These are microbenchmarks which tends to over-emphasize differences, so I would say overall it looks like a 2% loss.

[Uli Kunitz]

On my microbenchmarks I'm seeing a huge negative impact (ca. 15%) under the Linux ondemand governor. Under the performance governor its less than 1%.

[Ian Lance Taylor]

On Fri, Feb 7, 2020 at 11:01 AM Klaus Post <klau...@gmail.com> wrote:
>
> I am seeing a generally negative impact of Go 1.13 -> 1.14-RC1 in terms of speed.

Thanks. Would you mind opening an issue about this (if you haven't already)?

Ian

[Robert Engels]

I would caution that reduced performance with ondemand might be a good thing. If the job is doing lots of IO this means the process has little/less overhead so less drain on the cpu meaning it takes a while to spin back up.

If both governors show the serious degradation I would be far more concerned.

It can also be attributed to more underlying lock contention -causing deschedules - which would be a bad thing.

> On Feb 7, 2020, at 5:30 PM, Ian Lance Taylor <ia...@golang.org> wrote:

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV2CkgiPm1%3DbWtVUA2ra71N9BkYvaAOfCACMVzALOvY2w%40mail.gmail.com.

[Jan Mercl]

On Wed, Feb 5, 2020 at 8:43 PM Carlos Amedee <car...@golang.org> wrote:

> We have just released go1.14rc1, a release candidate version of Go 1.14.

I am glad to report substantial improvements for a set of benchmarks of the gocc
compiler[0], which is an experimental/WIP C compiler implemented in Go that can
also produce Go code.

Note: The benchmarks are not benchmarking the compiler but the code produced by the gocc compiler.

----

gocc commit bf916e5600, Tue Dec 24 17:01:06 2019 +0100

Go 1.13.7 linux/amd64

    ...

    all_test.go:2092:     goccgo       perlin.c   411.430ms  true  true  true  13.769

    ...

    all_test.go:2099: Considered tests: 24/24
    all_test.go:2107:        gcc   1.926479916s  1.000
    all_test.go:2107:       gocc   2.084863963s  1.082
    all_test.go:2107:     goccgo   6.272091508s  3.256

Go 1.14rc1 linux/amd64

    TestCompCert: all_test.go:2092:     goccgo       perlin.c   159.321ms  true  true  true   5.396

    ...

    TestCompCert: all_test.go:2099: Considered tests: 24/24
    TestCompCert: all_test.go:2107:        gcc   1.945554301s  1.000
    TestCompCert: all_test.go:2107:       gocc   2.073950104s  1.066
    TestCompCert: all_test.go:2107:     goccgo   4.853355485s  2.495

----

The cumulative index (gcc = 1) of executing a set of 24 benchmarks for the Go backend went from 3.256
to 2.495 (-23%).

The worst performing test, perlin.c, was executing 13.769 times slower than the code produced

by gcc with Go 1.13.7 and the Go backend. With Go 1.14rc1 this went down to 5.396 time slower (-60%).

Full results are enclosed in the attachments.

----

  [0]: https://godoc.org/modernc.org/gocc