A goroutine question

[Yuwen Dai]

Hi experts,

I'm a newbie to golang.  One of my first ideas to use goroutine is to write a matrix multiplying programme:  C = A*B.    I though the calculating of  every element of C:  c[i][j] = row i of A  *  column j of B could be run by a goroutine.  This is the skeleton of the code:

    t1 := time.Now().UnixNano()  //benchmark
    rand.Seed(t1)
    for i := 0; i < n; i++ {
        ai,_ := get_row(a,i)
        for j := 0; j < t; j ++ {
            bj, _ := get_column(b,j)
            //        c[i][j],_ = dot_product(ai, bj)
            go func(element *int, ai,bj []int) {
                *element,_ = dot_product(ai,bj)
                wg.Done()
            }(&c[i][j], ai, bj)
        }
    }

    wg.Wait()  // waiting for all the elements have been calculated
    t2 := time.Now().UnixNano()
    fmt.Printf("the dot_product using goroutine costs %v\n", t2 - t1)

As the goroutines will run "concurrently" on my laptop with 8 CPU cores to calculate the element of matrix, I thought the code would ran faster than not using goroutine.  In fact, it ran slowlier than not using goroutine.  Any explanation of this?    By the way,  the dimension of  matrix is 100x100. 

Best regards,

Yuwen

[Ian Lance Taylor]

Goroutines are lightweight but they are not free. On the other hand,
modern CPUs do simple additions and multiplications very quickly. The
cost of starting and waiting for a goroutine is larger than the cost
of a few multiplications. Your goroutine version might run faster if
the matrix is very very very large, but for practical matrixes it will
be faster to do just do the arithmetic sequentially.

Ian

[Peter Weinberger (温博格)]

A 100-long vector is way too short to show any benefit. goroutines have start-up, scheduling, and shut-down costs. What happens if you try to square the largest matrix you can fit into memory (10,000 by 10000?)

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/52ef6c0f-7044-4b7e-968c-b894eb52d374n%40googlegroups.com.

[Robert Engels]

For parallelizing code like this, you will probably see better performance by having each routine process a full row rather than a cell. You amortize the overhead better. 

Still the matrix is probably too small to make a difference. 

On Feb 19, 2021, at 8:56 AM, 'Peter Weinberger ' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOUkXSpvBq9ctKGwXC4VHT-xfBm2j4vsODnYgUgeO_ivbG-uSw%40mail.gmail.com.

[Artur Vianna]

You can find what's the difference between the two programs yourself by profiling it, it will show the overhead of context switch, goroutine initialization, GC and so forth.

Heres some good resources:

https://blog.golang.org/pprof

https://youtu.be/nok0aYiGiYA

--

[Yuwen Dai]

After I increase the dimension of matrixes to 1000x1000,  the advantage of goroutines appears:  using goroutines takes shorter time than not using them.   Thanks for all your comments.