James Reinders (if you read this),
Could you comment on a potential unintended beneficial side effect of TSX.
At first glance this may seem odd, consider a single threaded application that enters a transaction (XACQUIRE or XBEGIN), from that point on until the exit (XRELEASE or XEND) all memory reads and writes (up to your buffering capacity) are effectively "sticky" with respect to the internal copies. IOW these locations behave similar to non-evictable L1 cache locations (be they in L1 or elsewhere). Further the the writes and read/modify/writes are write combining with respect to the internal storage as opposed to in RAM via the memory bus. What I am suggesting is, TSX can be used to improve performance of code that has no thread contention. Is this a valid assessment?
Jim Dempsey
Link Copied
Hi Jim,
>these locations behave similar to non-evictable L1 cache locations
I think that processors do not evict w/o reasons. So if there are no reasons to evict, it is the same with and w/o TSX. If there are reasons, one gets either evictions (preferable) or trx abort (not preferable).
>the writes and read/modify/writes are write combining with respect to the internal storage as opposed to in RAM via the memory bus
With WB memory type (default) you get this for free. All writes are effectively "write-combining" (however on the higher level then intra-core write combining, which avoids even accessing caches).
>the writes and read/modify/writes are write combining with respect to the internal storage as opposed to in RAM via the memory bus
With WB memory type (default) you get this for free. All writes are effectively "write-combining" (however on the higher level then intra-core write combining, which avoids even accessing caches).
<<For more complete information about compiler optimizations, see our Optimization Notice.