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 too slow, a way around it is to design the RDTSC
to be called only occasionally. But this involves a branching
instruction which is probably going to hurt it too.
I wonder if you could have a "burst" version that generates several at a
time and queues them up? Then you grab them off the queue until you
run out, then you insert some entropy with RDTSC and generate 16 more
numbers or something like that. This still requires a branch
instruction. Of course you are inserting far less entropy into the
system if you only do it occasionally, but I would bet that you have
several bits of entropy in this case, because a lot is going on before
you get to the next call.
- Don
A van Kessel wrote:
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 fetching,
of course)
I have not yet been able to instruct GCC to use the mmx or sse3 instructions/
registers to do the shifting. Code could be reshuffeled to allow the
compiler more freedom.
AvK
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
