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).
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 findin
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
|
l.org
| 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
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 re
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 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 di
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 working
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 larg
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:
> >
> > http:/
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, 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.
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
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 StdGen'
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 b
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 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 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 rando
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 larg
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, I
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)
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
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
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
> slow
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 writing
25 matches
Mail list logo
