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]

libitm: Use ml_wt as default TM methods for >1 thread.

This patch changes the default TM method that is used if more than one
thread is registered to ml_wt (from serialirr_onwrite previously).  For
one registered thread, it's still serialirr.

Right now, this will not be a performance advantage for every workload
and number of threads.  However, of the TM methods we have implemented
so far, ml_wt is the only one that allows concurrent update
transactions.  gl_wt update txns essentially abort all other txns that
have read something.  serialirr_onwrite serializes all update txns.
ml_wt can execute disjoint-access-parallel txns in parallel, unless we
get false sharing via the address-to-orec mapping.  Therefore, even
though ml_wt performance isn't great currently, it's the only option
that doesn't suffer from a principal scalability bottleneck.

In the long-term, this should get improved by a less trivial choice
regarding which TM method to use (e.g., based on actual abort rate and
other factors). Likewise, the ml_wt lock-mapping can hopefully be
improved, so that we can at least get better scalability even if the
single-thread overheads are higher.  We might also want to add other TM
methods.  But all of that will require some time to get done, so until
then, I think the better choice right now is still to go with ml_wt
as-is in the meantime.


PS: I also noticed that libitm/testsuite/libitm.c/memcpy-1.c takes
surprisingly long when using ml_wt compared to serialirr.  I will
investigate this later. 

Attachment: patch1
Description: Text document

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