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

41–50 of 82 posts

Re: Go 1.5 Beta

#41

Post by pcwalton »

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 think you're overstating how much false sharing in particular causes parallel slowdowns. In the case of Clojure, for example, it's probably just straightforward synchronization overhead (cost of atomic ops), just as it is in Go.

False sharing is a very specific type of synchronization problem whereby data tightly packed in memory gets shared between multiple processors because the cache line size is larger than desired, even though logically the data in question are completely independent. This can happen, but it's nowhere near the most common type of synchronization-related performance problem in my experience. If your problem actually needs to share the data between multiple processors (e.g. with Go channels), then it's not "false" sharing anymore—it's "true" sharing.

Re: Go 1.5 Beta

#42

Post by pcwalton »

buerkle wrote: post #30
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…

What does lack of generics have to do with concurrent vs non-concurrent data structures? It seems like if the problem calls for it, concurrent data structures would be used regardless of generics.

Concurrent data structures (especially lock-free data structures) are really hard to write. Specializing e.g. a lock-free FIFO stack to each type you want to use it with isn't feasible in practice. It's much easier to just protect a built-in slice or map with a mutex, and that's what I believe Go code generally does.

Re: Go 1.5 Beta

#43

Post by zackbloom »

bsdetector wrote: post #31
melle wrote: post #18

Earlier quoted context omitted.

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 p…

This is the nature of a priority. They are saying they value compilation speed more than the maintainers of C might, and are willing to sacrifice other things (like runtime speed) in that interest.

Re: Go 1.5 Beta

#44

Post by binarycrusader »

Of particular note, Solaris support in Go 1.5 is greatly improved thanks to the work of Aram Hăvărneanu; Oracle sponsored most of that work.

Notably, cgo is now supported on Solaris as of Go 1.5 beta.

The same should hold true of various OpenSolaris-based distributions such as Illumos, et al.

Re: Go 1.5 Beta

#45

Post by zzzcpan »

enneff wrote: post #36
enneff wrote: post #34

Earlier quoted context omitted.

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.

It works now. Thanks. Even tried cross-compilation, works too.

Re: Go 1.5 Beta

#46

Post by dragonwriter »

buerkle wrote: post #30
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…

What does lack of generics have to do with concurrent vs non-concurrent data structures? It seems like if the problem calls for it, concurrent data structures would be used regardless of generics.

> What does lack of generics have to do with concurrent vs non-concurrent data structures?

Generics allow building reusable forms of complex data structures, reducing the cost in developer effort of each specialized use. By not supporting generics, Go increases the cost of each specialized use of complex data structures, which narrows the range of circumstances where the cost will be justified by the benefit.

Whether or not "the problem calls for it" is always a cost vs. benefit question, and Go -- compared to languages with support for generics -- increases the cost of this particular solution.

Re: Go 1.5 Beta

#47

Post by tyho »

bsdetector wrote: post #31
melle wrote: post #18

Earlier quoted context omitted.

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 p…

This is plain wrong, the main reason the compiler is fast according to the authors[1] is because it handles dependencies more sanely than C/C++.

https://talks.golang.org/2012/splash.article

Re: Go 1.5 Beta

#48

Post by codemac »

tyho wrote: post #47
bsdetector wrote: post #31

Earlier quoted context omitted.

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 p…

This is plain wrong, the main reason the compiler is fast according to the authors[1] is because it handles dependencies more sanely than C/C++. https://talks.golang.org/2012/splash.article

You're more than welcome to write C in the fashion that the go compiler enforces, and get much faster builds. Their compiler is young and immature relative to things like GCC and stating that it may be missing expensive optimization features is not "plain wrong".

Re: Go 1.5 Beta

#49

Post by peterfirefly »

melling wrote: post #25
vruiz wrote: post #24

Earlier quoted context omitted.

The compilation time is slower, not the resulting compiled binary. > On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5 than they did in Go 1.4, while as mentioned above the garbage collector's pauses are dramatically shorter, and almost always under 10 milliseconds.

I'm referring to compilation speed. In Python and Ruby, for example, there is no compile stage. This makes them attractive for rapid iteration.

There is a compilation-to-bytecode stage + lots of file look ups during start up of the Python interpreter and during every module import.
Post reply on HN