On Thursday 24 December 2009 02:55:33 you wrote:

The Haskell Platform is currently the recommended way to go, but it won't be up on GHC 6.12 until some time in the new year (I don't know their timelines).

I see, thanks.

For me, I didn't have a working GHC 6.12 setup until this morning. The compiler is ready, but we're still working on moving the libraries over to the new major version.

Maybe compiling your own 6.10.4 would be the best choice until the next platform release.

Is that better than using the 6.10.4 from Debian (and the haskell-platform package)?

If you're willing to dive in, the version of cabal-install that works for GHC 6.12.1 is out now, but it does require some boot-strapping to get going, as GHC no longer ships libraries that aren't required to build GHC.

Yeah, I tried installing cabal from source as well but couldn't get it to work either.

But back to the GHC panic, it might be worth posting that error to the GHC-users list I mentioned earlier.

I cannot reproduce it with GHC 6.10 so it has probably long since been fixed (6.8 is two years old!). -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Thu, Dec 24, 2009 at 10:09 AM, Tom Davie wrote:

The mergesort example given here has a rather nasty problem – it creates sparks for mergeing the two lists at the same time as it creates the lists, so there's always at least one task blocking waiting for it's producers.

Don't worry too much about this thread, here is why : - Jon Harrop is definitely not a beginner in Haskell land and has no business asking this question on this list - Jon Harrop is very well known on established functional programming mailing lists and forum as a very disagreeable troll (not only on Haskell). He love to trash whatever language hasn't his favours at the moment (I think right now he likes F#, which is a very interesting language nonetheless). - He apparently made an effort to include approximately all elements that could hurt Haskell reputation in this thoughtful gift to the community in this Christmas period : ** As you pointed the initial code he chose doesn't parallelize very well basically ** He tried to compile it with GHC 6.8 which was an important step towards better internals to handle parallelism in GHC but was also a time of big upheaval in this field and so not as stable as one could wish. ** He then installed GHC 6.10 and did not even clean up his previous compilations attempts before declaring that it didn't work (the error message he cited is usually observed when GHC encounters an interface file created by a previous version of GHC or on another architecture) at all without testing on some other clean sources. ** He then apparently decided that using a binary package for the 6.12 version was beneath its dignity and went on to install it from source (generally not recommended except for GHC developers that needs to work on the code or for port to unusual architectures) and claimed that there was a "circularity problem" since its 6.10 could not compile it (which it obviously could, as he discovered and qualified as "miraculous", not even considering that he had a working 6.8 before). I could choose to believe that Harrop really is as incompetent as he sounds and really did encounter all those problems (which are all possibles if unlikely to be met in quick succession) but the simple fact that he decided to post this message on the Haskell-Beginner list instead of the Haskell-cafe list where he's already well known and an occasional poster makes it that much more unlikely. The other interpretation is that JdH is up to his usual tricks, just sinking to a new low by posting in a venue where he's less likely to be recognized and more likely to worry unwary would-be-haskell-beginners. Merry Christmas ! -- Jedaï

On Thursday 24 December 2009 09:09:41 you wrote:

The mergesort example given here has a rather nasty problem – it creates sparks for mergeing the two lists at the same time as it creates the lists, so there's always at least one task blocking waiting for it's producers.

I see. So the sparks either contend for locks on the thunks to force that list or they repeat the same work.

This variation on a theme goes roughly twice as fast for me with -N1, and *does* get a speedup from -N<somethinghigher>:

mergesort [] = [] mergesort [x] = [x] mergesort [x,y] = if x < y then [x,y] else [y,x] mergesort xs = (forceList sleft) `par` (forceList sright) `pseq` merge sleft sright where (left,right) = split (length xs `div` 2) xs sleft = mergesort left sright = mergesort right

Note the `pseq` not `par` before the merge.

Can you explain why that helps?

I also added one more short-circuit case – we want to avoid spawning threads for tiny tasks like sorting 1 element lists.

This is something that concerns me. Lots of discussions of parallelism, including the Haskell literature I have read, neglect this critical problem of making sure that more time is spent doing useful work than spawning tasks (sparks). How is this solved in Haskell? Do you just put magic numbers in that work on the machine you're currently using? Also, how much work does a Haskell thread usually have to do to make it worth sparking?

Here's my results on a dual core running OS X:

LappyBob:~ tatd2$ time ./test +RTS -N1 -0.117109518058233

real 0m4.608s user 0m4.400s sys 0m0.189s LappyBob:~ tatd2$ time ./test +RTS -N2 -0.117109518058233

real 0m3.648s user 0m6.360s sys 0m0.220s LappyBob:~ tatd2$ time ./test +RTS -N3 -0.117109518058233

real 0m50.679s user 1m24.235s sys 0m0.620s

The last result is still off the wall, but it's a lot better.

That's another question: why did you get such awful performance for N=3 and I get similar results for N=8 on this 8 core? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e