On Fri, Jul 24, 2015 at 9:09 AM, sky <
yao20...@gmail.com> wrote:
>
> I noticed the Go 1.5 will change the default to the number of the CPUs
> available. link. I am interest in that Chain benchmark which gets a
> degradation when having more threads. But I can't find the source code of
> that benchmark. Could anyone send me a copy or a link of this benchmark?
As it suggests in the appendix, you can get the benchmark sources via
"go get
rsc.io/tmp/gomaxprocs/...". It may complain about a lack of
buildable Go source files, but you should see the files in your
GOPATH.
> Another question is about the reason of the degradation. Is it because this
> benchmark is an intrinsic sequential program? Is there any other reason?
It's an intrinsically sequential benchmark that uses lots of
goroutines, so scheduling overhead dominates run time. Scheduling
overhead is higher with more GOMAXPROCS, because the different
processors collide with each other when deciding what to do next. In
a normal program, in which the goroutines can run independently, the
benefit of goroutines running in parallel greatly outweighs the
scheduling cost. In a program like the chain benchmark, the
goroutines can't run in parallel, so the extra scheduling time shows
up. As the paper shows, the overhead is not too bad in Go 1.5.
Ian