• dsimcha (13/13) Sep 30 2008 A while back, there were some discussions about capacity fields, etc. on...
• dsimcha (4/17) Sep 30 2008 Never mind, this is a *very* bad idea for obvious reasons. When I wrote...
• Chad J (6/24) Sep 30 2008 Well, there are probably going to be programs where that is the case,

dsimcha <dsimcha yahoo.com> writes:

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?

dsimcha <dsimcha yahoo.com> writes:

== 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.

Chad J <gamerchad __spam.is.bad__gmail.com> writes:

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.