A while back, there were some discussions about capacity fields, etc. on this forum.  I was looking at the GC implementation, and, if we want to speed up array appends in a dead simple way without really much, I think we can gain a lot by simply making the size cache in gcx.d thread-local in D2.  When appending to arrays in multiple threads, not only is one paying for frequent size cache lookups, but one is also having all of their threads block on this synchronization.

We have:

struct Gcx {
    void *p_cache;
    size_t size_cache;
}

Would it help to just make these two variables thread-local?

== Quote from dsimcha (dsimcha@yahoo.com)'s article
> A while back, there were some discussions about capacity fields, etc. on this
> forum.  I was looking at the GC implementation, and, if we want to speed up
> array appends in a dead simple way without really much, I think we can gain a
> lot by simply making the size cache in gcx.d thread-local in D2.  When
> appending to arrays in multiple threads, not only is one paying for frequent
> size cache lookups, but one is also having all of their threads block on this
> synchronization.
> We have:
> struct Gcx {
>     void *p_cache;
>     size_t size_cache;
> }
> Would it help to just make these two variables thread-local?

Never mind, this is a *very* bad idea for obvious reasons.  When I wrote the initial post, I only thought of the case where each array that's being appended to is, for all practical purposes, owned by a single thread.

dsimcha wrote:
> == Quote from dsimcha (dsimcha@yahoo.com)'s article
>> A while back, there were some discussions about capacity fields, etc. on this
>> forum.  I was looking at the GC implementation, and, if we want to speed up
>> array appends in a dead simple way without really much, I think we can gain a
>> lot by simply making the size cache in gcx.d thread-local in D2.  When
>> appending to arrays in multiple threads, not only is one paying for frequent
>> size cache lookups, but one is also having all of their threads block on this
>> synchronization.
>> We have:
>> struct Gcx {
>>     void *p_cache;
>>     size_t size_cache;
>> }
>> Would it help to just make these two variables thread-local?
> 
> Never mind, this is a *very* bad idea for obvious reasons.  When I wrote the
> initial post, I only thought of the case where each array that's being appended to
> is, for all practical purposes, owned by a single thread.

Well, there are probably going to be programs where that is the case, namely as determined by escape analysis or in pure functions.  So have one code/data path for the special case of single-thread arrays, and another for the general case.  Maybe that would work?  Not sure if it would be so dead simple though.