Design discussion for atomic primops to land in 7.8

[Carter Schonwald]

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/a45c2e77/attachment.htm>