Design discussion for atomic primops to land in 7.8

[Ryan Newton]

Well, what's the long term plan?  Is the LLVM backend going to become the
only backend at some point?



On Thu, Aug 22, 2013 at 1:43 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey Ryan,
> you raise some very good points.
>
> The most important point you raise (I think) is this:
> it would be very very nice to (where feasible) to add analogous machinery
> to the native code gen, so that its not falling behind the llvm one quite
> as much.
>
> at least for these atomic operations (unlike the SIMD ones),
> it may be worth investigating whats needed to add those to the native code
> gen as well.
>
> (adding simd support on the native codegen would be nice too, but probably
> *substantially *more work)
>
>
>
> On Thu, Aug 22, 2013 at 11:40 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> There's a ticket that describes the design here:
>>     http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1
>> It is a fairly simple extension of the casMutVar# that has been in since
>> 7.2.  The implementation is on the `atomics` branch currently.
>>
>> Feel free to add your views either here or on that task's comments.
>>
>> One example of an alternative design would be Carter's proposal to expose
>> something closer to the full LLVM concurrency ops<http://llvm.org/docs/Atomics.html>
>> :
>>
>> Schonwald <carter.schonwald at gmail.com> wrote:
>>
>>> i'm kinda thinking that we should do the analogue of exposing all the
>>> different memory model level choices (because its not that hard to add
>>> that), and when the person building it has an old version of GCC, it falls
>>> back to the legacy atomic operations?
>>>
>>> This also gives a nice path to how to upgrade to the inline asm approach.
>>>
>>
>> These LLVM ops include many parameterized configurations of loads,
>> stores, cmpxchg, atomicrmw and barriers.  In fact, it implements much more
>> than is natively supported in most hardware, but it provides a uniform
>> abstraction.
>>
>> My original thought was that any kind of abstraction like that would be
>> built and maintained as a Haskell library, and only the most rudimentary
>> operations (required to get access to process features) would be exposed as
>> primops.  Let's call this the "small" set of concurrent ops.
>>
>> If we want the "big set" I think we're doomed to *reproduce* the logic
>> that maps LLVM concurrency abstractions onto machine ops irrespective of
>> whether those abstractions are implemented as Haskell functions or as
>> primops:
>>
>>    - If the former, then the Haskell library must map the full set of
>>    ops to the reduced small set (just like LLVM does internally)
>>    - If we instead have a large set of LLVM-isomorphic primops.... then
>>    to support the same primops *in the native code backend *will, again,
>>    require reimplementing all configurations of all operations.
>>
>> Unless... we want to make concurrency ops something that require the LLVM
>> backend?
>>
>> Right now there is not a *performance* disadvantage to supporting a
>> smaller rather than a larger set of concurrency ops (LLVM has to emulate
>> these things anyway, or "round up" to more expensive ops).  The scenario
>> where it would be good to target ALL of LLVMs interface would be if
>> processors and LLVM improved in the future, and we automatically got the
>> benefit of better HW support for some op on on some arch.
>>
>> I'm a bit skeptical of that proposition itself, however.  I personally
>> don't really like a world where we program with "virtual operations" that
>> don't really exist (and thus can't be *tested* against properly).
>>  Absent formal verification, it seems hard to get this code right anyway.
>>  Errors will be undetectable on existing architectures.
>>
>>   -Ryan
>>
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130822/9919a7d3/attachment.htm>