Awesome Joshua! I agree with the others. Start open sourcing it right away.
That's what I did with my Go bot that I started writing in a language I
didn't know. And people (well, two ;)) just decided to help out.
As for features. Well, I'd be happy if you just reimplemented CGOS and it
were runnin
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
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 :
> 40% sounds pretty high. Are you sure its not an arte
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 encourage you to work in the open from the start (on GitHub) so everyone
can see what you have in mind.
On Sat, Mar 28, 2015 at 6:59 PM Joshua Shriver wrote:
> What elements did you like about CGOS and what do you wish for?
>
> I've begun writing a new version from scratch that isn't TCL based
In which langage will it be ?
2015-03-28 23:58 GMT+01:00 Joshua Shriver :
> What elements did you like about CGOS and what do you wish for?
>
> I've begun writing a new version from scratch that isn't TCL based.
> With the aim for future use and also open source and open to public
> commits.
>
>
> 29.03.2015 um 12:29 schrieb Álvaro Begué :
>
> 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
_
>
>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 ca
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 ir
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, u
Why not xorshift+128 ?
*
include
/* The state must be seeded so that it is not everywhere zero. */
uint64_t s[2];
uint64_t xorshift128plus(void) {
uint64_t x = s[0];
uint64_t const y = s[1];
s[0] = y;
x ^= x << 23; // a
x ^= x >> 17; // b
x ^= y ^ (y >> 26); // c
> 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 q
Hmm, I use just a super-naive LCG
unsigned long hi, lo;
lo = 16807 * (pmseed & 0x);
hi = 16807 * (pmseed >> 16);
lo += (hi & 0x7fff) << 16;
lo += hi >> 15;
pmseed = (lo & 0x7fff) + (lo >> 31);
return ((pmseed & 0x) * max) >> 16;
Powers of two are easy, just take the minimum amount of bits out of your
entropy.
For a generic number N
Approach 1: round up to the next highest power of two, then discard and try
again if it is >= N.
This could potentially reject up to half the samples, so I have two
improvements I used:
A
If your PRNG is consuming 40% of your CPU time, your playouts are too light.
Anyway, it's very easy to make a fast PRNG these days. The first thing that
comes to mind is a 64-bit linear congruential generator of which you use
the middle bits, or you can XOR the high 32 bits and the low 32 bits
tog
Ah!
But how do you make sure the numbers are uniformly distributed?
On Sun, Mar 29, 2015 at 05:58:56PM +0800, remco.bloe...@singularityu.org wrote:
> I switched to SFMT [0]. But that was some years ago, there might be faster
> options now.
>
> I also generated it in megabyte batches and consume
I switched to SFMT [0]. But that was some years ago, there might be faster
options now.
I also generated it in megabyte batches and consume it from there, generating a
new megabyte as needed.
Lastly, I had some code to make sure I did not consume more bits of entropy
than required. Two unifo
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 s
18 matches
Mail list logo
