Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #3972 > unrolled thread

About Intel TSX

Started byIntelli2 <intelli2@mama.com>
First post2017-12-08 13:50 -0500
Last post2017-12-08 13:50 -0500
Articles 1 — 1 participant

Back to article view | Back to comp.programming.threads


Contents

  About Intel TSX Intelli2 <intelli2@mama.com> - 2017-12-08 13:50 -0500

#3972 — About Intel TSX

FromIntelli2 <intelli2@mama.com>
Date2017-12-08 13:50 -0500
SubjectAbout Intel TSX
Message-ID<p0emtq$el2$2@dont-email.me>
Hello,


Here is something interesting to read about hardware transactional 
memory that is Intel TSX:

TSX does not gaurantee forward progress, so there must always be a 
fallback non-TSX pathway. (complex transactions might always abort even 
without any contention because they overflow the speculation buffer. 
Even transactions that could run in theory might livelock forever if you 
don't have the right pauses to allow forward progress, so the fallback 
path is needed then too).

TSX works by keeping a speculative set of registers and processor state. 
It tracks all reads done in the speculation block, and enqueues all 
writes to be delayed until the transaction ends. The memory tracking of 
the transaction is currently done using the L1 cache and the standard 
cache line protocols. This means contention is only detected at cache 
line granularity, so you have the standard "false sharing" issue.

If your transaction reads a cache line, then any write to that cache 
line by another core causes the transaction to abort. (reads by other 
cores do not cause an abort).

If your transaction writes a cache line, then any read or write by 
another core causes the transaction to abort.

If your transaction aborts, then any cache lines written are evicted 
from L1. If any of the cache lines involved in the transaction are 
evicted during the transaction (eg. if you touch too much memory, or 
another core locks that line), the transaction is aborted.

TSX seems to allow quite a large working set (up to size of L1 ?). 
Obviously the more memory you touch the more likely to abort due to 
contention.

Obviously you will get aborts from anything "funny" that's not just 
plain code and memory access. Context switches, IO, kernel calls, etc. 
will abort transactions.

At the moment, TSX is quite slow, even if there's no contention and you 
don't do anything in the block. There's a lot of overhead. Using TSX 
naively may slow down even threaded code. Getting significant 
performance gains from it is non-trivial.


Read more here:

http://cbloomrants.blogspot.ca/2014/11/11-12-14-intel-tsx-notes.html



Thank you,
Amine Moulay Ramdane.

[toc] | [standalone]


Back to top | Article view | comp.programming.threads


csiph-web