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 my engine breaks down sort-of like this on my MacBook:
benchmarking Mersenne Twister (SFMT version [following Agner Fog])
[BRandom] = 1, [IRandom] = 1, [IRandomX] = 2, [Random] = 2, [FRandom] = 2
benchmarking playouts (clock cycles)
[game] = 18051 cc, [moves] = 111.07
benchmarking playouts (wall time)
[game] = 126.108 kpps, [moves] = 111.07
benchmarking board functions (calls per game/clock cycles)
[select] 111/55, [play] 106/93, [score] 14, [win] 0.4251
benchmarking move generator (calls per game/clock cycles, find+pick)
[moves] 111
[random] 111/17+36
This last line breaks down move-generation in finding all legal moves
(17cc, using Gunnar Farneback's Brown programs definition of legal) and
picking one uniformly at random (36cc). That last method uses 1-3 random
numbers of 1cc each. A move takes 55 + 93 = 148cc, so 3cc represents at
most 2%.
Things get a bit messier to assess once you consider waterfalling moves,
such as captures, atari extensions, etc. In general, though, going towards
heavier playouts will only reduce the time spent on random number
generation because you will have to maintain more data or perform more
logic. In any case, spending more than a handful of cc on random number
generation is not needed and, thus, random number generation should not be
high on your resource consumption list.
For reference, an old profile report for a non-bitmap heavier MCTS-player
reports 1.1% of time was spent on random number generation.
René
BTW. The average game-length using a uniformly random move-generator is a
pretty good correctness test.
On Sun, Mar 29, 2015 at 10:16 PM, Petri Pitkanen <petri.t.pitka...@gmail.com
> wrote:
> 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 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.
>>
>>
>> _______________________________________________
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>>
>
>
> _______________________________________________
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>
_______________________________________________
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
