Don Stewart summarised the state of play of parallel programming in Haskell at "ACM Reflections | Projections 2009". He covers strategies, Concurrent Haskell, STM, and Data Parallel Haskell: http://donsbot.wordpress.com/2009/10/17/multicore-haskell-now-acm-reflections-projections-2009/
Here is a video of Roman Leshchinskiy's talk on our work on implementing Data Parallel Haskell (DPH), which he presented at the Haskell Implementors' Workshop (co-located with ICFP'09):
Posted on Packt Publishing Article Network
In order to solve problems that arise in concurrently running threads in applications, we need new debugging techniques suitable for the new parallelism environments that occur in Visual C#. Multicore programming and parallel programming require new debugging techniques.
Learn some tricks to prepare multithreaded code to simplify the debugging and troubleshooting processes.
Posted on Intel Software Network
Sometimes, you don’t want to use all the available cores in a parallel loop. Why? Because you have better plans for the remaining available cores. Thus, you want to specify the concurrency level of a parallel loop. Luckily, Task Parallel Library Beta 1 will allow you to do this using the new ParallelOptions class.
Posted on Intel Software Network
As C# and Visual Basic (in the .Net world) and Java are high level programming languages, most developers were not used to check for some hardware information. With multicore microprocessors and a task-oriented programming model, trying to take full advantage of parallel processing capabilities offered by modern microprocessors, this is changing.
Posted on www.ddj.com/go-parallel
Management professionals love metrics. However, they don’t like the idea to optimize applications that are currently running. Thus, what about showing them some metrics about the power that they are wasting using a free tool?
Posted on Intel Software Network
In a recent post, Robert Chesebrough (Intel) talked about less focus on threads and more focus on tasks. I agree with him. I do believe that decomposing the job to be done into many tasks is the key to a successfully parallelized algorithm.
Full story: http://software.intel.com/en-us/blogs/2009/04/28/invoking-parallel-tasks/
This video uses Intel Concurrency Checker 2.1 to benchmark threading metrics on a parallelized and multithreaded C# application. Watching this video you will find out that there is an easy to use utility to test multicore optimizations in any executable.
For more information about Intel Concurrency Checker 2.1, visit: http://software.intel.com/
The application also uses AForge.NET imaging framework. For more information about AForge.NET, visit: http://www.aforgenet.com
For more information about .Net Parallel Extensions, visit: http://msdn.microsoft.com/en-us/concurrency/default.aspx
These graphs summarise the performance of Data Parallel Haskell for three simple benchmarks on two different architectures, both of which have 8 cores. At the top, we have 8 cores with one hardware thread each, in the form of two Quad-Core 3GHz Xeon processors. At the bottom, we have 8 cores with 8 hardware threads each (for a total of 64 hardware threads), in the form of a single 1.4GHz UltraSPARC T2.
The benchmarks are the following: (1) sumsq computes the parallel sum of the squares from 1 to 10 million; (2) dotp computes the dot product of two dense vectors of 100 million double-precision floating-point numbers; and (3) smvm multiplies a sparse matrix with 10 million non-zero double-precision floating-point elements with a dense vector.
The graphs show the speedup of Data Parallel Haskell with respect to a sequential C implementation of each benchmark – whenever, a curve climbs above 1 on the y-axis, the parallel Haskell program beats the sequential C program in absolute runtime.
The scalability of these three programs in Data Parallel Haskell is very good, although dotp is limited by memory bandwidth on the Quad-Core Xeon processors, as discussed in my previous post. The grey curve is a parallel C implementation of dotp that is bandwidth limited in the same manner.
This is the performance of a dot product of two vectors of 10 million doubles each using Data Parallel Haskell. Both machines have 8 cores. Each core of the T2 has 8 hardware thread contexts. The performance is memory bound. The DPH code is
dotp' :: [:Double:] -> [:Double:] -> Double dotp' v w = D.sumP (zipWithP (*) v w)
Interesting is that despite the much lower single-thread performance, the T2 makes it all up in excellent multi-threading performance. Interesting to Haskell folks is that the corresponding multi-threaded C code using pthreads is much harder to write and barely any faster when using all parallelism (the Sun C-Compiler still manages to reduce the runtime by about 30% with 64 threads, but on the Xeons, there is no significant difference).
NB: This uses the latest development version of GHC and DPH. Thanks to Ben Lippmeier for his nice work on the SPARC backend of GHC.
