Changes between Version 29 and Version 30 of Status/May09


Ignore:
Timestamp:
May 1, 2009 11:56:35 PM (5 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Status/May09

    v29 v30  
    7070=== Data Parallel Haskell === 
    7171 
    72 DPH remains under very active development. The [wiki:DataParallel current state of play] is documented on the wiki.  We also wrote a substantial paper [http://research.microsoft.com/~simonpj/papers/ndp Harnessing the multicores: nested data parallelism in Haskell] for FSTTCS; you may find this paper a useful tutorial on the whole idea of nested data parallelism. 
     72DPH remains under very active development by Manuel Chakravarty, Gabriele Keller, Roman Leshchinskiy, and Simon Peyton Jones. The [wiki:DataParallel current state of play] is documented on the wiki.  We also wrote a substantial paper [http://research.microsoft.com/~simonpj/papers/ndp Harnessing the multicores: nested data parallelism in Haskell] for FSTTCS; you may find this paper a useful tutorial on the whole idea of nested data parallelism. 
    7373 
    74 The system currently works well for small programs, such as computing a dot product or the product of a sparse matrix with a dense vector.  For such applications, the generated code is as close to hand written C code as GHC's current code generator enables us to be.  We ran three small benchmarks on an 8-core x86 server and on an 8-core UltraSPARC T2 server, from which we derived two comparative figures: [http://justtesting.org/post/83014052/this-is-the-performance-of-a-dot-product-of-two comparison between x86 and T2 on a memory-intensive benchmark (dot product)] and [http://justtesting.org/post/85103645/these-graphs-summarise-the-performance-of-data a performance summary of the benchmarks on both machines.] 
     74The system currently works well for small programs, such as computing a dot product or the product of a sparse matrix with a dense vector.  For such applications, the generated code is as close to hand written C code as GHC's current code generator enables us to be (i.e., within a factor of 2 or 3).  We ran three small benchmarks on an 8-core x86 server and on an 8-core UltraSPARC T2 server, from which we derived two comparative figures: [http://justtesting.org/post/83014052/this-is-the-performance-of-a-dot-product-of-two a comparison between x86 and T2 on a memory-intensive benchmark (dot product)] and [http://justtesting.org/post/85103645/these-graphs-summarise-the-performance-of-data a summary of the speedup of three benchmarks on x86 and T2.] Overall, we achieved good absolute performance and good scalability on the hardware we tested. 
     75 
     76Our next step is to scale the implementation up to properly handle larger programs.  In particular, we are currently working on improving the interaction between vectorised code, the aggressively inlining array library, and GHC's standard optimisation phases with the goal of reducing excessively long compile times due to a temporary code explosion during optimisation.  Moreover, Gabriele started to look at integrating specialised support for regular multi-dimensional arrays into the existing framework for nested data parallelism. 
    7577 
    7678=== Type system improvements ===