[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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? 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d3b3104e-42fa-4ab6-abc6-23b21fd3a333%40googlegroups.com.

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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


On Wednesday, February 5, 2020 at 12:43:47 PM UTC-7, Carlos Amedee wrote:
>
> 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
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5807e8c6-e48d-433e-9642-f1fa86cf427a%40googlegroups.com.

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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. 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b534f383-9421-4504-8816-df496a2ecdc7%40googlegroups.com.

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[amr]

I'm seeing the same problem, also.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3ef3143b-15d4-4ae1-902b-c9d860ebc1d4%40googlegroups.com.

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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

On Wednesday, February 5, 2020 at 8:43:47 PM UTC+1, Carlos Amedee wrote:
>
> 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
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e8db33b3-097a-42ff-a486-49733cbd8cf9%40googlegroups.com.

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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:
>
> 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
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0725f9cd-1029-4391-969f-dba70c2bb4d8%40googlegroups.com.

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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:

nameold time/opnew time/opdelta
DecodeDigitsSpeed1e5-12903µ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-1293.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-129.85ms ± 0%9.97ms ± 1%  +1.21%  (p=0.016 
n=4+5)
DecodeTwainSpeed1e4-1293.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-12288ns ± 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-1228.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-122.70ms ± 0%2.77ms ± 1%  +2.47%  (p=0.008 
n=5+5)
EncodeDigitsSpeed1e5-12966µ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-123.70ms ± 1%3.64ms ± 1%  -1.65%  (p=0.008 
n=5+5)
EncodeDigitsCompress1e6-1240.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-128.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-12101µs ± 1% 105µs ± 1%  +4.48%  (p=0.008 
n=5+5)
EncodeTwainSL1e5-12925µ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:

nameold time/opnew 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-1214.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

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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%.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/93dd241f-4bfa-45ba-842e-ded094867137%40googlegroups.com.

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

[Ian Lance Taylor]

On Wed, Feb 5, 2020 at 2:05 PM Kaveh Shahbazian
 wrote:
>>
>> "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?

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX7WhnuQQW2AeaQcGNbx9guaYdGS%2BDdJvM5_V81XBUg0Q%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

[Ian Lance Taylor]

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

Sorry about that.  It's been fixed.

Ian

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVMTuyf7RE6TnGegwCopUPeGR5mto5%2B-xQHr5fPBaz2Ag%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

[Ian Lance Taylor]

On Wed, Feb 5, 2020 at 11:33 PM Manlio Perillo  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW66BwS4GQecwGLVHAQ8vXJTjc_OU_YSPQwfkq2ZqC7aA%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

[Ian Lance Taylor]

On Thu, Feb 6, 2020 at 9:51 AM Dax McDonald  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/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.

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV-KOOBVL3rj0edFhehDbc%2BP2yEV7eR%3DyPDUoobpfE3iA%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

[Ian Lance Taylor]

On Fri, Feb 7, 2020 at 11:01 AM Klaus Post  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV2CkgiPm1%3DbWtVUA2ra71N9BkYvaAOfCACMVzALOvY2w%40mail.gmail.com.

Re: [go-nuts] Re: Go 1.14 Release Candidate 1 is released

[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  wrote:
> 
> On Fri, Feb 7, 2020 at 11:01 AM Klaus Post  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
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV2CkgiPm1%3DbWtVUA2ra71N9BkYvaAOfCACMVzALOvY2w%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/51EADAE3-8664-4C8E-AAA9-6CBB20A29BCC%40ix.netcom.com.