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

Groups > comp.programming.threads > #3973

Here is my extended post about HTM and TM..

Show all headers | View raw

Hello,


Here is my extended post about HTM and TM..

Transactional memory pros and cons from ACM Queue:

"We observed that the TM programming model itself, whether implemented 
in hardware or software, introduces complexities that limit the expected 
productivity gains, thus reducing the current incentive for migration to 
transactional programming and the justification at present for anything 
more than a small amount of hardware support."

Read more here:

https://insidehpc.com/2008/12/transactional-memory-pro-and-con/

And since also HTM (hardware transactional memory) and TM can not 
replace locks when doing IO and for highly contended critical sections , 
this is why my inventions that are my scalable algorithms such as my C++ 
Synchronization Objects Library and my others scalable algorithms that i 
am thinking to sell to Embarcadero technologies or Microsoft are still 
very useful.

Here is also 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.

Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread

Thread

Here is my extended post about HTM and TM.. Intelli2 <intelli2@mama.com> - 2017-12-08 14:08 -0500

csiph-web