Proposal: provide cas and barriers symbols even without -threaded
carter.schonwald at gmail.com
Sun Aug 4 03:31:19 CEST 2013
nvm, githubs backup, i'll have a look! :)
On Sat, Aug 3, 2013 at 9:05 PM, Carter Schonwald <carter.schonwald at gmail.com
> 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?
> On Sat, Aug 3, 2013 at 4:01 AM, Ryan Newton <rrnewton at 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:
>> 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
>> 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.)
>> 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 <rrnewton at gmail.com> wrote:
>>> On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald <
>>> carter.schonwald at 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
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs