Looking at the lightest playout version of my bitmap-based 9x9 program
(source-code somewhere in the archives), I spent an estimated 2% of the
time generating random numbers, so 40% seems to indicate something is not
right, such as re-initializing the generator all the time.
The execution time of
For profiling I use callgrind.
Afaik it is the most accurate as it simulates a processor and counts
cycles etc.
As others pointed out: my playout-code is somewhat lightweight. In that
40% version it only checked if a cross is empty. I added super-ko check
which gave a 10% hit on the number of
Assuming you are using some sensible OS there better ways profile than
sample like oprofile for linux. There is similar thing for FreeBSD I
think. No instrumentation san sampling gets automated
Petri
2015-03-30 8:05 GMT+03:00 hughperkins2 hughperki...@gmail.com:
40% sounds pretty high. Are
40% sounds pretty high. Are you sure its not an artefact of your profiling
implementation?
I prefer not to instrument, but to sample stack traces. You can do this using
gdb by pressing ctrl-c, then type bt. Do this 10 times, and look for the parts
of the stack that occur often.
I measured that std::mt19937_64 (the mersenne twister from the standard
c++ libraries) uses about 40% cpu time during playouts.
So I wonder: is there a faster prng while still generating good enough
random?
This question suggests some:
http://stackoverflow.com/q/1640258/841830
This
Anyway, it's very easy to make a fast PRNG these days.
A couple words of caution about hacking PNRG.
Back in the stone age of computing, some mavens from the triple-i movie
group cooked up a galaxy simulator which generated pictures of spiral
galaxies based on a numerical model. The
29.03.2015 um 12:29 schrieb Álvaro Begué alvaro.be...@gmail.com:
If your PRNG is consuming 40% of your CPU time, your playouts are too light.
That's what I was going to say, too. My program isn't the fastest (5k pps on
9x9) and the RNG never even appeared in the profiling output.
Urban
uniform choices, one bit. Three choices: fractional bits.
[0]
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/
— Remco
-Original Message-
From: folkert folk...@vanheusden.com
To: computer-go@computer-go.org
Sent: Sun, 29 Mar 2015 17:50
Subject: [Computer-go] fast + good RNG
Hi,
I
in terms of bias and entropy consumption.
— Remco
-Original Message-
From: folkert folk...@vanheusden.com
To: computer-go@computer-go.org
Sent: Sun, 29 Mar 2015 18:05
Subject: Re: [Computer-go] fast + good RNG
Ah!
But how do you make sure the numbers are uniformly distributed?
On Sun, Mar 29
@computer-go.org
Sent: Sun, 29 Mar 2015 17:50
Subject: [Computer-go] fast + good RNG
Hi,
I measured that std::mt19937_64 (the mersenne twister from the standard
c++ libraries) uses about 40% cpu time during playouts.
So I wonder: is there a faster prng while still generating good enough
://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/
— Remco
-Original Message-
From: folkert folk...@vanheusden.com
To: computer-go@computer-go.org
Sent: Sun, 29 Mar 2015 17:50
Subject: [Computer-go] fast + good RNG
Hi,
I measured that std::mt19937_64 (the mersenne twister from the standard
c
I just think Go (except trivial implementation cases) should be very
insensitive to RNGs. It is not like many Monte Carlo applications where
you just call the RNG in a tight loop in regular manner to move in the
same state space. In a Go program, you call the RNG from playouts in
all sorts of
Hi,
I measured that std::mt19937_64 (the mersenne twister from the standard
c++ libraries) uses about 40% cpu time during playouts.
So I wonder: is there a faster prng while still generating good enough
random?
Folkert van Heusden
--
Nagios user? Check out CoffeeSaint - the versatile Nagios
. Three choices:
fractional bits.
[0]
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/
??? Remco
-Original Message-
From: folkert folk...@vanheusden.com
To: computer-go@computer-go.org
Sent: Sun, 29 Mar 2015 17:50
Subject: [Computer-go] fast + good RNG
Hi,
I
On Sun, Mar 29, 2015 at 01:08:20PM +0200, Kahn Jonas wrote:
Why not xorshift+128 ?
Because I wasn't aware of it. Nice!
But I probably won't remember the code by heart like I do
seed * prime_near_2^14. ;-)
Period is $2^128 - 1$, more than sufficient for go. (If you need longer
periods, use
-Original Message-
From: folkert folk...@vanheusden.com
To: computer-go@computer-go.org
Sent: Sun, 29 Mar 2015 17:50
Subject: [Computer-go] fast + good RNG
Hi,
I measured that std::mt19937_64 (the mersenne twister from the standard
c++ libraries) uses about 40% cpu time during
16 matches
Mail list logo
