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.
>
And on some codebases (SAP HANA is the poster child), you really did get this win from Intel TSX with all its flaws.

AFAICT, though, that was in large part because SAP HANA was sufficiently poorly written that doing fine-grained locking well was hard, and thus it was a best case scenario for HTM (eliding coarse-grained locks that in practice never had cacheline level conflicts while taken, hence no false conflicts).

> 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).

Or you could do the work that SAP appears to have done for SAP HANA - eliminate false conflicts completely, so that the fallback path no longer needs to be scalable.

This, however, destroys the value proposition of HTM unless you've got sufficiently gnarly legacy that doing locking well is hard - you're doing significant work to make HTM perform well in your application, which isn't going to help CPUs without HTM, when you could do the (often no harder) work of making locking perform well in your application, which will help on any CPU.

Which, in turn, makes HTM a niche feature for a small market - legacy codebases that benefit from multiprocessor support but where fine-grained locking is too big an investment to make for the benefit you get.

Looks like that niche is sufficiently small to not be worth the hardware engineering investment - and that people in that niche now have no choice but make the software engineering investment if they need to scale on bigger systems.