'dynamic fallback'?

By: blaine (myname.delete@this.acm.org), September 25, 2010 1:16 pm
Room: Moderated Discussions
Linus Torvalds (torvalds@linux-foundation.org) on 9/25/10 wrote:
>Paul A. Clayton (paaronclayton@gmail.com) on 9/25/10 wrote:
>>The system for Rock provided dynamic fallback.
>No it didn't.
>>Not only could software decide to retry immediately [...]
>Exactly. Software. Because the hardware had no
>support for dynamic fallbacks.
>>(Or did you mean by 'dynamic fallback' that
>>hardware would handle transaction failures or anticipate
>>transaction failures?)
>I absolutely did.
>The thing is, if transactional memory is supposed to be
>useful, it has to be noticeably faster than
>traditional locking.
>And there is no way that you will get that with some
>software-based fallback that tests some per-instance flag
>or whatever to decide dynamically whether it needs to
>back off. Especially since we know that the fallback
>is going to be slower than doing a real lock, the good
>case needs to be sufficiently much faster to really be
>a big win. Some "somewhat" faster. It needs to be an order
>of magnitude faster than taking a lock.
>So I claim that you need actual hardware support for
>the fallback position. An actual hardware predictor (which
>would look very much like a branch predictor, and I think
>you might even be able to use the same hardware), and a set
>of sane semantics that means that software can use the
>transaction hardware without having to know the exact rules
>for what can be in a transaction (because it is going to
>depend on microarchitectural details).
>Nothing I have ever seen in hardware does anything like
>that. The hardware I've seen has been very special-purpose
>and way too fragile to ever be anything but.
>And don't get me wrong. Special-purpose is fine. I don't
>think DSP's are bad just because they specialize either.
>But special-purpose hardware should be recognized as such,
>and doesn't get to play with the big boys. It's playing
>in its own little sand-box with the other kids.
>Just to give some kind of baseline: current Intel CPU's
>do an uncontended lock/unlock sequence in something like
>20 cycles. That's a real lock. Transactional memory
>needs to do better than that to play with the big boys,
>including very much the failure case. Because the common
>case is still going to be the uncontended case.
>If you need to turn it into some kind of conditional in
>software, you've already pretty much lost.
>(And yes, I realize that the advantage of transactional
>memory is when you can possibly avoid ping-pong of the
>lock cacheline itself. I do support the notion of doing
>TM. It's just that I claim that in order for it to make
>any real sense, you need to do it really well, and
>not the half-arsed crap that I've seen).

I seems that Soracle is trying to move to an "everything is in memory" approach. If everything is in memory, would this would reduce response times and thus reduce DM lock contention.

The question (finally) is: would an in memory DB enable a reduction in contention to the point that many locks can be removed and TM's benefit is minimized?
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
T3 announcedMax2010/09/21 03:42 AM
  T3 announcedsomeone2010/09/21 04:53 AM
    T3 announcedanon2010/09/21 05:05 AM
      T3 announcedlurker2010/09/21 06:11 AM
      T3 announcedJesper Frimann2010/09/21 06:21 AM
      T3 announcedPhil2010/09/21 11:59 PM
        T3 announcedMichael S2010/09/22 05:16 AM
  T3 announcedLinus Torvalds2010/09/21 06:15 AM
    T3 announcedanon2010/09/21 08:31 AM
      Transactional memory Paul A. Clayton2010/09/21 09:52 AM
        Transactional memory Linus Torvalds2010/09/21 11:21 AM
          Transactional memory Paul A. Clayton2010/09/23 06:30 AM
            Transactional memory Linus Torvalds2010/09/23 07:01 AM
              Transactional memory David Kanter2010/09/23 11:05 PM
                Transactional memory Linus Torvalds2010/09/24 06:59 AM
                  Transactional memory David Kanter2010/09/25 08:27 AM
                    'dynamic fallback'?Paul A. Clayton2010/09/25 10:28 AM
                      'dynamic fallback'?Linus Torvalds2010/09/25 12:23 PM
                        'dynamic fallback'?blaine2010/09/25 01:16 PM
                Cliff Click Jr. on Azul's HTMPaul A. Clayton2010/09/24 01:19 PM
              Transactional memory Foo_2010/09/24 02:08 AM
    T3 announcedblaine2010/09/21 10:43 AM
      no news from FujitsuMax2010/09/21 09:37 PM
Reply to this Topic
Body: No Text
How do you spell tangerine? ūüćä