awesome! (this will also make my work easier) ryan: github is down, could you put the branch on bitbucket or some such so I can have a lookseee/clone locally?
thanks! -Carter On Sat, Aug 3, 2013 at 4:01 AM, Ryan Newton <rrnew...@gmail.com> wrote: > Just to keep you all up to date... I'm adding the primops in question and > validating the individual commits before putting them here: > > https://github.com/rrnewton/ghc/commits/atomicPrimOps > > The basic idea for using these extensions is: > > - the atomic-primops library will work in 7.6 or 7.7+. It will use > ifdefs to decide whether to use its own primops or GHC-builtin > - future versions will simply get faster, as Carter replaces > out-of-line primops that *also* use C calls, with inline primops / LLVM > equivalents > > Shall I stick a patch on a ticket, or will someone volunteer to pull? > What's the protocol for requesting commit access anyway? (By the way, can > someone share the reason that pull-requests to the github ghc mirror are > such a no-no? They seem no worse than a patch in an email which the big > warning > sign <https://github.com/ghc/ghc> recommends.) > > Best, > -Ryan > > P.S. FYI, I'm periodically getting these: > > 0 caused framework failures > 0 unexpected passes > 1 unexpected failures > > Unexpected failures: > perf/compiler T1969 [stat not good enough] (normal) > > Can that just be because of running on a loaded machine? How narrow are > these windows? > > > On Thu, Aug 1, 2013 at 12:32 PM, Ryan Newton <rrnew...@gmail.com> wrote: > >> On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald < >> carter.schonw...@gmail.com> wrote: >> >>> ok, could you add those comments (about additional operations to >>> consider) to the ticket? >>> >> >> Sure. Just did that. >> >> >>> relatedly: if we want these atomic ops to use the sequential analogues >>> when we're not using the threaded run time system, does that mean >>> we need to have a symbol / constant variable exposed in the RTS we link >>> in, so that the inline code branches on a linktime constant value / symbol >>> (something like "isThreadedRTS:: Bool", ) or some sort of analogue >>> thereof? >>> >> >> I think it will take some care to mimic the semantics perfectly. Why not >> just leave the real atomic ops even in non-threaded mode, at least at >> first? Later we can optimize it if we find that people are using >> concurrent data structures heavily in non-threaded mode ;-). >> >> >>> one nice thing about doing such, is that if at some point link time >>> optimization is added, the branch would go away! On the other hand, it >>> could be argued that the cost of the call to the CAS primops in their >>> current form isn't that much more expensive than such a branch. >>> >> >> Indeed, I'm much more concerned about performance in the threaded case >> and making sure they're correct. >> >> > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
