[go-nuts] Buffered Channel's Performance

Typo: I've [been] benchmarking / I give [ large numbers ]

are you turning on multiprocessor support?


ie runtime.GOMAXPROCS(runtime.NumCPU())

without it they are still done, underneath, one after another

Yes, the full code is here. http://play.golang.org/p/8OAbtn6koN

And for benchmarking, like the following link

http://play.golang.org/p/JK3yL4QwOJ


It goes like this

var resultchSumBuffer int

func BenchmarkchSumBuffer(b *testing.B) {
runtime.GOMAXPROCS(runtime.NumCPU())
var r int
for i := 0; i < b.N; i++ {
sum, _ := chSumBuffer(2000000)
r = sum
}
resultchSumBuffer = r
}

Don't do it like that, use

go test -bench=. -cpu=1,2,4

Thanks, Dave!

Yes, because buffered channels don't wait, so u should see some performance
increase
when using it.(but it might not alway be true it depends on what your code
is doing)

Thanks, I might keep looking for the example, since mine is not really
showing the performance increase with buffered channel.

you might not see it with small code
check this code out, http://play.golang.org/p/dmVkMnmioL
run it yourself

Thanks, I will play around with your code. Great.

http://play.golang.org/p/Ki8Xz9InM1

"note when is not buffered there is only one name"

But as long as we make sure close the channel, unbuffered channel also can
contain all 7 strings. Look at my example.
  Thanks

Lee don't forget channel block, so on line 12 of your implementation
when you send into the channel it blocks for it to be read.

Waiting isn't a problem if you've got something else to do while you wait.
I'm currently waiting for the kettle to boil and writing this email.
If the kettle boiled instantly, I'd still be writing this email and I'd
still complete the email and drink my coffee in the same amount of time.

Hello,
What exactly are you trying to measure?

The difference between unbuffered and buffered channels is that with a
buffered channel, the sender does not block even if the receiver is
not ready to receive, unless the buffer is full.

In this example, each goroutine exits directly after sending. Moreover,
the receiver is always ready, because it does not expect the messages
in a specific order. Thus, changing from unbuffered to buffered channels
makes no difference for the performance of the example.

As the example splits up the sum calculation into two goroutines, setting
-cpu=2 (or higher) should be faster than 1, if you system has 2 or more
cpu cores. However, the most cpu time is spent in the creation of the
slice, which is non-parallelized.
Consider a program witch works on jobs in a pipeline. Each job has to run
through each step of the pipeline sequentially. The pipeline steps are
implemented as goroutines, and the jobs are submitted through channels.
Each step take the same time in average, but time varies from job to job.

With unbuffered channels, a pipeline step must wait for the next step
to become ready, and cannot work on the next job in the meantime. Buffered
channel allow to store intermediate results in the buffer, which leads
to a better utilization in summary.

See http://play.golang.org/p/5PVZfaq4-m for an example implementation with
3 pipeline steps, which take between 0 and 100 milliseconds for each step.
The program runs measurably faster when "make(chan int)" is replaced by e.g.
"make(chan int, 10)".

(You need to execute the program locally, because of the playgrounds
cache.)

Harald

Thanks, yes you are right. My code spends too much resource creating slice.
I just wanted to see whether the NON-blocking of buffered channel performs
faster than unbuffered channel that has blocking.

Thanks for the code. I am playing around it right now and seems like
working as I expected.