By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), August 22, 2012 9:20 am
Room: Moderated Discussions
anon (anon.delete@this.anon.com) on August 22, 2012 9:46 am wrote:
[snip]
> 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.
Given that LL/SC itself is rather useful, extending it even to a dozen accesses could significantly extend its usefulness.
AMD's ASF's capacity for guaranteed completion (outside of conflicts or interrupts) was smaller (though ASF also made stronger Architectural guarantees and allowed removing members of the read set).
Many critical sections are small--intentionally so because a long critical section is likely to reduce parallelism. Without additional (complex) hardware to order transactions so that they do not conflict, most large transactions might be likely to fail.
[snip]
> 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.
Given that LL/SC itself is rather useful, extending it even to a dozen accesses could significantly extend its usefulness.
AMD's ASF's capacity for guaranteed completion (outside of conflicts or interrupts) was smaller (though ASF also made stronger Architectural guarantees and allowed removing members of the read set).
Many critical sections are small--intentionally so because a long critical section is likely to reduce parallelism. Without additional (complex) hardware to order transactions so that they do not conflict, most large transactions might be likely to fail.
Topic | Posted By | Date |
---|---|---|
Article: Haswell TM Alternatives | David Kanter | 2012/08/21 09:17 PM |
Article: Haswell TM Alternatives | Håkan Winbom | 2012/08/21 11:52 PM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 01:06 AM |
Article: Haswell TM Alternatives | anon | 2012/08/22 08:46 AM |
Article: Haswell TM Alternatives | Linus Torvalds | 2012/08/22 09:16 AM |
Article: Haswell TM Alternatives | Doug S | 2012/08/24 08:34 AM |
AMD's ASF even more limited | Paul A. Clayton | 2012/08/22 09:20 AM |
AMD's ASF even more limited | Linus Torvalds | 2012/08/22 09:41 AM |
Compiler use of ll/sc? | Paul A. Clayton | 2012/08/28 09:28 AM |
Compiler use of ll/sc? | Linus Torvalds | 2012/09/08 12:58 PM |
Lock recognition? | Paul A. Clayton | 2012/09/10 01:17 PM |
Sorry, I was confused | Paul A. Clayton | 2012/09/13 10:56 AM |
Filter to detect store conflicts | Paul A. Clayton | 2012/08/22 09:19 AM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 02:02 PM |
Article: Haswell TM Alternatives | David Kanter | 2012/08/22 02:45 PM |
Article: Haswell TM Alternatives | bakaneko | 2012/08/22 09:56 PM |
Cache line granularity? | Paul A. Clayton | 2012/08/28 09:28 AM |
Cache line granularity? | David Kanter | 2012/08/31 08:13 AM |
A looser definition might have advantages | Paul A. Clayton | 2012/09/01 06:29 AM |
Cache line granularity? | rwessel | 2012/08/31 07:54 PM |
Alpha load locked granularity | Paul A. Clayton | 2012/09/01 06:29 AM |
Alpha load locked granularity | anon | 2012/09/02 05:23 PM |
Alpha pages groups | Paul A. Clayton | 2012/09/03 04:16 AM |
An alternative implementation | Maynard Handley | 2012/11/20 09:52 PM |
An alternative implementation | bakaneko | 2012/11/21 05:52 AM |
Guarding unread values? | Paul A. Clayton | 2012/11/21 08:39 AM |
Guarding unread values? | bakaneko | 2012/11/21 11:25 AM |
TM granularity and versioning | Paul A. Clayton | 2012/11/21 08:27 AM |
TM granularity and versioning | Maynard Handley | 2012/11/21 10:52 AM |
Indeed, TM (and coherence) has devilish details (NT) | Paul A. Clayton | 2012/11/21 10:56 AM |