For the record, this is the main issue that's stopping me using a slightly more sophisticated algorithm in github.com/rogpeppe/fastuuid that avoids significant overhead when UUID generation is contended.

CC @aclements

These results actually indicate that sync.Pool is scaling basically perfectly and saturating the CPU pipeline (assuming you have two 2-way hyperthreaded cores).

The way parallel benchmark results are reported is frustratingly confusing. It's not reporting CPU-ns/op, it's reporting wall-ns/op. For example, suppose each op takes exactly 100 ns, regardless of parallelism. If the single-threaded benchmark runs for 1 sec, it will execute 10,000,000 ops, so ns/op = 1s/10,000,000 ops = 100 ns/op. But if the same benchmark runs 4-way parallel for 1 sec, it will execute 40,000,000 ops, so ns/op = 1s/40,000,000 = 25 ns/op. (I really wish it didn't work this way...)

Your results only differ by a factor of 2 rather than 4 because of hyperthreading. Since the benchmark is highly predictable and obviously stays within the cache, there are probably basically no pipeline stalls (though I didn't measure this to confirm), so you really only get 2x parallelism. For example, when I run with -cpu 1,4 on a six core 2-way hyperthreaded machine I get:

perflock /tmp/test.test -test.bench . -test.cpu 1,4
goos: linux
goarch: amd64
BenchmarkPool       	63292490	        18.7 ns/op
BenchmarkPool-4     	250416594	         4.70 ns/op

4.70 * 4 = 18.8, indicating perfect scalability.

I'm going to go ahead and close this, but feel free to follow up.

The way parallel benchmark results are reported is frustratingly confusing. It's not reporting CPU-ns/op, it's reporting wall-ns/op. For example, suppose each op takes exactly 100 ns, regardless of parallelism. If the single-threaded benchmark runs for 1 sec, it will execute 10,000,000 ops, so ns/op = 1s/10,000,000 ops = 100 ns/op. But if the same benchmark runs 4-way parallel for 1 sec, it will execute 40,000,000 ops, so ns/op = 1s/40,000,000 = 25 ns/op. (I really wish it didn't work this way...)

OK, I wondered if it was something like that. So "op" in this case does not mean "1 operation that I'm testing takes time $T", but "1 operation that I'm testing takes time ($T * $NCPU)", so the numbers in different -cpu results aren't comparable without scaling them first.

That is definitely somewhat confusing. Is it documented somewhere? (I scanned through go help testflag and https://golang.org/pkg/testing/). Perhaps it should be called out explicitly in https://golang.org/pkg/testing/#hdr-Benchmarks ?

Thanks for the quick response BTW.

That's right.

I don't think this is documented anywhere. I've opened #31884 about the documentation issue.