changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)

Carter Schonwald
hey All,

I'm starting to dig into what are tasks i could do to help contribute to
ghc, and also let me further familiarize myself with the code base so that
i can later undertake  more ambitious contributions.

One relatively simple task that I think might be valuable would be to have
cas be a cmm primop on the llvm backend.

Doing so would simplify porting ghc to new architectures supported by llvm,
AND I believe that it might improve ghc haskell  performance on certain
concurrent workloads, because currently the compare and exchange op isn't
inlined into functions using it, such as atomicModifyMutVar, so theres a c
call to cas in an otherwise pretty tight loop. It would also potentially
pave the way to providing other interesting atomicity primitives leveraging
llvm too. (I think)


heres the ticket i've open on this matter
http://hackage.haskell.org/trac/ghc/ticket/7883

This is something I'd be interested in doing as a warmup project, though
i'll need help benchmarking if theres any performance improving on heavy
concurrent work loads, as I don't have access to beefy hardware presently.


is this sort of exploratory engineering / change something that the
community / ghc devs are open to? (I'd like to make sure any wee starter
project I do to get my feet wet has some potential to actually get merged
into ghc should it work out)

it looks like it'd be a relatively tractable first project that touches a
lot of the backend bits on ghc too, which would be interesting.

thanks and any feedback/ideas/suggestions would be wonderful /  appreciated

-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130503/9f50724e/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)

David Terei
Sounds good. I am not familiar with the current implementation of CAS and
the trade-offs but in principle moving to a CallishMachOp sounds right. You
can look at previous examples of this that Johan and I have done in the
past to support things like popcnt efficiently:

2906db6c3a3f1000bd7347c7d8e45e65eb2806cb
2d0438f329ac153f9e59155f405d27fac0c43d65

Implementing the change shouldn't be that hard, mostly it'll probably just
be a challenge getting familiar with GHC if you aren't already, but a
change like this has good documentation and prior examples to work from. A
CallishMachOp should allow you to probably just use the existing
implementation to start but with the code gen now knowing more info. This
as a stepping stone will ensure correctness, then you can look at
implementing backend specific versions that are optimized and produce
direct code so they are inlined.

Cheers,
David



On 3 May 2013 11:55, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> hey All,
>
> I'm starting to dig into what are tasks i could do to help contribute to
> ghc, and also let me further familiarize myself with the code base so that
> i can later undertake  more ambitious contributions.
>
> One relatively simple task that I think might be valuable would be to have
> cas be a cmm primop on the llvm backend.
>
> Doing so would simplify porting ghc to new architectures supported by
> llvm, AND I believe that it might improve ghc haskell  performance on
> certain concurrent workloads, because currently the compare and exchange op
> isn't inlined into functions using it, such as atomicModifyMutVar, so
> theres a c call to cas in an otherwise pretty tight loop. It would also
> potentially pave the way to providing other interesting atomicity
> primitives leveraging llvm too. (I think)
>
>
> heres the ticket i've open on this matter
> http://hackage.haskell.org/trac/ghc/ticket/7883
>
> This is something I'd be interested in doing as a warmup project, though
> i'll need help benchmarking if theres any performance improving on heavy
> concurrent work loads, as I don't have access to beefy hardware presently.
>
>
> is this sort of exploratory engineering / change something that the
> community / ghc devs are open to? (I'd like to make sure any wee starter
> project I do to get my feet wet has some potential to actually get merged
> into ghc should it work out)
>
> it looks like it'd be a relatively tractable first project that touches a
> lot of the backend bits on ghc too, which would be interesting.
>
> thanks and any feedback/ideas/suggestions would be wonderful /  appreciated
>
> -Carter
>
> _______________________________________________
> 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/20130503/ece43b6f/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

FW: changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)

Simon Peyton Jones
Simon: any opinions about this?  (Adding CAS as a primop for LLVM.)  Isn't CAS *already* a primop?  casMutVar#

Simon

From: ghc-devs-bounces at haskell.org [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Terei
Sent: 03 May 2013 22:11
To: Carter Schonwald
Cc: ghc-devs at haskell.org
Subject: Re: changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)

Sounds good. I am not familiar with the current implementation of CAS and the trade-offs but in principle moving to a CallishMachOp sounds right. You can look at previous examples of this that Johan and I have done in the past to support things like popcnt efficiently:

2906db6c3a3f1000bd7347c7d8e45e65eb2806cb
2d0438f329ac153f9e59155f405d27fac0c43d65

Implementing the change shouldn't be that hard, mostly it'll probably just be a challenge getting familiar with GHC if you aren't already, but a change like this has good documentation and prior examples to work from. A CallishMachOp should allow you to probably just use the existing implementation to start but with the code gen now knowing more info. This as a stepping stone will ensure correctness, then you can look at implementing backend specific versions that are optimized and produce direct code so they are inlined.

Cheers,
David


On 3 May 2013 11:55, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
hey All,

I'm starting to dig into what are tasks i could do to help contribute to ghc, and also let me further familiarize myself with the code base so that i can later undertake  more ambitious contributions.

One relatively simple task that I think might be valuable would be to have cas be a cmm primop on the llvm backend.

Doing so would simplify porting ghc to new architectures supported by llvm, AND I believe that it might improve ghc haskell  performance on certain concurrent workloads, because currently the compare and exchange op isn't inlined into functions using it, such as atomicModifyMutVar, so theres a c call to cas in an otherwise pretty tight loop. It would also potentially pave the way to providing other interesting atomicity primitives leveraging llvm too. (I think)


heres the ticket i've open on this matter
http://hackage.haskell.org/trac/ghc/ticket/7883

This is something I'd be interested in doing as a warmup project, though i'll need help benchmarking if theres any performance improving on heavy concurrent work loads, as I don't have access to beefy hardware presently.


is this sort of exploratory engineering / change something that the community / ghc devs are open to? (I'd like to make sure any wee starter project I do to get my feet wet has some potential to actually get merged into ghc should it work out)

it looks like it'd be a relatively tractable first project that touches a lot of the backend bits on ghc too, which would be interesting.

thanks and any feedback/ideas/suggestions would be wonderful /  appreciated

-Carter

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto: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/20130509/dc61cbea/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130509/dc61cbea/attachment.txt>

Reply | Threaded
Open this post in threaded view
|

FW: changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)

Simon Marlow-7
It's a good idea, go for it.  David's right - a CCallishMachOp is the
right way to do it.

Simon: we have casMutVar# which is a Haskell-level primop to do a cas on
a MutVar#, but what Carter is talking about is a Cmm-level primitive
that we could use in both compiler-generated and hand-written Cmm code.
  There are many of these that we could add aside from CAS, but adding
CAS would be a step in the right direction.

Cheers,
        Simon


On 09/05/13 09:31, Simon Peyton-Jones wrote:

> Simon: any opinions about this?  (Adding CAS as a primop for LLVM.)
> Isn?t CAS **already** a primop?  casMutVar#
>
> Simon
>
> *From:*ghc-devs-bounces at haskell.org
> [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *David Terei
> *Sent:* 03 May 2013 22:11
> *To:* Carter Schonwald
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: changing ghc llvm backend to use the llvm provide cas /
> rmw primops (task i'd like to explore)
>
> Sounds good. I am not familiar with the current implementation of CAS
> and the trade-offs but in principle moving to a CallishMachOp sounds
> right. You can look at previous examples of this that Johan and I have
> done in the past to support things like popcnt efficiently:
>
> 2906db6c3a3f1000bd7347c7d8e45e65eb2806cb
>
> 2d0438f329ac153f9e59155f405d27fac0c43d65
>
> Implementing the change shouldn't be that hard, mostly it'll probably
> just be a challenge getting familiar with GHC if you aren't already, but
> a change like this has good documentation and prior examples to work
> from. A CallishMachOp should allow you to probably just use the existing
> implementation to start but with the code gen now knowing more info.
> This as a stepping stone will ensure correctness, then you can look at
> implementing backend specific versions that are optimized and produce
> direct code so they are inlined.
>
>
> Cheers,
>
> David
>
> On 3 May 2013 11:55, Carter Schonwald <carter.schonwald at gmail.com
> <mailto:carter.schonwald at gmail.com>> wrote:
>
> hey All,
>
> I'm starting to dig into what are tasks i could do to help contribute to
> ghc, and also let me further familiarize myself with the code base so
> that i can later undertake  more ambitious contributions.
>
> One relatively simple task that I think might be valuable would be to
> have cas be a cmm primop on the llvm backend.
>
> Doing so would simplify porting ghc to new architectures supported by
> llvm, AND I believe that it might improve ghc haskell  performance on
> certain concurrent workloads, because currently the compare and exchange
> op isn't inlined into functions using it, such as atomicModifyMutVar, so
> theres a c call to cas in an otherwise pretty tight loop. It would also
> potentially pave the way to providing other interesting atomicity
> primitives leveraging llvm too. (I think)
>
> heres the ticket i've open on this matter
>
> http://hackage.haskell.org/trac/ghc/ticket/7883
>
> This is something I'd be interested in doing as a warmup project, though
> i'll need help benchmarking if theres any performance improving on heavy
> concurrent work loads, as I don't have access to beefy hardware presently.
>
> is this sort of exploratory engineering / change something that the
> community / ghc devs are open to? (I'd like to make sure any wee starter
> project I do to get my feet wet has some potential to actually get
> merged into ghc should it work out)
>
> it looks like it'd be a relatively tractable first project that touches
> a lot of the backend bits on ghc too, which would be interesting.
>
> thanks and any feedback/ideas/suggestions would be wonderful /  appreciated
>
> -Carter
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>