By: Paul A. Clayton (paaronclayton.delete@this.gmail.com), September 24, 2010 1:19 pm
Room: Moderated Discussions
David Kanter (dkanter@realworldtech.com) on 9/24/10 wrote:
---------------------------
[snip]
>I think Azul had something much simpler than TM. I think they are now porting
>to nehalem-ex, so they clearly don't need TM for some of their stuff.
http://www.azulsystems.com/blog/cliff-click/2009-02-25-and-now-some-hardware-transactional-memory-comments
Some interesting quotes:
"Software heuristics determine when to try the HTM (uncontended locks are much cheaper using a cache-hitting CAS)"
"we had lots of teething problems with the software heuristic that used to cause 10-20% slowdowns due to endless fail/retry loops"
"HTM failure appears to nearly always be due to conflict and not capacity"
"Why make the code XTN-friendly when they can make it lock-friendly as well, and have it run fine on all gear (and not just HTM-enabled gear)?"
"It's not the case that they need to write some uber-hard-to-maintain code to get performance. Instead it's the case that they have no clue which locks need to be "cracked" to get a speedup, and once that's pointed out the fixes are generally straightforward."
(A bit discouraging that TM might not be a generally
significant win even if universally supported.)
Paul A. Clayton
just a technophile
---------------------------
[snip]
>I think Azul had something much simpler than TM. I think they are now porting
>to nehalem-ex, so they clearly don't need TM for some of their stuff.
http://www.azulsystems.com/blog/cliff-click/2009-02-25-and-now-some-hardware-transactional-memory-comments
Some interesting quotes:
"Software heuristics determine when to try the HTM (uncontended locks are much cheaper using a cache-hitting CAS)"
"we had lots of teething problems with the software heuristic that used to cause 10-20% slowdowns due to endless fail/retry loops"
"HTM failure appears to nearly always be due to conflict and not capacity"
"Why make the code XTN-friendly when they can make it lock-friendly as well, and have it run fine on all gear (and not just HTM-enabled gear)?"
"It's not the case that they need to write some uber-hard-to-maintain code to get performance. Instead it's the case that they have no clue which locks need to be "cracked" to get a speedup, and once that's pointed out the fixes are generally straightforward."
(A bit discouraging that TM might not be a generally
significant win even if universally supported.)
Paul A. Clayton
just a technophile
| Topic | Posted By | Date |
|---|---|---|
| T3 announced | Max | 2010/09/21 03:42 AM |
| T3 announced | someone | 2010/09/21 04:53 AM |
| T3 announced | anon | 2010/09/21 05:05 AM |
| T3 announced | lurker | 2010/09/21 06:11 AM |
| T3 announced | Jesper Frimann | 2010/09/21 06:21 AM |
| T3 announced | Phil | 2010/09/21 11:59 PM |
| T3 announced | Michael S | 2010/09/22 05:16 AM |
| T3 announced | Linus Torvalds | 2010/09/21 06:15 AM |
| T3 announced | anon | 2010/09/21 08:31 AM |
| Transactional memory | Paul A. Clayton | 2010/09/21 09:52 AM |
| Transactional memory | Linus Torvalds | 2010/09/21 11:21 AM |
| Transactional memory | Paul A. Clayton | 2010/09/23 06:30 AM |
| Transactional memory | Linus Torvalds | 2010/09/23 07:01 AM |
| Transactional memory | David Kanter | 2010/09/23 11:05 PM |
| Transactional memory | Linus Torvalds | 2010/09/24 06:59 AM |
| Transactional memory | David Kanter | 2010/09/25 08:27 AM |
| 'dynamic fallback'? | Paul A. Clayton | 2010/09/25 10:28 AM |
| 'dynamic fallback'? | Linus Torvalds | 2010/09/25 12:23 PM |
| 'dynamic fallback'? | blaine | 2010/09/25 01:16 PM |
| Cliff Click Jr. on Azul's HTM | Paul A. Clayton | 2010/09/24 01:19 PM |
| Transactional memory | Foo_ | 2010/09/24 02:08 AM |
| T3 announced | blaine | 2010/09/21 10:43 AM |
| no news from Fujitsu | Max | 2010/09/21 09:37 PM |
