anon (anon.delete@this.anon.com) on August 22, 2012 9:46 am wrote:
>
> If only using the MOB/ROB, then the size of the
> TM working sets will be rather limited, basically a slightly bigger version of
> the LL/SC instruction sequence in RISCs. Wouldn't be that useful.

Oh, it can be useful. Much more so than LL/SC, because it would work with arbitrary compiled code, and it wouldn't be limited to a single reservation (which is what LL/SC tends to do), and not tied to a "smallest common denominator" transaction size like LL/SC.

So personally, I'd like to see the "small transactions only" model.

However, in order for that model to work well, you have to have really cheap failure modes, because you potentially fail much more often.

This is one of the reasons why I was arguing so strongly at one point (both here and to some Intel engineers) for the transaction model to use "success prediction" (possibly actually re-using the branch prediction hardware, but possibly with a separate predictor). Because part of "really cheap failure modes" is to not even bother trying if it's unlikely to work.

(Part of "really cheap failure modes" is also to not have to do prediction in software. All the hardware engineers seem to think that you can do prediction in software, but that's a total and utter disaster for so many reasons that it's not even funny).

And in many ways, small transactions are much easier to predict. Some of them you can predict by just looking at the instruction stream, without any dynamic prediction table at all. The simplest prediction model would involve just the CPU asking itself "is the transaction end instruction in my instruction queue" when it starts the begin-transaction instruction, and saying "No, screw that" if not.

And nice small transactions are where transactions really help the most. Lock ping pong for some big expensive thing is not cheap, but ping-ponging some hot lock just because you do some list addition to a hot list - that's relatively really expensive.

Linus