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.
On Friday, February 19, 2021 at 11:37:39 PM UTC+8 meera wrote:
> You can find what's the difference between th
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
On Fri, 19 Feb 2021, 11:46 Yuwen Dai,
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
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 1?)
On Fri, Feb 19, 2021 at 9:46 AM Yuwen Dai wrote:
> Hi experts,
>
> I'm a newbie to go
On Fri, Feb 19, 2021 at 6:46 AM Yuwen Dai wrote:
>
> 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
> goroutin
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 :
