FAQ
I've benchmarking this go tour example with buffered channel.

http://tour.golang.org/#64

The original example goes like this.

     c := make(chan int)
     go sum(a[:len(a)/2], c)
     go sum(a[len(a)/2:], c)
     x, y := <-c, <-c



And for my benchmarking, I give a large numbers with rand package. And try
to compare this unbuffered channel with buffered one.
My buffered channel would be like this so that when another goroutine tries
to send, it does not block.

     c := make(chan int, 2)
     go sum(a[:len(a)/2], c)
     go sum(a[len(a)/2:], c)
     x, y := <-c, <-c


Doesn't it mean that buffered channel should perform faster than unbuffered
because there is no wait-time that is blocking?

It is hard to find a concrete example of benefit of using buffered channels.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Gyu-Ho Lee at Dec 1, 2013 at 9:34 pm
    Typo: I've [been] benchmarking / I give [ large numbers ]

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Simon place at Dec 1, 2013 at 10:41 pm
    are you turning on multiprocessor support?


    ie runtime.GOMAXPROCS(runtime.NumCPU())

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


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gyu-Ho Lee at Dec 1, 2013 at 10:49 pm
    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
    }


    On Sunday, December 1, 2013 2:41:54 PM UTC-8, simon place wrote:

    are you turning on multiprocessor support?


    ie runtime.GOMAXPROCS(runtime.NumCPU())

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

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Dec 1, 2013 at 11:05 pm

    On Mon, Dec 2, 2013 at 9:49 AM, Gyu-Ho Lee wrote:
    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())
    Don't do it like that, use

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

    var r int
    for i := 0; i < b.N; i++ {
    sum, _ := chSumBuffer(2000000)
    r = sum
    }
    resultchSumBuffer = r
    }


    On Sunday, December 1, 2013 2:41:54 PM UTC-8, simon place wrote:

    are you turning on multiprocessor support?


    ie runtime.GOMAXPROCS(runtime.NumCPU())

    without it they are still done, underneath, one after another
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gyu-Ho Lee at Dec 1, 2013 at 11:14 pm
    Thanks, Dave!
    On Sunday, December 1, 2013 3:05:29 PM UTC-8, Dave Cheney wrote:
    On Mon, Dec 2, 2013 at 9:49 AM, Gyu-Ho Lee wrote:
    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())
    Don't do it like that, use

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

    var r int
    for i := 0; i < b.N; i++ {
    sum, _ := chSumBuffer(2000000)
    r = sum
    }
    resultchSumBuffer = r
    }


    On Sunday, December 1, 2013 2:41:54 PM UTC-8, simon place wrote:

    are you turning on multiprocessor support?


    ie runtime.GOMAXPROCS(runtime.NumCPU())

    without it they are still done, underneath, one after another
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Felixzilla at Dec 1, 2013 at 10:58 pm
    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)

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gyu-Ho Lee at Dec 1, 2013 at 11:03 pm
    Thanks, I might keep looking for the example, since mine is not really
    showing the performance increase with buffered channel.
    On Sunday, December 1, 2013 2:56:20 PM UTC-8, felix...@gmail.com wrote:

    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)
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Felixzilla at Dec 1, 2013 at 11:16 pm
    you might not see it with small code
    check this code out, http://play.golang.org/p/dmVkMnmioL
    run it yourself
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gyu-Ho Lee at Dec 1, 2013 at 11:22 pm
    Thanks, I will play around with your code. Great.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gyu-Ho Lee at Dec 1, 2013 at 11:31 pm
    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
    On Sunday, December 1, 2013 3:16:47 PM UTC-8, felix...@gmail.com wrote:

    you might not see it with small code
    check this code out, http://play.golang.org/p/dmVkMnmioL
    run it yourself
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Felixzilla at Dec 1, 2013 at 11:41 pm
    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.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jesse McNelis at Dec 1, 2013 at 11:20 pm

    On Mon, Dec 2, 2013 at 9:56 AM, wrote:

    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)
    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.

    --
    =====================
    http://jessta.id.au

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Harald Weidner at Dec 2, 2013 at 12:16 am
    Hello,
    I've benchmarking this go tour example with buffered channel.
    http://tour.golang.org/#64
    Doesn't it mean that buffered channel should perform faster than unbuffered
    because there is no wait-time that is blocking?
    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.
    It is hard to find a concrete example of benefit of using buffered channels.
    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

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gyu-Ho Lee at Dec 2, 2013 at 12:23 am
    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.
    On Sunday, December 1, 2013 4:16:45 PM UTC-8, Harald Weidner wrote:

    Hello,
    I've benchmarking this go tour example with buffered channel.
    http://tour.golang.org/#64
    Doesn't it mean that buffered channel should perform faster than
    unbuffered
    because there is no wait-time that is blocking?
    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.
    It is hard to find a concrete example of benefit of using buffered
    channels.

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 1, '13 at 9:24p
activeDec 2, '13 at 12:23a
posts15
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase