By: --- (---.delete@this.redheron.com), August 21, 2022 9:27 pm
Room: Moderated Discussions
Andrey (andrey.semashev.delete@this.gmail.com) on August 21, 2022 6:39 pm wrote:
> --- (---.delete@this.redheron.com) on August 21, 2022 1:26 pm wrote:
> >
> > I've no idea what the M1 claim is about!
> > But the generic issue may be that HTM is to simultaneously too strong and too weak a contract.
> > The alternative is that the HW give you effectively the performance of HTM, but
> > through speculation as to the behavior of the atomic operations involved, eg
> > (2020) https://patents.google.com/patent/US20220091846A1 Atomic Operation Predictor.
> >
> > In a sense this is like providing HTM (you need the same sort of machinery to store and
> > unwind state) but without the hassle that you are locked into particular claims (transactions
> > can be up to X instructions long, must not include more than Y types of this operation,
> > etc etc), you can change the details as best fits each new design. What you lose is the
> > SW ease of HTM, but if you are confident that your language provides that anyway...
>
> 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)...
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)?
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?
> --- (---.delete@this.redheron.com) on August 21, 2022 1:26 pm wrote:
> >
> > I've no idea what the M1 claim is about!
> > But the generic issue may be that HTM is to simultaneously too strong and too weak a contract.
> > The alternative is that the HW give you effectively the performance of HTM, but
> > through speculation as to the behavior of the atomic operations involved, eg
> > (2020) https://patents.google.com/patent/US20220091846A1 Atomic Operation Predictor.
> >
> > In a sense this is like providing HTM (you need the same sort of machinery to store and
> > unwind state) but without the hassle that you are locked into particular claims (transactions
> > can be up to X instructions long, must not include more than Y types of this operation,
> > etc etc), you can change the details as best fits each new design. What you lose is the
> > SW ease of HTM, but if you are confident that your language provides that anyway...
>
> 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)...
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)?
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?