2

I have implemented the Euler symplectic method using repa. It is a pretty simple method. Sadly the performance I am getting is not as good as I would have hoped. The repa guys have been very helpful (Ben Lippmeier in particular) and I have followed his advice on inlining and adding strictness annotations. Unfortunately these do not seem to have helped. I am producing the core with

ghc --make -O2 RepaOnly.hs -main-is RepaOnly -ddump-prep -dsuppress-all -dppr-case-as-let -dppr-cols200 > RepaOnly.hcr

Sadly this seems to be quite large and I am currently not sure how to proceed. I thought the wider Haskell community might have some ideas on how to debug this or point out where I am going wrong.

The code is here: https://gist.github.com/idontgetoutmuch/6209752

I can also post the core in a gist if that is helpful.

idontgetoutmuch
  • 1,621
  • 11
  • 17
  • I should have said that this is an update from http://stackoverflow.com/questions/18099878/repa-performance-for-planetary-simulation – idontgetoutmuch Aug 12 '13 at 10:41
  • Hi. I was able to squeeze a little bit more out by changing extend, traverse, backpermute and index to their unsafe versions ( http://hackage.haskell.org/packages/archive/repa/3.2.3.3/doc/html/Data-Array-Repa-Unsafe.html ) but it still isn't particularly good. – Amos Robinson Aug 12 '13 at 11:31
  • Compiling with -fllvm -optlo-O3 helps a bit, too – Amos Robinson Aug 12 '13 at 11:37
  • Have you tried drilling down via profiling? I haven't had time for anything more than a brief inspection, but `stepMomentumP` was responsible for > 90% of the time and allocation of the program. – jtobin Aug 13 '13 at 20:31
  • Sadly I haven't had time to do this and won't have for at least a week. I am starting to suspect that this problem isn't suitable for repa. When I think about the problem, every planet is acted upon by every other planet and it's not clear to me that this is amenable to something that works on grids. – idontgetoutmuch Aug 14 '13 at 21:18

0 Answers0