By: Doug S (foo.delete@this.bar.bar), August 24, 2012 9:34 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 22, 2012 10:16 am wrote:
> 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.
Wouldn't you want a combination of both hardware and software as the ideal? Same thing as the hints to branch prediction used in Linux - "if (unlikely(condition)) ..." There will be some transactions with little contention you feel would almost never fail, and vice versa.
> 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.
Wouldn't you want a combination of both hardware and software as the ideal? Same thing as the hints to branch prediction used in Linux - "if (unlikely(condition)) ..." There will be some transactions with little contention you feel would almost never fail, and vice versa.
| Topic | Posted By | Date |
|---|---|---|
| Article: Haswell TM Alternatives | David Kanter | 2012/08/21 10:17 PM |
| Article: Haswell TM Alternatives | Håkan Winbom | 2012/08/22 12:52 AM |
| Article: Haswell TM Alternatives | David Kanter | 2012/08/22 02:06 AM |
| Article: Haswell TM Alternatives | anon | 2012/08/22 09:46 AM |
| Article: Haswell TM Alternatives | Linus Torvalds | 2012/08/22 10:16 AM |
| Article: Haswell TM Alternatives | Doug S | 2012/08/24 09:34 AM |
| AMD's ASF even more limited | Paul A. Clayton | 2012/08/22 10:20 AM |
| AMD's ASF even more limited | Linus Torvalds | 2012/08/22 10:41 AM |
| Compiler use of ll/sc? | Paul A. Clayton | 2012/08/28 10:28 AM |
| Compiler use of ll/sc? | Linus Torvalds | 2012/09/08 01:58 PM |
| Lock recognition? | Paul A. Clayton | 2012/09/10 02:17 PM |
| Sorry, I was confused | Paul A. Clayton | 2012/09/13 11:56 AM |
| Filter to detect store conflicts | Paul A. Clayton | 2012/08/22 10:19 AM |
| Article: Haswell TM Alternatives | bakaneko | 2012/08/22 03:02 PM |
| Article: Haswell TM Alternatives | David Kanter | 2012/08/22 03:45 PM |
| Article: Haswell TM Alternatives | bakaneko | 2012/08/22 10:56 PM |
| Cache line granularity? | Paul A. Clayton | 2012/08/28 10:28 AM |
| Cache line granularity? | David Kanter | 2012/08/31 09:13 AM |
| A looser definition might have advantages | Paul A. Clayton | 2012/09/01 07:29 AM |
| Cache line granularity? | rwessel | 2012/08/31 08:54 PM |
| Alpha load locked granularity | Paul A. Clayton | 2012/09/01 07:29 AM |
| Alpha load locked granularity | anon | 2012/09/02 06:23 PM |
| Alpha pages groups | Paul A. Clayton | 2012/09/03 05:16 AM |
| An alternative implementation | Maynard Handley | 2012/11/20 10:52 PM |
| An alternative implementation | bakaneko | 2012/11/21 06:52 AM |
| Guarding unread values? | Paul A. Clayton | 2012/11/21 09:39 AM |
| Guarding unread values? | bakaneko | 2012/11/21 12:25 PM |
| TM granularity and versioning | Paul A. Clayton | 2012/11/21 09:27 AM |
| TM granularity and versioning | Maynard Handley | 2012/11/21 11:52 AM |
| Indeed, TM (and coherence) has devilish details (NT) | Paul A. Clayton | 2012/11/21 11:56 AM |
