By: Ganon (anon.delete@this.gmail.com), March 30, 2021 5:22 pm
Room: Moderated Discussions
Foo_ (foo.delete@this.nomail.com) on March 30, 2021 1:31 pm wrote:
> Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on March 30, 2021 1:27 pm wrote:
> > Jon Masters (jcm.delete@this.jonmasters.org) on March 30, 2021 11:41 am wrote:
> > > https://www.arm.com/why-arm/architecture/cpu
> >
> > Interesting that they're pulling in both SVE2 and transactional memory.
>
> Quoting this page:
>
> "One of the most promising uses of Transactional Memory is known as Transactional Lock Elision (TLE),
> which allows existing regions of code, protected by locks, to be executed concurrently within a transaction.
> This happens with no modification to the multi-threaded program, and only falls back to the less optimal
> lock-taking path if the hardware detects a conflict within the transaction."
>
> -> What is the likelihood of ARM succeeding here where Intel
> failed (and while AMD seems completely uninterested)?
>
Other than the some initial bugs and possible side channel issues
(which are not a relevant security threat in many contexts); has Intel
failed with HTM/TLE? Many commercial databases are making active use of it;
it greatly simplifies the writing of scalable concurrent data structures.
One could even say that the move from 32KB (8 way) to 48KB (12 way) in the L1 cache in Icelake Server is partly to enable more use of transactional memory. In addition, looking at
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
they are adding support for suspending/resuming load tracking in RTM:
Programmers can choose which memory accesses do not need to be tracked in the TSX read set. A programmer who uses the suspend load address tracking feature must ensure that there are no atomicity requirements related to the addresses they choose to exclude from the read set as hardware will not detect read-write conflicts for those addresses.
Doesn't seem like something that would be worth adding if they did not have big customers with a
lot of money asking for this feature.
> Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on March 30, 2021 1:27 pm wrote:
> > Jon Masters (jcm.delete@this.jonmasters.org) on March 30, 2021 11:41 am wrote:
> > > https://www.arm.com/why-arm/architecture/cpu
> >
> > Interesting that they're pulling in both SVE2 and transactional memory.
>
> Quoting this page:
>
> "One of the most promising uses of Transactional Memory is known as Transactional Lock Elision (TLE),
> which allows existing regions of code, protected by locks, to be executed concurrently within a transaction.
> This happens with no modification to the multi-threaded program, and only falls back to the less optimal
> lock-taking path if the hardware detects a conflict within the transaction."
>
> -> What is the likelihood of ARM succeeding here where Intel
> failed (and while AMD seems completely uninterested)?
>
Other than the some initial bugs and possible side channel issues
(which are not a relevant security threat in many contexts); has Intel
failed with HTM/TLE? Many commercial databases are making active use of it;
it greatly simplifies the writing of scalable concurrent data structures.
One could even say that the move from 32KB (8 way) to 48KB (12 way) in the L1 cache in Icelake Server is partly to enable more use of transactional memory. In addition, looking at
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
they are adding support for suspending/resuming load tracking in RTM:
Programmers can choose which memory accesses do not need to be tracked in the TSX read set. A programmer who uses the suspend load address tracking feature must ensure that there are no atomicity requirements related to the addresses they choose to exclude from the read set as hardware will not detect read-write conflicts for those addresses.
Doesn't seem like something that would be worth adding if they did not have big customers with a
lot of money asking for this feature.