GHC Trac Home
GHC Git Repos
Working on GHC
Mailing Lists & IRC
The GHC Team
All Feature Req's
Tickets I Created
Patches for review
New Feature Req
side by side
lines around each change
Show the changes in full context
White space changes
May 10, 2012 10:16:30 AM (
Finally, we are about to release (it may be out by the time you read this) a stable, end-user ready version of the Repa-like array library Accelerate for GPU computing on Hackage. It integrates with Repa, so you can mix GPU and CPU multicore computing, and via the new `meta-par` package you can share workload between CPUs and GPUs . This new version 0.12 is already available on !GitHub . You need a CUDA-capable NVIDIA GPU to use it.
* '''Lightweight concurrency substrate''' (Sivaramakrishnan Krishnamoorthy Chandrasekaran, aka "KC"). During his internship at MSR Cambridge, KC has been working on replacing the RTS scheduler with some APIs that enable the scheduler to be implemented in Haskell. The aim is to not just move the scheduler into Haskell, but also enable user-defined schedulers to coexist, which will ultimately enable much greater control over scheduling behaviour. This follows on from previous work  with Peng Li and Andrew Tolmach, but this time we are taking a slightly different approach that has a couple of important benefits.
Firstly, KC found a way to enable concurrency abstractions to be defined without depending on a particular scheduler. This means for example that we can provide `MVar`s that work with any user-defined scheduler, rather than needing one `MVar` implementation per scheduler. Secondly, we found ways to coexist with some of the existing RTS machinery for handling blackholes and asynchronous exceptions in particular, which means that these facilities will continue to work as before (with the same performance), and writers of user-defined schedulers do not need to worry about them. Furthermore this significantly lowers the barrier for writing a new scheduler.
This is all still very much experimental, and it is not clear whether it will ever be in GHC proper. It depends on whether we can achieve good enough performance, amongst other things. All we can say for now is that the approach is promising. You can find KC's work on the `ghc-lwc` branch of the git repo.
 [http://hackage.haskell.org/trac/ghc/query?status=closed&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=component&milestone=7.4.2&resolution=fixed] [[BR]]
 [http://parfunk.blogspot.com.au/2012/05/how-to-write-hybrid-cpugpu-programs.html] [[BR]]
 [https://github.com/AccelerateHS/accelerate] [[BR]]