This is fixed in https://go-review.googlesource.com/c/go/+/359477
The benchmarks become much less weird. https://play.golang.org/p/leXp-8MB6gi
On Wednesday, August 18, 2021 at 11:35:05 PM UTC-4 tapi...@gmail.com wrote:
> More specifically, the last parameter (needzero) of mallocgc is not passed
The PR: https://github.com/golang/go/pull/47804
On Wednesday, August 18, 2021 at 11:35:05 PM UTC-4 tapi...@gmail.com wrote:
> More specifically, the last parameter (needzero) of mallocgc is not passed
> down to c.nextFree, which causes the memclrNoHeapPointers function is
> called twice in
More specifically, the last parameter (needzero) of mallocgc is not passed
down to c.nextFree, which causes the memclrNoHeapPointers function is
called twice in makeslicecopy if the slice size <= 32768.
On Wednesday, August 18, 2021 at 11:06:53 PM UTC-4 tapi...@gmail.com wrote:
> Spent some
Spent some time on investigating this problem. It is confirmed that, when N
== 16384, the memclrNoHeapPointers function is called twice in the Insert2
function. That means the "make+copy` optimization introduced in Go 1.15
will perform worse than the normal route under such situation.
On
Dnia 2021-07-28, o godz. 19:42:05
Kurtis Rader napisał(a):
> [...] I too am mildly annoyed by [Tapir Liu] questions.
As I was a few years ago. But let's do Tapir Liu justice: he posted a good
manual
online [https://go101.org] and he updates it as his knowledge grows.
Also his stubborn picking
On Thursday, July 29, 2021 at 3:22:35 AM UTC-4 axel.wa...@googlemail.com
wrote:
> FWIW I did take a look at the output (I ended up curious enough):
> https://go.godbolt.org/z/WK8xYd1E3
>
> Insert and Insert2 generate pretty different code. In particular, Insert2
> uses makeslicecopy, to fold
BTW: https://pkg.go.dev/math/rand#Read
On Thu, Jul 29, 2021 at 9:21 AM Axel Wagner
wrote:
> FWIW I did take a look at the output (I ended up curious enough):
> https://go.godbolt.org/z/WK8xYd1E3
>
> Insert and Insert2 generate pretty different code. In particular, Insert2
> uses makeslicecopy,
FWIW I did take a look at the output (I ended up curious enough):
https://go.godbolt.org/z/WK8xYd1E3
Insert and Insert2 generate pretty different code. In particular, Insert2
uses makeslicecopy, to fold the `make` and the `copy(s2, a)` (avoiding
having to zero the relevant memory). `Insert` uses
It would have taken you less time to look at the generated code and/or a
CPU profile than it would have to post this - let alone the rest of the
discussion. I also believe it likely would take more time to type out the
answer to your question, than it would for you to look at the generated
code
On Wednesday, July 28, 2021 at 10:42:58 PM UTC-4 Kurtis Rader wrote:
> On Wed, Jul 28, 2021 at 7:24 PM tapi...@gmail.com
> wrote:
>
>> I will when I confirm that no one could give an answer without much
>> effort. If you feel frustrated, you can ignored it. ;D
>>
>
> Like Axel, I too am
On Wed, Jul 28, 2021 at 7:24 PM tapi...@gmail.com
wrote:
> I will when I confirm that no one could give an answer without much
> effort. If you feel frustrated, you can ignored it. ;D
>
Like Axel, I too am mildly annoyed by your questions. Primarily because you
don't seem to understand that the
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
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
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
> wrote:
>
>> I think this one is different from previous. I don't criticize Go, I just
>> seek reasons.
>>
>
> Implying that previously you've been
On Wed, Jul 28, 2021 at 7:30 PM 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?
As for your search for reasons: 16384 is a power of two. So I assume that
what changes is
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
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:
>
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
18 matches
Mail list logo
