[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
<font class="small">Code:</font><hr /><pre>
133784560 hands
1.188 secs
112613302 hands/sec
hc 23294460
pr 58627800
tp 31433400
th 6461620
st 6180020
fl 4047644
fh 3473184
fr 224848
sf 41584
</pre><hr />
This was on an AMD 3000+ with 1 gig memory running Win2k
This computer produced
133784560 hands
5.156 secs
25947355 hands/sec
hc 23294460
pr 58627800
tp 31433400
th 6461620
st 6180020
fl 4047644
fh 3473184
fr 224848
sf 41584
using Andrzej Nironen's "Hand Evaluator Speed Demo"
[/ QUOTE ]
Very impressive! (I think you have the results mixed up though - 112.5mil when doing extra work of incrementing the hand type counts, 50mil when not... [img]/images/graemlins/smile.gif[/img] )
Have you considered posting this method on the
pokersource yahoo group?
Juk [img]/images/graemlins/smile.gif[/img]
EDIT: Sorry, I just noticed you print the hand type counts in both procedures... BTW: How fast does it run without doing this (ie: just assigning an integer the hand evaluation rather than incrementing totals[]?)
[/ QUOTE ]
0.953 secs
140382574 hands/sec
However I'm doubting the granularity of the timing process used.
I'll switch to the RDTSC method and repost relative values.
Using RDTSC as a timer
133784560 hands
2.640 secs
50675964 hands/sec
becomes
133784560 hands
5752663748 cycles
42.999 cycles/hand
133784560 hands
1.188 secs
112613302 hands/sec
becomes
133784560 hands
2645152642 cycles
19.772 cycles/hand
and
133784560 hands
0.953 secs
140382574 hands/sec
becomes
133784560 hands
2077269818 cycles
15.527 cycles/hand
[/ QUOTE ]
I've kinda lost track of this thread now, but so far (out of all the algorithms listed here), which are the current best algorithms (in cycles per second & assuming no "cheating" - ie: algorithm speed measured against a 7-card hand selected uniformly randomly from all possible 7-card hands) for:
a) A "packed" 64bit integer representation.
b) A unordered 7-integer representation.
Most of my work has used a packed representation in the past, but after seeing mykey1961's nested lookup idea running at 15 cycles per hand, I am seriously considering moving everything over to an unpacked representation to take advantage of this (~20mil hands/sec -> ~200mil hands/sec can't be ignored!).
Overall this thread has opened my eyes; I'd always just taken foregranted that the pokersource lib was highly optimized and assumed only marginal speed improvements would be possible in the future...
Great thread - Juk [img]/images/graemlins/smile.gif[/img]