took a quick look, awesome! this will make it MUCH MUCH easier for me to
do my work. Thank you very much.
off hand, to prevent patch confusion,
it naively seems like the nicest way to post the patches to trac is to
post a *new ticket to trac* that links to the main one,
plus add a comment on the main ticket a link to the new ticket for the
c/cmm based versions of the primops.
At least, given that theres likely going to be a bit of discussion on just
your ticket perhaps, better to factor that into a related ticket to make it
easier to keep track of that?
(i'm also possibly over thinking this enormously, so i could be way off
base)
On Sat, Aug 3, 2013 at 9:31 PM, Carter Schonwald wrote: nvm, githubs backup, i'll have a look! :) On Sat, Aug 3, 2013 at 9:05 PM, Carter Schonwald <
carter.schonwald@gmail.com> wrote: 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 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 On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald <
carter.schonwald@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.