Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.5 Beta

golang.org

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Go 1.5 Beta

#31

Post by bsdetector »

melle wrote: post #18
vruiz wrote: post #3

changelog: https://tip.golang.org/doc/go1.5 It seems to me like they've included Google's trace viewer[0] into the go tool, nice. [0] https://github.com/google/trace-viewer

From the changelog: > Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. This seems quite a drast…

Compilation speed was just a gimmick anyway; the compiler is fast because it doesn't do many expensive optimizations. It was like bragging that using "-O0" makes a compiler so fast. There are languages that require a lot of work just to compile at all, like C++, but for most languages slow compilation is more a measure of how advanced the compiler is.

And it's not just the compiler, the linker didn't even know if a package is used or not, which is why you have to manually remove unused imports (otherwise they would be linked in, bloating the binary).

Re: Go 1.5 Beta

#32

Post by Twirrim »

melling wrote: post #22
vruiz wrote: post #20

Earlier quoted context omitted.

2x is still means much faster than C++. Go has an strict release cycle[0] and at some point you have to make the switch if you want a compiler easier to develop. I'm sure it'll get much better soon. https://github.com/golang/go/wiki/Go-Release-Cycle

Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers. http://commandcenter.blogspot.it/2012/06/less-is-exponential... Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.

How often do you compile a code versus run it? Particularly in cases where speed matters?

Re: Go 1.5 Beta

#33

Post by stcredzero »

pcwalton wrote: post #13
stcredzero wrote: post #9

Earlier quoted context omitted.

For high concurrency systems, I'd expect false sharing to start rearing its ugly head. I only recently got knocked over the head with -race by the oh-so-diplomatic folks on IRC. It's very good. Might as well use it -- otherwise it's like driving with a broken check engine light. Speaking of false sharing, would it be a good idea to take the Go implementation of Disruptor and use that for buffered channels?

> For high concurrency systems, I'd expect false sharing to start rearing its ugly head. I'd be really surprised if that results in programs in parallel mode becoming slower than sequential (which is what you get with GOMAXPROCS=1). Cache effects are important, but not that important in a setting like Go, where few people use concurrent read-write data structures anyway (other than channels, of course) due to the lac…

I'd be really surprised if that results in programs in parallel mode becoming slower than sequential

I'm going to guess that you haven't played too much with executing things in parallel? In Clojure groups, people have heard beginners express surprise about parallel mode programs running slower so often, it's somewhat shaped the reaction to such questions.

few people use concurrent read-write data structures anyway (other than channels, of course)

One can still get in trouble with channels of pointers to structs.

Much more likely is that some programs become slower due to the fact that GOMAXPROCS>1 requires more locks and atomic operations. That's not false sharing,

Depending on how the locks and atomic operations are implemented and used, the slowdown with locks and atomic operations could be in large part because of false sharing. (I don't know the details for Go.)

Re: Go 1.5 Beta

#34

Post by enneff »

zzzcpan wrote: post #21

Wrong binaries in go1.5beta1.linux-386.tar.gz, don't work on linux 386. Looks like they are for amd64.

Thanks for the report. We're using a new tool to roll the release binaries, and you have discovered a bug. On it.

Re: Go 1.5 Beta

#35

Post by kodablah »

dvirsky wrote: post #19
shazow wrote: post #16

Earlier quoted context omitted.

The closest thing to documentation is still the design document: https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh... I've been playing around with it, here's a neat example that does shared library partial bindings for http.Server in C and Python: https://github.com/shazow/gohttplib

Is it possible to dynamically load libraries that have been compiled with -buildmode=shared in runtime from within a running Go program? The design doc talked about it IIRC.

According to the release notes [1], "For the amd64 architecture only, the compiler has a new option, -dynlink, that assists dynamic linking by supporting references to Go symbols defined in external shared libraries."...so I assume if you want all of your Go signatures visible in your shared Go libraries, you can do it on x64. I have not tested this myself.

1 - https://tip.golang.org/doc/go1.5#compiler

Re: Go 1.5 Beta

#36

Post by enneff »

enneff wrote: post #34
zzzcpan wrote: post #21

Wrong binaries in go1.5beta1.linux-386.tar.gz, don't work on linux 386. Looks like they are for amd64.

Thanks for the report. We're using a new tool to roll the release binaries, and you have discovered a bug. On it.

It's now updated. Please download the new file (sha1 70112cca6a7225bacac4a32ffab2d97bcd7613f4) and confirm that it works for you.

Re: Go 1.5 Beta

#37

Post by tomjakubowski »

stcredzero wrote: post #33
pcwalton wrote: post #13

Earlier quoted context omitted.

> For high concurrency systems, I'd expect false sharing to start rearing its ugly head. I'd be really surprised if that results in programs in parallel mode becoming slower than sequential (which is what you get with GOMAXPROCS=1). Cache effects are important, but not that important in a setting like Go, where few people use concurrent read-write data structures anyway (other than channels, of course) due to the lac…

I'd be really surprised if that results in programs in parallel mode becoming slower than sequential I'm going to guess that you haven't played too much with executing things in parallel? In Clojure groups, people have heard beginners express surprise about parallel mode programs running slower so often, it's somewhat shaped the reaction to such questions. few people use concurrent read-write data structures anyway (…

> I'm going to guess that you haven't played too much with executing things in parallel? In Clojure groups, people have heard beginners express surprise about parallel mode programs running slower so often, it's somewhat shaped the reaction to such questions.

pcwalton is one of the lead engineers of Servo, a Mozilla Research project to develop a more parallelizable browser engine in Rust. I'd say he's played around quite a bit with executing things in parallel!

https://github.com/servo/servo

Re: Go 1.5 Beta

#38

Post by melling »

Twirrim wrote: post #32
melling wrote: post #22

Earlier quoted context omitted.

Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers. http://commandcenter.blogspot.it/2012/06/less-is-exponential... Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.

How often do you compile a code versus run it? Particularly in cases where speed matters?

Why do you think projects like LightTable and Apple's Playgrounds exist?

http://www.chris-granger.com/2012/02/26/connecting-to-your-c...

http://www.objc.io/issues/16-swift/rapid-prototyping-in-swif...

Rapid prototyping doesn't work as well if you need wait for compilation.

JRebel exists for Java to improve redeployment times:

http://zeroturnaround.com/software/jrebel/

Re: Go 1.5 Beta

#39

Post by habosa »

I'm excited to see experimental support for vendoring. One nice thing about go is that the dependency management is part of the core language design, but it always fell flat when you needed specific versions of a library. Vendoring solves that huge issue, I hope it works as nicely as they claim.

Re: Go 1.5 Beta

#40

Post by mitchellh »

tirus wrote: post #15

Has anyone spotted the documentation for the new shared library system yet? Plugin-based architecture is one of the biggest things I've wanted in Go and it seems to finally be happening.

I played around with this on my own, and the shared library system will only work with Linux binaries for now. I wasn't able to get it working with OS X or Windows, with the very clear message from Go telling me the "platform target is not supported."

I think it is mostly a getting started point, and not generally useful unless your only target is Linux (which very likely may be the case unless you're working on desktop apps).

Post reply on HN