On Tue, May 16, 2017 at 4:59 AM, Manish Rai Jain <manishrj...@gmail.com> wrote: > > 3 is slower than 2 (of course). But, 2 is never able to achieve the IOPS > that Fio can achieve. I've tried other things, to no luck. What I notice is > that Go and Fio are close to each other as long as number of Goroutines is > <= number of cores. Once you exceed cores, Go stays put, while Fio IOPS > keeps on improving, until it reaches SSD thresholds.
One thing I notice about your program is that each goroutine is calling rand.Intn and rand.Int63n. Those functions acquire and release a lock, so that single lock is being contested by every goroutine. That's an unfortunate and unnecessary slowdown. Give each goroutine its own source of pseudo-random numbers by using rand.New. You also have a point of contention on the local variable i, which you are manipulating using atomic functions. It would be cheaper to give each goroutine a number of operations to do rather than to compute that dynamically using a contended address. I'll also note that if a program that should be I/O bound shows a behavior change when the number of parallel goroutines exceeds the number of CPUs, then it might be interesting to try setting GOMAXPROCS to be higher. I don't know what effect that would have here, but it's worth checking. Ian -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
