I believe it is save to say, even without other benchmarks, that a) you are correct that the cost is "unpredictable"¹ and b) that will always be the case. The compiler will always chose different strategies for differently sized values and if not that, the architecture of computers will have different timing characteristics (based on cache sizes, number of registers…) for differently sized values. This does not constitute a problem. So it seems like a waste of everybody's time (yours included, but you're of course free to spend it however you like) to try and determine where these thresholds lie using blackbox benchmarks.
[1] You really just say it doesn't depend lineally on size. But if it actually was unpredictable, it would vary significantly for the same value. All you've shown is that the prediction is more complicated than "Size in bytes times some time interval". On Sun, May 30, 2021 at 7:10 AM tapi...@gmail.com <tapir....@gmail.com> wrote: > > > On Sunday, May 30, 2021 at 12:28:55 AM UTC-4 Kurtis Rader wrote: > >> On Sat, May 29, 2021 at 8:50 PM tapi...@gmail.com <tapi...@gmail.com> >> wrote: >> >>> The benchmark code: https://play.golang.org/p/bC1zO14eNeh >>> >> ... >>> >> From the benchmark result, it looks >>> * the cost of copying a [13]int value is much larger than copying a >>> [12]int value. >>> * the cost of copying a struct{a, b, c int} value is about double of >>> copying a struct{a, b, c, d int} value. >>> >> >> The size, and internal layout, of structs has a huge effect on these >> types of benchmarks due to the interaction with the L1 and L2 caches and >> the CPU architecture policies for the management of those caches. Thus >> this type of benchmark needs to document the CPU architecture being used >> and also the results on other architectures. It would not be at all >> surprising if changing the implementation to improve the results on your >> system resulted in slower behavior on other systems. >> > > I agree. > > Could someone post the benchmark results on different architectures other > than Intel(R) Core(TM) i5-3210 to make comparisons? > > >> >> -- >> Kurtis Rader >> Caretaker of the exceptional canines Junior and Hank >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/6d32d796-513f-40b6-b5d2-a1e54f4d1d25n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/6d32d796-513f-40b6-b5d2-a1e54f4d1d25n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFr7Kf9BW0d-vvmAUU8aghu9d60nc8EGLFCb4Ap-T_Paw%40mail.gmail.com.
