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

> Is your point not the PREDICTION of atomicity but the fact that the code can be
> written as atomic, ie (start transaction, complicated stuff, end transaction)?

There's no "prediction of atomicity", from the architecture stand point. An operation (or a sequence of) is either atomic or not. That some non-atomic operations may appear atomic on some hardware implementations is nothing more than a coincidence and is not something that can be relied on in software.

Now, if you are suggesting that in some hardware it may be beneficial to implement non-atomic operations as atomic ones, I'm quite doubtful. Coherence protocols are not free in terms of performance, so I can't see the benefit beyond write combining of neighbour writes. But in any case, such feature would have nothing to do with neither atomics nor HTM.

> That's what I would classify as "language/compiler problem". Again I'm not claiming that *will* work out,
> but I could see various parties, from IBM to Apple to maybe even Intel considering that maybe the SW/language
> track has a better ultimate chance than the HW track. Apple and IBM of course have some degree of language
> control; if this is Intel's bet I'm less sure what their language bet might be. C#? Rust?

Software implementations of transactional memory have existed for quite a while and never gained any widespread use. I have not seen any evidence that these implementations offer any performance benefits and I strongly suspect that it's very much the opposite. So, in my opinion, without proper hardware support general transactional memory is pretty much dead.