Hi, I'd like to get more involved in parallel programming in Haskell, and I have access to an SGI Altix machine (a shared-memory multiprocessor). Can someone tell me, if I download a 64-bit GHC 6.5 snapshot, to what extent will parallelism "just work"? Specifically, I'm interested in * parallel evaluation strategies * nested data parallelism * forkIO, MVar's, and STM My understanding is that for the 32-bit version, this all works in parallel, but GC is sequential. Is that still the case? Is the 64-bit version in the same state? Finally, is there an estimated date for when 6.6 will be available? I'm happy to experiment with snapshots, but most admins around here are much more comfortable installing an official release of some sort. Thanks! -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx
Chad Scherrer wrote:
I'd like to get more involved in parallel programming in Haskell, and I have access to an SGI Altix machine (a shared-memory multiprocessor). Can someone tell me, if I download a 64-bit GHC 6.5 snapshot, to what extent will parallelism "just work"? Specifically, I'm interested in * parallel evaluation strategies * nested data parallelism * forkIO, MVar's, and STM
My understanding is that for the 32-bit version, this all works in parallel, but GC is sequential. Is that still the case? Is the 64-bit version in the same state?
nested data parallelism: not yet. forkIO, MVars, STM, par, and strategies are all working in 6.5 right now. throwTo is not working on multiple CPUs yet. There shouldn't be any difference between 32 and 64 bit support.
Finally, is there an estimated date for when 6.6 will be available? I'm happy to experiment with snapshots, but most admins around here are much more comfortable installing an official release of some sort.
We don't have a firm schedule, as usual it's "when it's done". To get an idea of what is still to be done, these tickets are scheduled for 6.6: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.6&order=priority as a rough guide, I'd like to get 6.6 out sometime this summer, and definitely before ICFP/Haskell Workshop/GHC Hackathon. Cheers, Simon
On Mon, 2006-05-08 at 12:19 +0100, Simon Marlow wrote:
My understanding is that for the 32-bit version, this all works in parallel, but GC is sequential. Is that still the case? Is the 64-bit version in the same state?
nested data parallelism: not yet. forkIO, MVars, STM, par, and strategies are all working in 6.5 right now. throwTo is not working on multiple CPUs yet.
There shouldn't be any difference between 32 and 64 bit support.
Ok, great. Is is correct that the GC is still sequential? Are there particular difficulties in getting NDP and parallel GC working, or is it just a matter of having so many other pieces to work on? Thanks, Chad
Chad Scherrer wrote:
On Mon, 2006-05-08 at 12:19 +0100, Simon Marlow wrote:
My understanding is that for the 32-bit version, this all works in parallel, but GC is sequential. Is that still the case? Is the 64-bit version in the same state?
nested data parallelism: not yet. forkIO, MVars, STM, par, and strategies are all working in 6.5 right now. throwTo is not working on multiple CPUs yet.
There shouldn't be any difference between 32 and 64 bit support.
Ok, great. Is is correct that the GC is still sequential? Are there particular difficulties in getting NDP and parallel GC working, or is it just a matter of having so many other pieces to work on?
NDP is being actively worked on by Roman Leshchinskiy and Manuel Chakravarty. The GC is currently single-threaded, but we have an intern who started here this week (Roshan James) who is working on a parallel implementation of the GC. Cheers, Simon
Hello Simon, Wednesday, May 10, 2006, 4:12:18 PM, you wrote:
The GC is currently single-threaded, but we have an intern who started here this week (Roshan James) who is working on a parallel implementation of the GC.
GREAT! if you browse Intel/AMD news, you should know that they plan to double number of cores each two years (anyway, it's a Moore law) so it's possible that Haskell will become best application programming language just because it simplifies using of all these cores together moreover, afaiu, this means that ghc-compiled programs will no more stall for several seconds doing major GC that is also very important for any user-interactive program (especially games :) ) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
moreover, afaiu, this means that ghc-compiled programs will no more stall for several seconds doing major GC that is also very important for any user-interactive program (especially games :) )
Unfortunately it won't completely remove the latency of a major GC, although latency will be reduced because the GC is quicker (hopefully). Parallel GC is when the whole system stops and performs multi-threaded GC, as opposed to "concurrent GC", which is when the GC runs concurrently with the program. We think concurrent GC is unlikely to be practical in the Haskell setting, due to the extra synchronisation needed in the mutator. However, there may always be clever techniques that we haven't discovered, and synchronisation might become less expensive, so the balance may change in the future. Cheers, Simon
participants (3)
-
Bulat Ziganshin -
Chad Scherrer -
Simon Marlow