11–20 of 82 posts
These are pretty big to me: The garbage collector is now concurrent and provides dramatically lower pause times by running, when possible, in parallel with other goroutines. By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1. But how important is this? It doesn't seem like it affects the average user: The compiler and runtime are now written entirely…
These are pretty big to me: The garbage collector is now concurrent and provides dramatically lower pause times by running, when possible, in parallel with other goroutines. By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1. But how important is this? It doesn't seem like it affects the average user: The compiler and runtime are now written entirely…
Earlier quoted context omitted.
With the new scheduler I believe this is much less of an issue. It is huge though because there might be a bunch of data races in the wild that were hidden until now and are about to see the light of day. Hopefully most people test with -race these days.
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?
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 lack of generics.
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, though; that's just synchronization overhead.
Earlier quoted context omitted.
With the new scheduler I believe this is much less of an issue. It is huge though because there might be a bunch of data races in the wild that were hidden until now and are about to see the light of day. Hopefully most people test with -race these days.
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?
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'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
These are pretty big to me: The garbage collector is now concurrent and provides dramatically lower pause times by running, when possible, in parallel with other goroutines. By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1. But how important is this? It doesn't seem like it affects the average user: The compiler and runtime are now written entirely…
So, that more complex garbage collector is a product of that less-sexy rewrite.
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
This seems quite a drastic change. I thought compilation speed was one of the pilars of go. In that light, why did they decide to release this anyway?
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.
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
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…