concurrency - Goroutine execution time with different input data -

concurrency - Goroutine execution time with different input data -

i experimenting goroutine parallelizing computation. however, execution time of goroutine confuse me. experiment setup simple.

runtime.gomaxprocs(3) datalen := 1000000000 data21 := make([]float64, datalen) data22 := make([]float64, datalen) data23 := make([]float64, datalen) t := time.now() res := make(chan interface{}, dlen) go func() { := 0; < datalen; i++ { data22[i] = math.sqrt(13) } res <- true }() go func() { := 0; < datalen; i++ { data22[i] = math.sqrt(13) } res <- true }() go func() { := 0; < datalen; i++ { data22[i] = math.sqrt(13) } res <- true }() i:=0; i<3; i++ { <-res } fmt.printf("the parallel loop took %v run.\n", time.since(t))

notice loaded same info in 3 goroutines, execution time programme

the parallel loop took 7.436060182s run.

however, if allow each goroutine handle different info follows:

runtime.gomaxprocs(3) datalen := 1000000000 data21 := make([]float64, datalen) data22 := make([]float64, datalen) data23 := make([]float64, datalen) t := time.now() res := make(chan interface{}, dlen) go func() { := 0; < datalen; i++ { data21[i] = math.sqrt(13) } res <- true }() go func() { := 0; < datalen; i++ { data22[i] = math.sqrt(13) } res <- true }() go func() { := 0; < datalen; i++ { data23[i] = math.sqrt(13) } res <- true }() i:=0; i<3; i++ { <-res } fmt.printf("the parallel loop took %v run.\n", time.since(t))

the execution time 3 times more previous , equal/worse sequential execution without goroutine

the parallel loop took 20.744438468s run.

i guess maybe utilize goroutine in wrong way. should right way utilize multiple goroutines handle different pieces of data;

since illustration programme not performing substantial calculation, bottleneck going speed @ info can written memory. settings in example, we're talking 22 gb of writes not insignificant.

given time difference in run time of 2 examples, 1 possibility isn't writing much ram. given memory writes cached cpu, execution looks this:

the first goroutine writes out info cache line representing start of data22 array. the sec goroutine writes out info cache line representing same location. cpu running first goroutine notices write invalidates own cached write, throws away changes. the 3rd goroutine writes out info cache line representing same location. cpu running sec goroutine notices write invalidates own cached write, throws away changes. the cache line in 3rd cpu evicted , changes written out ram.

this process continues goroutines progress through data22 array. since ram bottleneck , end writing 1 3rd much info in scenario, isn't surprising runs approximately 3 times fast sec case.

concurrency go goroutine