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.

In practice the fallback path hits in lots of cases when there is no true conflict, and even in the case of true conflicts when you do hit the fallback path, the problem is all the other concurrent work that was not involved in the conflicts now all causes a pile up in the slow path and you get stuck in a negative feedback loop. I never understood how this wasn't a blindingly obvious problem (particularly for lock elision).

So you have to implement a scalable fallback. And then the transactional path becomes little use (at best, and very expensive wasted work at worst).