On Wednesday, 12 November 2014 at 11:51:11 UTC, ponce wrote:
Haswell does not have buffered transactions so you wait for
the commit, but there are presentations out where Intel has
put buffered transactions at around 2017… (but I would expect
a delay).
I wasn't arguing of the current performance (which is not
impressive).
My point is that transactional memory has limited
applicability, since locks already fits the bill well.
Yes, Intel style HTM is only an optimization for high contention
where you already have locking code in place, since you need to
take a lock as a fallback anyway. But useful for database-like
situations where you might have 7 readers traversing and 1 writer
updating a leaf node.
It is of course difficult to say how it will perform in 2./3.
generation implementations or if the overall hardware
architecture will change radically (as we see in Phi and
Parallella).
I can easily imagine that the on-die architecture will change
radically, within a decade, with the current x86 architecture
remaining at a coordination level. This is the direction Phi
seems to be going.
In that case, maybe the performance of the x86 will be less
critical (if it spends most time waiting and buffering is done in
hardware).
And I'd argue the same with most lockfree structures actually.
I think in general that you need to create application specific
data-structures to get performance and convenience. (I seldom
reuse lists and graph-like data structures for this reason, it is
just easier to create them from scratch.)
I also agree that you usually can get away with regular locks and
very simple lockfree structures where performance matters (such
as a lockfree stack where only one thread removes nodes).
Where performance truly matters you probably need to split up the
dataset based on the actual computations and run over the data in
a batch-like SIMD way anyway. (E.g. physics simulation).
