Go 1.4 Release Candidate 1 is released

[Andrew Gerrand]

Hi Go nuts,

We have just released go1.4rc1, the first release candidate for Go 1.4.

It is cut from release-branch.go1.4 at the revision tagged go1.4rc1.

Please help us by testing your Go programs with the release, and report any problems using the issue tracker:

    http://golang.org/issue/new

You can download binary and source distributions from the usual place:

    http://golang.org/dl/#go1.4rc1

To find out what has changed in Go 1.4, read the release notes:

    http://tip.golang.org/doc/go1.4

Documentation for Go 1.4 is available at:

    http://tip.golang.org/

Our goal is to release the final version of Go 1.4 on December 2, 2014.

Andrew

[小菜]

I am waitting for 1.4.1 , because 1.4.1 will fix some bugs of 1.4.

在 2014年11月17日星期一UTC+8下午1时04分29秒，Andrew Gerrand写道：

[Julius Kovac]

Great work of whole team, thank you! I hope to see it soon on appengine to test it.

[Dmitri Shuralyov]

That's excellent, thank you so much!

[Dave Cheney]

Do you have a list of the bugs that you are waiting to be fixed?

[Ian Taylor]

On Mon, Nov 17, 2014 at 1:09 AM, 小菜 <yxw.2...@gmail.com> wrote:
>
> I am waitting for 1.4.1 , because 1.4.1 will fix some bugs of 1.4.

1.4 isn't even out yet. If there are any bugs that would be fixed in
1.4.1 later, they should be fixed in 1.4 now.

The policy for Go point releases is that they only include bug fixes
that are critical and can not be avoided by making changes to the
program.

Ian

[dipp...@gmail.com]

Thanks for the release!
I've tested my code i was currently working on, but i noticed that with 1.4rc1 my code (daisychain of channels) is almost twice as slow. Must i fill a issue for this? I shall i post a new message in this forum?

[Andrew Gerrand]

Please file issues for significant performance issues in real code.
If it's a toy or microbenchmark, don't worry about it.

(Your "daisychain of channels" sounds like a toy program, correct me if I'm wrong.)

We know some things slowed down in this release, and some things sped up.

For most real programs there should be no significant difference.

Andrew

On Tue Nov 18 2014 at 4:06:24 AM <dipp...@gmail.com> wrote:

Thanks for the release!
I've tested my code i was currently working on, but i noticed that with 1.4rc1 my code (daisychain of channels) is almost twice as slow. Must i fill a issue for this? I shall i post a new message in this forum?

--
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.
For more options, visit https://groups.google.com/d/optout.

[Ugorji Nwoke]

This is a clear regression on the build dashboard:

http://build.golang.org/perfdetail?commit=4cd22c3c8bf273f85774a682b8fd2c727b2b3df4&commit0=f153208c0a0e306bfca14f71ef11f09859ccabc8&benchmark=http

The http benchmark shows about 12% regression in walltime and cputime. 

The garbage benchmark shows about 5% regression in walltime and cputime.

[小菜]

good news！

在 2014年11月17日星期一UTC+8下午1时04分29秒，Andrew Gerrand写道：

[Pierre Durand]

When I update my gopath, I have this error:

imports github.com/pierrre/imageserver/cache: /home/pierre/Go/src/github.com/pierrre/imageserver is from g...@github.com:pierrre/imageserver.git, should be from https://github.com/pierrre/imageserver

There is no problem with Go 1.3.3.

[James Bardin]

On Tuesday, November 18, 2014 5:42:08 AM UTC-5, Pierre Durand wrote:

When I update my gopath, I have this error:

imports github.com/pierrre/imageserver/cache: /home/pierre/Go/src/github.com/pierrre/imageserver is from g...@github.com:pierrre/imageserver.git, should be from https://github.com/pierrre/imageserver

There is no problem with Go 1.3.3.

You need to use `go get -u -f` due to the addition of canonical import paths, or update ssh checkouts using git directly.

While I really like the addition of canonical import paths for packages, I'm not a fan of this new limitation with git ssh checkouts. Could there be a translation that happens so that the go tool accepts that '"g...@github.com:user/repo.git" is valid for "https://github.com/user/repo"?

[Luna Duclos]

This is a must have as far as I'm concerned. The canonical import path doesn't change just because we switch from https to ssh or vice-versa. Having to punch in passwords constantly is gonna get old very quickly

[Pierre Durand]

I use "go get -v -u ..." to update everything in my $GOPATH.

"go get -u -f ..." will disable check for all packages?

[Pierre Durand]

Is it a bug?

Should I open an issue?

[Pierre Durand]

Another error message:

package cmd/internal/rsc.io/arm/armasm: directory "/home/pierre/Logiciels/go/src/cmd/internal/rsc.io/arm/armasm" is not using a known version control system

package cmd/internal/rsc.io/x86/x86asm: directory "/home/pierre/Logiciels/go/src/cmd/internal/rsc.io/x86/x86asm" is not using a known version control system

[Frank Schröder]

What I am seeing is that the compiler got 15% slower. Especially the empty rebuilds are 4x slower. If I compile our codebase of 31 binaries with go install prj/... I get these results:

Full rebuild == bin & pkg removed then go install prj/...

Empty rebuild == rebuild without changes

go version go1.3.3 darwin/amd64 (10.10.1)

Full rebuild: 4.6 sec

Empty rebuild: 160 ms

go version go1.4rc1 darwin/amd64 (10.10.1)

Full rebuild: 5.3 sec

Empty rebuild: 670 ms

Frank

On Monday, November 17, 2014 6:04:29 AM UTC+1, Andrew Gerrand wrote:

[Dave Cheney]

Can you capture the results of this data with the -xflag added. It should be pretty easy to figure out what has changed from that.

[Frank Schröder]

Sure. Here you go: https://gist.github.com/magiconair/7a2af974747b6d38132b

Frank

> On 27 Nov 2014, at 23:42, Dave Cheney <da...@cheney.net> wrote:
>
> Can you capture the results of this data with the -xflag added. It should be pretty easy to figure out what has changed from that.
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/mP5sSNwezVc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Dave Cheney]

Thanks, that is the 1.3.3 install, where is the 1.4rc1 install ?

Is it possible to simplify your build process with

go install -x cas/...

?

[Frank Schröder]

The 1.4 log is further down. The gist has two files. There was a reason I did it this way but I'm not sure if it applies any longer. I'll check.

Frank

[Frank Schröder]

Yep, go install -x cas/... worked. Updated the gist. Same result though.

Frank

[Dave Cheney]

Doh, yes, I missed that. I'm trying to reproduce the problem now.

[Dave Cheney]

I can't reproduce the problem

lucky(~) % rm -rf ${GOPATH}/{pkg,bin} && time ~/go1.3.3/bin/go install github.com/juju/juju/... && time ~/go1.3.3/bin/go install github.com/juju/juju/...

real    0m13.211s

user    0m42.699s

sys     0m7.407s

real    0m0.399s

user    0m0.334s

sys     0m0.072s

lucky(~) % rm -rf ${GOPATH}/{pkg,bin} && time ~/go1.4rc1/bin/go install github.com/juju/juju/... && time ~/go1.4rc1/bin/go install github.com/juju/juju/...

real    0m13.461s

user    0m43.301s

sys     0m7.498s

real    0m0.443s

user    0m0.371s

sys     0m0.079s

There is a tiny, .2 seconds over 13.4 seconds wall time, increase compiling juiju from scratch (some 282 packages) comparing 1.3.3 to 1.4rc1. Juju does not use cgo, which may be a clue to explaining why the times have increased for your build.

[Frank Schröder]

Isn't cgo is still necessary for networking?

Frank

[Dave Cheney]

Sorry, I was not clear. Juju does not use packages that use cgo, it's
all pure go. The net package (which does use cgo) is part of the
standard library so will not be recompiled in this test.

[Frank Schröder]

Our code is also pure Go and I've checked the libs we're using for import "C" but couldn't find any. Also, that wouldn't explain the 4x slower rebuild when nothing has changed.

I assume you're on Linux. I'm on OSX.

Tried building juju on OSX but tip does not compile and 1.21 dependencies don't seem to match.

Tried etcd. Same effect. Also no import "C"

$ go version ; rm -rf ${GOPATH}/{bin,pkg} ; time go install -x github.com/coreos/etcd/... ; time go install -x github.com/coreos/etcd/...
go version go1.3.3 darwin/amd64

real 0m1.619s
user 0m3.310s
sys 0m0.729s
WORK=/var/folders/6v/lm4r65rd4375nrt1qg8nn8v43900l6/T/go-build026948869

real 0m0.096s
user 0m0.064s
sys 0m0.029s
frschroeder@LM-AMS-00963965:~/gojuju/src$


$ go version ; rm -rf ${GOPATH}/{bin,pkg} ; time go install -x github.com/coreos/etcd/... ; time go install -x github.com/coreos/etcd/...
go version go1.4rc1 darwin/amd64

real 0m2.009s
user 0m3.623s
sys 0m0.718s
WORK=/var/folders/6v/lm4r65rd4375nrt1qg8nn8v43900l6/T/go-build176257592

real 0m0.520s
user 0m0.480s
sys 0m0.040s
frschroeder@LM-AMS-00963965:~/gojuju$
Any other ideas?

Frank

[Dave Cheney]

Try building from source

hg clone https://code.google.com/p/go -r go1.3.3 go1.3.3
hg clone https://code.google.com/p/go -r go1.4rc1 go1.4rc1

cd into each directory/src, ./make.bash

then call go directly, ~/go1.3.3/bin/go install ...

[Frank Schröder]

Indeed.

The go 1.4.1-rc1 I've used before is the official OSX 10.8+ build from https://golang.org/dl/

https://storage.googleapis.com/golang/go1.4rc1.darwin-amd64-osx10.8.tar.gz

That one doesn't seem to work as well on OSX 10.10.

tip seems to be between 1.3.3 and 1.4.1-rc1

$ rm -rf ${GOPATH}/{bin,pkg} ; time ~/go1.3.3/bin/go install github.com/coreos/etcd/... ; time ~/go1.3.3/bin/go install github.com/coreos/etcd/...

real 0m2.098s
user 0m4.642s
sys 0m0.648s

real 0m0.089s
user 0m0.062s
sys 0m0.026s

$ rm -rf ${GOPATH}/{bin,pkg} ; time ~/go1.4rc1/bin/go install github.com/coreos/etcd/... ; time ~/go1.4rc1/bin/go install github.com/coreos/etcd/...

real 0m2.311s
user 0m4.929s
sys 0m0.741s

real 0m0.105s
user 0m0.076s
sys 0m0.027s

go version devel +ffe33f1f1f17 Tue Nov 25 15:41:33 2014 +1100 darwin/amd64
$ rm -rf ${GOPATH}/{bin,pkg} ; time ~/gotip/bin/go install github.com/coreos/etcd/... ; time ~/gotip/bin/go install github.com/coreos/etcd/...

real 0m2.161s
user 0m4.755s
sys 0m0.673s

real 0m0.097s
user 0m0.070s
sys 0m0.027s


Thx Dave
Frank
--
Frank Schröder
Amsterdam, NL
PGP - DDA53977

[Jian Zhen]

Sorry guys, I know everyone’s worked really hard on 1.4 and I appreciate everything you have done. I don’t want to pile on, only wanted to provide some additional data points. So take it for whatever it’s worth. I am sure there will be additional improvements coming.

For now, I am seeing about ~20% slow down in my code. The code is a MQTT message broker and it’s available at https://github.com/surge/surgemq.

In this benchmark I am using Tyler Treat’s MQ benchmark tool: https://github.com/tylertreat/mq-benchmarking 

Here’s the results I am seeing: I was able to send and receive approximately 325K-350K messages per second with 1.3.3, and with 1.4rc1, I am down to 250K-275K.

Sun 30 18:28  mq-benchmarking (master *)$ go version

go version go1.3.3 darwin/amd64

Sun 30 18:28  mq-benchmarking (master *)$ GOMAXPROCS=2 go run main.go surge false 1000000 1024

2014/11/30 18:29:03 Begin surge test

2014/11/30 18:29:06 Sent 1000000 messages in 2948.333740 ms

2014/11/30 18:29:06 Sent 339174.625000 per second

2014/11/30 18:29:06 Received 1000000 messages in 2952.769043 ms

2014/11/30 18:29:06 Received 338665.156250 per second

2014/11/30 18:29:06 End surge test

Sun 30 18:29  mq-benchmarking (master *)$ go version

go version go1.4rc1 darwin/amd64

Sun 30 18:29  mq-benchmarking (master *)$ GOMAXPROCS=2 go run main.go surge false 1000000 1024

2014/11/30 18:29:36 Begin surge test

2014/11/30 18:29:40 Sent 1000000 messages in 3671.864746 ms

2014/11/30 18:29:40 Sent 272341.187500 per second

2014/11/30 18:29:40 Received 1000000 messages in 3676.679932 ms

2014/11/30 18:29:40 Received 271984.500000 per second

2014/11/30 18:29:40 End surge test

[Dmitry Vyukov]

Please provide exact reproduction instructions.

[Jian Zhen]

To run this, you need to

# go get github.com/surge/surgemq
# go get github.com/surge/mq-benchmarking

In one terminal window, run

# cd surgemq
# go run surgemq.go

In another terminal window, run

# cd mq-benchmarking
# go run main.go surge false 1000000 1024


I was running my tests on a MacBook Pro (13 inch, Late 2013), 2.8 GHz Intel Core i7, 16 GB 1600 MHz DDR3.

Let me know if you need anything else.

thx

Jian