On Wed, Jul 28, 2021 at 7:30 PM tapi...@gmail.com <tapir....@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?

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.


>
> 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/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/CAEkBMfEGj-B%3DA0ncSyoFOU6Wu9n9tj996zY-nB-ez92m_jxthQ%40mail.gmail.com.

Reply via email to