This is the mail archive of the
mailing list for the GCC project.
Re: [patch] libitm: Add multi-lock, write-through TM method.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Aldy Hernandez <aldyh at redhat dot com>
- Date: Tue, 14 Feb 2012 14:15:41 +0100
- Subject: Re: [patch] libitm: Add multi-lock, write-through TM method.
- References: <firstname.lastname@example.org> <4F3993B2.email@example.com>
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