Thanks for the clues, I'll try and make some time this weekend to track it down. I do have some gentoo x64 systems to play with. My first impulse is actually that it is likely due to differences in inlining and/or rewrite rule processing between the GHC versions, but we'll see what turns up. -- James On Apr 9, 2010, at 6:51 AM, Gökhan San wrote:
mokus@deepbondi.net writes:
are you using the hackage-released version of random-fu or the darcs one?
I was using the hackage version, but since then I switched to the darcs version. (Btw, began using it in some of my projects and I'm really happy about it.)
In the above case, I was using IO in the first bgroup and State StdGen in the second.
I'm running it on a x86_64 Gentoo Linux box with GHC 6.10.4 and was unable to install Criterion (apparently, impossible is happening while compiling vector-algorithms) so I used 'time' to come up with some results.
Below doesn't include IO tests (randomRIO, etc.), since they turned out to be spectacularly slow anyway. Results using ghc -O2.
module Main (main) where
import Data.Random import Data.List import Control.Monad.State import Control.Monad.Random import System.Random
test = p1 `fmap` getStdGen type RType = Double
/usr/bin/time results for (test, RType):
(p1, Double) : ~3.3 secs (p2, Double) : ~1.7 secs (p3, Double) : ~1.0 sec (p1, Int) : ~1.9 secs (p2, Int) : ~1.0 sec (p3, Int) : ~0.5 sec
count = 10 ^ 6 range = (-10, 10) type P = StdGen -> [RType]
p1 = evalState (sample (replicateM count (uncurry uniform range))) :: P
p2 = evalRand (replicateM count (getRandomR range)) :: P
p3 = take count . evalRand (getRandomRs range) :: P
main = test >>= (print . foldl' (+) 0)
Using 'sum' turned to be rather misleading (took up to a minute to sum up 'Double's; this problem was less apparent for p1), so I had to use foldl' here to get consistent results between 'Int's and 'Double's. '`using` rnf' produced similar results.
Also, using DevURandom for random-fu produces almost the same results.
--
Gökhan San