On Wednesday, July 28, 2021 at 4:15:38 PM UTC-4 axel.wa...@googlemail.com wrote:
> 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. > I will when I confirm that no one could give an answer without much effort. If you feel frustrated, you can ignored it. ;D > 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 <tapi...@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...@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/91ae2f06-2d77-46d5-b09f-ea3cf9a57ed0n%40googlegroups.com.
