Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
#7602: Threaded RTS performing badly on recent OS X (10.8?) -----------------------------------+---------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -----------------------------------+---------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"28b031c506122e28e0230a562a4f6fd3d0256d0c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="28b031c506122e28e0230a562a4f6fd3d0256d0c" Refactor GCTDecl.h, and mitigate #7602 a bit This basically cleans a lot of GCTDecl up - I found it quite hard to read and a bit confusing. The changes are mostly cosmetic: better delineation between the alternative cases and light touchups, and tries to make every branch as consistent as possible. However, this patch does have one significant effect: it will ensure that any LLVM-based compilers will use __thread if they support it. Before, they would simply always use pthread_getspecific and pthread_setspecific, which are almost surely even *more* inefficient. The details are a bit too long and boring to go into here; see #7602. After talking with Simon, we decided to play it safe - __thread can at least be optimized by future clang releases even further on OS X if they choose, and it's safer until we can investigate the pthread implementation further on Mavericks. For Linux, the story isn't so bleak if you use Clang (for whatever reason) - Linux directly writes to `%fs` for __thread slots (while OS X will perform a load followed by an indirect call.) So it should still be fairly competitive, speed-wise. Signed-off-by: Austin Seipp <austin@well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC