I didn't see it as criticism of go. However you're looking at
micro-behaviour which has little relevance to the real world, and hence not
of interest to most go programmers.
Compilers and runtimes contain heuristics, such as "if I grow a
slice/map/whatever beyond size X, then increase it to size Y". These are
necessary because the runtime cannot see the future: it doesn't know how
many times you're going to keep growing the same object, and it would be
inefficient to keep growing the same object by the minimum amount
possible. Memory management may say "if an object is larger than A, then
round it up to a multiple of B" to avoid memory fragmentation.
Therefore, you should expect the implementation to have behaviour like
this, which is designed to work well in the majority of use cases, most of
the time. In other words, what you see ("small number change will affect
benchmark results") is normal and unremarkable.
On Wednesday, 28 July 2021 at 18:30:09 UTC+1 tapi...@gmail.com wrote:
> I think this one is different from previous. I don't criticize Go, I just
> seek reasons.
>
> 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 40960
>>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/8a94a375-128e-4050-80b2-ac3732b4eaa4n%40googlegroups.com.
