Version 8 (modified by chak, 7 years ago) (diff)


Plan for the December 2010 Release

To be released components

  • GHC 7.0.2
  • DPH packages
  • Repa packages

(No release of vector should be necessary, as 0.7.01 should work fine.)

Before the release we must achieve the following


API adaptation: APIs of vector, Repa, and Accelerate should be unified as far as possible

  • Repa's current 'replicate' should be renamed and a new 'replicate' that turns a scalar into an array should be introduced ???
  • Check similarity of singleton/unit between all three libraries ???


  • -fdph-par should be the default [MANUEL]
  • -fvectorise should imply -Odph (if omitted, we get fatal errors) [MANUEL]
    • rl notes, "We shouldn't! -fvectorise -O0 should work, I'll take a look. I should change -Odph to reflect what we currently need, though. Basically, it should be equivalent ot -O2 -fsimplifier-phases=3 -fsimplifier-iterations=20."
  • Move GHC.PArr into the DPH libs. (Needed for Haddock.) [MANUEL]
  • Find out if we still need the NoSpecConstr annotation and remove it if not [ROMAN]

Bug fixes:

  • Repa edge-detection is deadlocking with more than 2 threads [DONE]
  • Fix the BH seg fault in DPH. Roman has found the problem [DONE]
  • LLVM back end not working with DPH [BEN]

Performance goals:

  • Vector works fast, sequentially, compared to C, Haskell mutable-array version [FINE]
    • Benchmarks: NoSlow, vector versions of Repa benchmarks
  • Repa works fast in parallel
    • MMult [OK, but about 20% slower than in 6.13; try with LLVM and w/o bounds checks] [BEN]
    • Laplace [SLOW & DOESN'T SCALE] [BEN]
    • Blur [OK]
    • EdgeDetect [OK]
    • FFT [OK]
  • Statically-nested DPH programs should work fast, in parallel
    • SumSquares [FINE]
    • Dot product [FINE]
    • Evens '[OK (but more than 3 times slower than C)]'
      • rl reckons this is due to GHC compiling modulo of powers of two inefficiently; c.f., #3065 (in packByTags)
    • SMVM [SLOW (lack of fusion)] [BEN & ROMAN]
  • Dynamically-nested DPH programs without user-defined datatypes should run correctly, but not necessarily fast
    • Quicksort [BROKEN (SpecConstr) & SLOW] [SIMON & BEN]
    • Quickhull [OK, but has a SpecConstr problem that we want to fix] [ROMAN]
      • Probably affected by the same optimisation issue with the compilation of modulo operations as Evens
  • Dynamically-nested DPH programs with user-defined datatypes should run correctly, but not necessarily fast
    • Words [BROKEN (SpecConstr)] [SIMON]
    • BarnesHut [OK]


Works well
Fine for the release, but could be better
Not usable

Tags in bold require attention before the release.

More benchmarks details at DataParallel/BenchmarkStatus