anon2 (anon.delete@this.anon.com) on August 23, 2022 8:50 pm wrote:
> Andrey (andrey.semashev.delete@this.gmail.com) on August 23, 2022 6:01 pm wrote:
> > --- (---.delete@this.redheron.com) on August 23, 2022 10:00 am wrote:
> > > Andrey (andrey.semashev.delete@this.gmail.com) on August 23, 2022 6:29 am wrote:
> > > > --- (---.delete@this.redheron.com) on August 21, 2022 9:27 pm wrote:
> > > > > Andrey (andrey.semashev.delete@this.gmail.com) on August 21, 2022 6:39 pm wrote:
> > > > > >
> > > > > > The key advantage of transactional memory is atomicity of *multiple* memory accesses,
> > > > > > at potentially distant memory locations. No predictor will give you that.
> > > > >
> > > > > I'm no expert, but this seems to me too strong a claim.
> > > > > I make no claims as to whether it's a good use of transistors, but I could imagine a two
> > > > > level system that starts by detecting patterns of atomics that occur close to each in
> > > > > time, and that that then predicts an overall outcome, all held as speculative in the same
> > > > > way as HTM (ie vie special "don't propagate this" bits in each cache line)...
> > > >
> > > > Architecturally, two atomic operations are distinct and are not atomic in combination. This is regardless
> > > > of whether the particular hardware manages to somehow commit the two operations as one atomic operation.
> > > > Being architecturally atomic is what is important here because that is what software relies on.
> > > >
> > > > HTM, on the other hand, is architectural (i.e. not speculative). That is, the architecture guarantees,
> > > > within set limits, that a certain sequence of operations will execute atomically.
> > >
> > > I understand this Andrey, but you apparently did not understand the distinction I was trying to make.
> > > Is what people want from HTM
> > > - PERFORMANCE (which can be achieved, I think, by speculation, as I suggested) OR
> > > - EASIER writing of code (which can be achieved, I think, by language+compiler, with
> > > any theoretical performance that's left on the table being made up by speculation).
> > >
> > > HTM is a means to an end, it's not an end in itself. But is that end
> > > - performance OR
> > > - making it easier to write reliable parallel code
> > > ?
> >
> > All other things being equal, HTM does not make it easier to write code compared to locking. In fact,
> > it makes it more complex, at least in case of Intel TSX, as you have to implement two code paths, one
> > of them involving a lock.
>
> It was absolutely *supposed* to make writing code easier. This was the entire promise of the thing from the beginning.
> The theory was that the fallback path was supposed to be when you had a true conflict, so a highly scalable fallback
> path would not be required (because you were conflicting the same data anyway). In theory.

I deliberately said "all other things being equal", and that includes the code design. Given the coarse grained locking code, replacing (or rather, augmenting) the code with HTM does not simplify the code. On the contrary, it makes the code more complex as it now has both the locking path and the transactional path. Given the fine grained locking code, you can augment the fine grained locks with short transactions and have the same increase of code complexity as with coarse grained locks.

The promise was that given the coarse grained locking design one could use HTM to achieve better performance on it instead of increasing the code complexity by changing the design to lock-free techniques or fine grained locking. This is very different from promising to reduce code complexity. And what I'm saying is if you do change the design anyway, the performance of the changed design with HTM on top of that could be better still - at the expense of yet higher code complexity. So the code complexity argument is definitely not in favor of HTM, and never was.