[ ghc-Bugs-1245810 ] Random.StdGen slowness

[SourceForge.net]

Bugs item #1245810, was opened at 2005-07-27 08:32
Message generated for change (Comment added) made by simonpj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1245810&group_id=8032

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries/base
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Remi Turk (remit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random.StdGen slowness

Initial Comment:
Two (performance) problems in one:

{-# OPTIONS -fffi #-}
module Main (main) where

import Control.Monad
import Random

foreign import ccall unsafe "random" _crandom :: IO Int

randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
    n <- _crandom
    return $ min + n `rem` range
    where
        range = max - min + 1

main = replicateM_ (5*10^6) $ do
    x <- randomRIO (0::Int,1000) :: IO Int
    x `seq` return ()
    return ()

First, without the "seq" at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
  Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
  Does help in this example, but also changes behaviour
of the library:
  x <- randomRIO undefined
  currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.

Second, even _with_ the "seq", replacing "randomRIO" by
"randomInt" speeds the thing up with a factor of about
30. (2 to 3.6, in a "real world" university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(

----------------------------------------------------------------------

>Comment By: Simon Peyton Jones (simonpj)
Date: 2005-08-11 15:10

Message:
Logged In: YES 
user_id=50165

If someone can narrow down why things speed up by a factor 
of 30, and can give us a better characterised case where 
GHC is giving bad performance, we'd be happy to investigate.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1245810&group_id=8032