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 <[email protected]> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
