Andrey (andrey.semashev.delete@this.gmail.com) on August 24, 2022 3:54 am wrote:
> 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.

That's just jibberish. All else being equal you don't change anything and the code is exactly the same and there is no complexity. Adding TM is the difference when you want to make an improvement. The alternative being improving performance without using TM.

And for that, TM was promised to be the simpler option.