This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] libitm: Add multi-lock, write-through TM method.

On Mon, 2012-02-13 at 14:50 -0800, Richard Henderson wrote:
> On 02/13/2012 01:47 PM, Torvald Riegel wrote:
> > +  // Location-to-orec mapping.  Stripes of 16B mapped to 2^19 orecs.
> > +  static const gtm_word L2O_ORECS = 1 << 19;
> > +  static const gtm_word L2O_SHIFT = 4;
> Is it just easier to say "16B" or did we really want CACHELINE_SIZE?

The 16B stripes where quite good in past experiments with TinySTM, IIRC.
The problem with the simple hash function that we use currently is that
if you make #shifts too small, you acquire and check more locks (so
higher cache footprint too), and the lock array covers less space before
it wraps around.  However, if you make #shifts too large, you increase
false sharing.  Cacheline granularity could be too large already, unless
the user has put all independent variables on separate cache lines (but
this is often too much bloat, e.g., think about the layout of the nodes
of a tree...). The best choice here is more or less workload-dependent,
and still an open question.  In the past, I also experimented with less
simple hash functions, with mixed results.
Optimizing / tuning this hash function is on my performance todo list.

> Otherwise ok.

Committed (with the formatting fixed, and the 16B stripes kept as

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]