TL;DR OS X suffers a performance hit when build with llvm-gcc/clang. The binary builds are built this way. The fix I outlined in the ticket (a fast `pthread_getspecific`/`pthread_setspecific`) could still work to recover most of the performance, but Apple accidentally messed up the Mavericks source code release, so I'm not sure if anything regarding the pthread implementation has changed. If it hasn't, then I think it should be reasonably easy to fix with some testing.
(The ticket is a bit of a long and dry read I'm afraid.) On Tue, Feb 4, 2014 at 3:22 PM, Andrew Farmer <[email protected]> wrote: > I know that #7602 has been mentioned as a final loose end in the RC. I was > wondering if someone in the know could summarize its status in regards to > how it effects GHC users. > > Feel free to be blisteringly brief... ;-) I'm just looking for things like: > "this is a non-issue on modern OS X/Clang" or "it'll be fixed soon just be > patient" or "we've done our part, this is Apple's problem now". > > I gave the trac thread a read-through, but there seems to be several degrees > of flexibility/workarounds, so I'm still not sure if this is something I > should worry about on my OS X machine. > > Thanks for your cycles! > Andrew > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
