On Sat, 2007-10-13 at 18:33 -0300, Isaac Dupree wrote:
GHC StdGen's random and randomR are somewhat slow. I found that
changing to a custom ((x*a + b) `mod` c) random-generator (instance of
RandomGen) much sped things up (since nothing depended on the random
numbers being good quality).
| Subject: Re: [Haskell-cafe] Performance problem with random numbers
|
| isaacdupree:
| ntupel wrote:
| Thanks for your reply Stefan. Unfortunately I could measure only a
| relatively small improvement by changing to concrete types
|
| the sample code was about one second faster when compiled
Does the GHC code generator makes use of SIMD instructions? Maybe via
the C compiler?
Cheers,
Peter
Simon Peyton-Jones wrote:
We'd be delighted if someone offered a more performant library to put into
future GHC releases.
| I've seen similar results switching to the SIMD mersenne twister C
On Tue, Oct 16, 2007 at 06:07:39PM +0200, Peter Verswyvelen wrote:
Does the GHC code generator makes use of SIMD instructions? Maybe via the C
compiler?
No.
GHC uses GCC extensions, and GCC doesn't support automatic SIMD use.
(You could use -unreg and an advanced compiler. Good luck finding
The Mersenne twister should be able to split better than most. but I'm not
sure how efficient it is.
On 10/14/07, Isaac Dupree [EMAIL PROTECTED] wrote:
Don Stewart wrote:
I've seen similar results switching to the SIMD mersenne twister C
implementation for randoms:
On Fri, 2007-10-12 at 20:25 -0700, Stefan O'Rear wrote:
On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote:
setup :: (Ord a, IArray a2 a, IArray a1 e, Num a) = [e] - [a] - (a1 Int
e, a1 Int e, a2 Int a)
calcAlias :: (Ord e, Num e, IArray a e, Ix i, IArray a2 e1, IArray a1 e1)
= a2 i
On Oct 13, 2007, at 6:52 , ntupel wrote:
On Fri, 2007-10-12 at 20:25 -0700, Stefan O'Rear wrote:
On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote:
setup :: (Ord a, IArray a2 a, IArray a1 e, Num a) = [e] - [a] -
(a1 Int e, a1 Int e, a2 Int a)
calcAlias :: (Ord e, Num e, IArray a e, Ix
On Sat, 2007-10-13 at 09:56 -0400, Brandon S. Allbery KF8NH wrote:
Now you need to start forcing things; given laziness, things tend to
only get forced when in IO, which leads to time being accounted to
the routine where the forcing happened. If random / randomR are
invoked with large
On Oct 13, 2007, at 11:40 , ntupel wrote:
On Sat, 2007-10-13 at 09:56 -0400, Brandon S. Allbery KF8NH wrote:
Now you need to start forcing things; given laziness, things tend to
only get forced when in IO, which leads to time being accounted to
the routine where the forcing happened. If
On Sat, 2007-10-13 at 12:42 -0400, Brandon S. Allbery KF8NH wrote:
Your apparently simple StdGen argument is actually a sort of program
state (represented by unevaluated thunks, not by a state monad; see
below) which gets altered with every invocation of random. If
nothing is forced
On Oct 13, 2007, at 13:30 , ntupel wrote:
On Sat, 2007-10-13 at 12:42 -0400, Brandon S. Allbery KF8NH wrote:
Your apparently simple StdGen argument is actually a sort of program
state (represented by unevaluated thunks, not by a state monad; see
below) which gets altered with every invocation
On Sat, 2007-10-13 at 13:35 -0400, Brandon S. Allbery KF8NH wrote:
For starters, look into seq. Try applying it to any expression
using a generated random number. This should force evaluation to
occur somewhere other than when random is trying to figure out what
StdGen value it's been
ntupel wrote:
Thanks for your reply Stefan. Unfortunately I could measure only a
relatively small improvement by changing to concrete types
the sample code was about one second faster when compiled with -O2.
Profiling again indicated that most time was spend in random and randomR
GHC
isaacdupree:
ntupel wrote:
Thanks for your reply Stefan. Unfortunately I could measure only a
relatively small improvement by changing to concrete types
the sample code was about one second faster when compiled with -O2.
Profiling again indicated that most time was spend in random and
On Sat, 2007-10-13 at 14:37 -0700, Don Stewart wrote:
I've seen similar results switching to the SIMD mersenne twister C
implementation for randoms:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
If there's interest, I can package up the bindings for hackage.
I
Don Stewart wrote:
I've seen similar results switching to the SIMD mersenne twister C
implementation for randoms:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
If there's interest, I can package up the bindings for hackage.
looks nice... at least for those of us who
On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote:
Dear all,
I have implemented a small module to generate random items with a given
probability distribution using the alias approach [1] and unfortunately
compared to similar implementations in C++ or Java it is about 10 times
slower. I
stefanor:
On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote:
Dear all,
I have implemented a small module to generate random items with a given
probability distribution using the alias approach [1] and unfortunately
compared to similar implementations in C++ or Java it is about 10
dons:
stefanor:
On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote:
Dear all,
I have implemented a small module to generate random items with a given
probability distribution using the alias approach [1] and unfortunately
compared to similar implementations in C++ or Java it
19 matches
Mail list logo
