[Haskell-cafe] Haskell Speed Myth
Thomas M. DuBuisson
thomas.dubuisson at gmail.com
Sun Aug 24 14:03:30 EDT 2008
> Hmm thanks, that's interesting -- I was think it was probably caused
> by OS X, but it appears to happen on Linux too. Could you try running
> the old code too, and see if you experience the order of magnitude
> slowdown too?
The original program on my Linux 2.6.26 Core2 Duo:
[tom at myhost Test]$ time ./tr-threaded 1000000
[tom at myhost Test]$ time ./tr-nothreaded 1000000
[tom at myhost Test]$ time ./tr-threaded 1000000 +RTS -N2
Seeing as there still was obviously not enough computation to justify
the OS threads in my last example, I made a test where it hashed a 32
byte string (show . md5 . encode $ val):
[tom at myhost Test]$ time ./threadring-nothreaded 1000000
[tom at myhost Test]$ time ./threadring-threaded 1000000
[tom at myhost Test]$ time ./threadring-threaded 1000000 +RTS -N2
[tom at myhost Test]$
Seeing as this still doesn't beat the old RTS, I decided to increase the
per unit work a little more. This code will hash 10KB every time the
token is passed / decremented.
[tom at myhost Test]$ time ./threadring-nothreaded 100000
[tom at myhost Test]$ time ./threadring-threaded 100000
[tom at myhost Test]$ time ./threadring-threaded 100000 +RTS -N2
* Yes, I notice its exiting before the output gets printed a couple
times, oh well.
Yay, the multicore version pays off when the workload is non-trivial.
CPU utilization is still rather low for the -N2 case (70%). I think the
Haskell threads have an affinity for certain OS threads (and thus a
CPU). Perhaps it results in a CPU having both tokens of work and the
other having none?
More information about the Haskell-Cafe