I think the general distaste for modulo is based on the historical tendency for
the low-order bits to be less random than the high-order bits.
Hideki Kato wrote:
Thank you for detailed explanation. I've understood well now.
It's essentially the mapping problem from [0..N) to [0..M) where
N
A reasonable xor+shift random (similar to Marsaglia's, but only 64bit
instead of 128 bits), using the pentium's rdtsc-instrunction to add
additional "entropy" (i used gnu's inline assembler) :::
#define rdtscll(val) \
__asm__ __volatile__("rdtsc" : "=A" (val))
typedef unsigned long long
The question I have is how much does RDTSC slow this down?I may do
some tests to see.
- Don
A van Kessel wrote:
A reasonable xor+shift random (similar to Marsaglia's, but only 64bit
instead of 128 bits), using the pentium's rdtsc-instrunction to add
additional "entropy" (i used gnu's inli
> The question I have is how much does RDTSC slow this down?I may do
I don't know.
If I understand correctly, rdtsc can be executed in parallen with *some*
other instructions (and places no "barrier" in the code), in which case
it could be executed at no additional cost (except the instruction
I did a simple test. I compiled this version and the version below to
get a sense of how fast it is.
Your version with RDTSC is quite slow compared to the version below.
I determined that RDTSC is taking almost all the time however, because
just for fun I took out that call and it was mu
I doesn't seem too fast based on my test, but perhaps there are ways to
optimize it.
I would like to mention that your generator is 64 bit and the other
generator was 32 bits but I'm running on a 64 bit core 2 duo OS and do
not know how much of a factor this is or isn't.
If RDTSC actually is
> I would like to mention that your generator is 64 bit and the other
That is correct.
My timings (Haven't profiled yet):
WITH TSC:
real0m0.902s
user0m0.870s
sys 0m0.002s
WITHOUT:
real0m0.613s
user0m0.582s
sys 0m0.000s
That's for 100 M random numbers.
And inlining would
That's way different that what I'm getting. Something is wrong here.
I'm getting 4.08 with RDTSC and when I just set new to 0ull I get 0.696
One of us must have done something wrong.
- Don
A van Kessel wrote:
I would like to mention that your generator is 64 bit and the other
Th
Hi,
I have been leafing through a book "Reinforcement Learning" by Sutton and
Barto. The book seems to serve as a decent introductory text to some of the
issues which are mentioned in parts of Sylvain Gelly's thesis.
The book however, is a decade old and I curious if there are resources which
#include
#include
I'm including my code below. Also, here are my reported times:
Without RDTSC
real0m1.008s
user0m0.668s
sys 0m0.004s
With RDTSC
real0m5.790s
user0m3.956s
sys 0m0.016s
To turn on or off RDTSC see the rdtsc_rand line that says, "if (1)"
- Don
--
I Just omitted the "new" variable:
/**/
BIGTHING rdtsc_rand(void)
{
static BIGTHING val=0xULL;
#if WANT_RDTSC
BIGTHING new;
rdtscll(new);
val ^= (val >> 15) ^ (val << 14) ^ new;
#else
val ^= (val >> 15) ^ (val << 14) ^ 9 ;
#endif
Carter Cheng wrote:
Hi,
I have been leafing through a book "Reinforcement Learning" by Sutton and Barto. The book seems to serve as a decent introductory text to some of the issues which are mentioned in parts of Sylvain Gelly's thesis.
The book however, is a decade old and I curious if there
Has anyone looked at the resultant distributions, to
determine how "random" they are?
--- Don Dailey <[EMAIL PROTECTED]> wrote:
> #include
> #include
> I'm including my code below. Also, here are my
> reported times:
>
> Without RDTSC
>
> real0m1.008s
> user0m0.668s
> sys 0m0.00
> Has anyone looked at the resultant distributions, to
Well, mine was pretty random.
Maybe a bit too random.
Changing the 14 and 15 shifts effectively cripples it.
I have not looked at sequential correlation, only at the
distribution, by binning the values into a histogram.
As far as I could see
terry mcintyre wrote:
Has anyone looked at the resultant distributions, to
determine how "random" they are?
They should be run against the dieharder tests before any confidence is
placed in them. But I did look at them "visually" to see if there was
anything wrong that was immediately obvi
Ok, please check your number again.I set mine up like yours just in
case and I still get at least a 5x slowdown.
I think yours are probably wrong because I have seen numbers that
indicate RDTSC is really slow.
- Don
A van Kessel wrote:
I Just omitted the "new" variable:
/***
Are you using the same hardware? I was looking over
the instruction timings, and there's a lot of
variation depending on the architecture.
--- Don Dailey <[EMAIL PROTECTED]> wrote:
> That's way different that what I'm getting.
> Something is wrong here.
>
> I'm getting 4.08 with RDTSC and whe
Measurements ar pretty consistent.
Hardware:
Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007
i686 athlon i386 GNU/Linux
(I didnot even know it was an athlon !)
AvK
___
computer-go mailing list
computer-go@computer-go.or
terry mcintyre wrote:
Are you using the same hardware? I was looking over
the instruction timings, and there's a lot of
variation depending on the architecture.
cat /proc/cpuinfo reports this for me for the first processor:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
Well that's quite a difference, I'm on a core 2 duo and evidently RDTSC
sucks on a core 2 duo.
- Don
A van Kessel wrote:
Measurements ar pretty consistent.
Hardware:
Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007
i686 athlon i386 GNU/Linux
(I didnot even k
Mine:
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2800+
stepping: 0
cpu MHz : 2079.595
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_
21 matches
Mail list logo
