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
On Sun, Oct 14, 2007 at 11:54:54PM +0200, 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
On Mon, 2007-10-15 at 10:48 -0400, David Roundy wrote:
I have no idea if this example will help your actual code, but it
illustrates that at least in this example, it's pretty easy to gain an
order of magnitude in speed. (That func is a weird function, by the
way.)
Thanks for your reply
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 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 14, 2007, at 17:54 , ntupel wrote:
Now my problem still is, that I don't know how to speed things up. I
tried putting seq and $! at various places with no apparent
improvement.
Maybe I need to find a different data structure for my random
module and
lazy lists are simply not
On Sun, 2007-10-14 at 18:14 -0400, Brandon S. Allbery KF8NH wrote:
On Oct 14, 2007, at 17:54 , ntupel wrote:
Now my problem still is, that I don't know how to speed things up. I
tried putting seq and $! at various places with no apparent
improvement.
Maybe I need to find a different
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
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 have to confess that I am still in the early stages of
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
25 matches
Mail list logo
