[GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)

[GHC]

#7602: Threaded RTS performing badly on recent OS X (10.8?)
-------------------------------------+-------------------------------------
        Reporter:  simonmar          |            Owner:  thoughtpolice
            Type:  bug               |           Status:  new
        Priority:  highest           |        Milestone:  7.8.3
       Component:  Runtime System    |          Version:
      Resolution:                    |         Keywords:  thread-local
Operating System:  MacOS X           |  state, TLS clang
 Type of failure:  Runtime           |     Architecture:  x86_64 (amd64)
  performance bug                    |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:  7678
        Blocking:                    |  Related Tickets:
-------------------------------------+-------------------------------------

Comment (by thoughtpolice):

 For those who didn't follow the list:

   - Mark Seaborn, a !Chromium/NaCl engineer, stated that they have this
 exact same problem in Native Client on 64bit OS X. In particular, they
 came up with the same solution I did essentially: inline the fast path of
 `pthread_{get,set}specific`. Their code is more robust than my patch
 however, as it's actually paranoid enough to check the machine code and
 bail otherwise:
 https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/service_runtime/arch/x86_64/nacl_tls_64.c?revision=11149
  I think this is probably the best approach at the moment
  - Renato Golin, the proposer of the initial change, updated me to say
 that their updated proposal does include register variables for general
 purpose registers (GPRs), but it's only one part of the overall set of
 changes, which will take more time (their particular motivation now seems
 to be as a principled approach to defining `__builtin_return_address` and
 friends at the moment). However, they understand that proposal doesn't
 accommodate our design, and would like us to give more feedback as they
 evolve the work to support true register variables.

 So, in the long haul, I think things will get better here. In the mean
 time, I think this is a signal that we should go ahead and jump on the
 fast-path-inline change I spoke of in comment 13.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:44>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler