You might not be able to get a cycle-by-cycle accounting, but with unlimited effort, you *can* get pretty darn close. Of course, that effort is usually not worth it. However, what you can always do, which is really the very first step to understand a benchmark result and attempt a micro-optimization like this, is look at the generated code and/or an actual CPU profile to see what the difference in generated code is (it might be none, in which case it's "spooky architecture action at a distance") and what the difference is where the generated code spends its time.
If you've done that, i would've expected you to share your insights. If you haven't done it, it seems rude to skip that step and expect people on golang-nuts to do it for you, if I'm being honest. That is why I'm a bit frustrated with these threads, personally. It's not that they are boring questions - in fact, I'd probably enjoy listening to a talk or reading an extensive blog post answering them very much. It's that you seem to generate arbitrary benchmarks and then ask other people to do the work of interpreting them for you. In any case, all I was trying to say by pointing out the power of two is that that's the least surprising boundary for something to change. Whether it's allocation-details (apparently unlikely) or just some other optimization heuristic rolling over or whether it is some architectural detail like cache-sizes mattering. Which of these it is, I don't know either - but I'm not surprised enough to find out. On Wed, Jul 28, 2021 at 8:34 PM tapi...@gmail.com <tapir....@gmail.com> wrote: > > > On Wednesday, July 28, 2021 at 1:47:44 PM UTC-4 axel.wa...@googlemail.com > wrote: > >> On Wed, Jul 28, 2021 at 7:30 PM tapi...@gmail.com <tapi...@gmail.com> >> wrote: >> >>> I think this one is different from previous. I don't criticize Go, I >>> just seek reasons. >>> >> >> Implying that previously you've been criticizing Go? >> > > Sorry, my English is always not decent. > > >> >> As for your search for reasons: 16384 is a power of two. So I assume that >> what changes is that an allocation enters a new size-class, which uses a >> different algorithm for allocation. Or something along those lines. >> > > Yes, 16384+16384= 32768 and 16385+16384= 32769. > 32768 bytes will be allocated on a memory block in the 32768 size class, > which is the largest size class. > 32769 bytes will be allocated on 5 pages (each page is 8192 bytes). > > But the implementations of Insert and Insert2 are very similar, > the allocation algorithms for them should be the same (for a specified > number). > So it is weird the number change causes positive impact for one > implementation,effect > but negative impact for the other. > > Maybe, it is still a CPU related mystery. > > >> >> >>> >>> On Wednesday, July 28, 2021 at 11:44:13 AM UTC-4 Brian Candler wrote: >>> >>>> I think you have created rather a lot of threads recently on exactly >>>> the same topic: >>>> https://groups.google.com/g/golang-nuts/search?q=tapi%20benchmark >>>> >>>> I'm not convinced that another one is needed. There have been good >>>> answers in the previous threads. >>>> >>>> Go has a fairly complex runtime (as you'll see from the size of >>>> compiling "Hello world"), and such boundary conditions are to be expected, >>>> especially when looking at memory allocation. But these rarely matter in >>>> real-world programs. >>>> >>>> If they do matter in your application, then you may be happier with a >>>> language like C, where the machine-code generated maps more directly to the >>>> code you write. Even then, you will come across oddities in the >>>> microarchitectures of the underlying hardware, such as what happens when >>>> caches are under eviction pressure. >>>> >>>> When I was programming 6800's and 6502's, I was able to work out >>>> exactly how long a piece of code would take to run, by generating a >>>> cycle-by-cycle count. That's not possible any more :-) >>>> >>>> On Wednesday, 28 July 2021 at 15:43:38 UTC+1 tapi...@gmail.com wrote: >>>> >>>>> >>>>> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp >>>>> >>>>> When N == 16384, the benchmark result: >>>>> >>>>> Benchmark_Insert-4 134622 8032 ns/op 32768 >>>>> B/op 1 allocs/op >>>>> Benchmark_Insert2-4 132049 8201 ns/op 32768 >>>>> B/op 1 allocs/op >>>>> >>>>> When N == 16385, the benchmark result: >>>>> >>>>> Benchmark_Insert-4 118677 9374 ns/op >>>>> 40960effect B/op 1 allocs/op >>>>> Benchmark_Insert2-4 136845 7744 ns/op 40960 >>>>> B/op 1 allocs/op >>>>> >>>> -- >>> 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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/2c217862-84b7-4bff-a48a-06810848bcf4n%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/2c217862-84b7-4bff-a48a-06810848bcf4n%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/fdc4786d-b844-4b33-9a32-7b4ebb027ff9n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/fdc4786d-b844-4b33-9a32-7b4ebb027ff9n%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/CAEkBMfHhDK221zQ2YcA8Bvzo%3Dz4oHY4FV8-38znX7gmR%3DQZJ%2Bw%40mail.gmail.com.
