Image Image Image




Post new topic Reply to topic  [ 399 posts ]  Go to page Previous  1 ... 15, 16, 17, 18, 19, 20  Next
Author Message
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Wed Mar 03, 2010 9:34 am 
Offline
Senior member
User avatar

Posts: 125
Favourite Bot: wetbot
Quote:
Yes, I can export those to text file, but can you specify more what you are needed and in what format (example comma separated list)?

Yes, comma-delimited would be best, I think. I may end up just pasting it directly into the source. I need all the arrays generated by HandFST --fst7123, fst74...fst77, flush7, fst64, .. fst66, flush6 ... fst55, flush5. Not sure if I need the Brecher maps or not ... I didn't even realize there are different equivalent class mappings. I thought everyone was using Cactus Kev's map. If this is asking too much, maybe you could just post the serialized array binaries? Though I'm a bit dubious of my ability to parse them.

Also, can you clarify which is the source for the Spears/RayW evaluator (ie the fastest one) in your zip file? I have been up and down this thread trying to find that source, and I can't figure out which is which. Is the benchmarking data you list for that evaluator from a Java or C implementation of it? Are both sources available?


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Wed Mar 03, 2010 1:42 pm 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi
wetbot wrote:
Yes, comma-delimited would be best, I think. I may end up just pasting it directly into the source. I need all the arrays generated by HandFST --fst7123, fst74...fst77, flush7, fst64, .. fst66, flush6 ... fst55, flush5. Not sure if I need the Brecher maps or not ... I didn't even realize there are different equivalent class mappings. I thought everyone was using Cactus Kev's map. If this is asking too much, maybe you could just post the serialized array binaries? Though I'm a bit dubious of my ability to parse them.

Also, can you clarify which is the source for the Spears/RayW evaluator (ie the fastest one) in your zip file? I have been up and down this thread trying to find that source, and I can't figure out which is which. Is the benchmarking data you list for that evaluator from a Java or C implementation of it? Are both sources available?


Yes, it uses Cactus Kev's map for 5 card hands and drops out unused numbers for 6 and 7 card hands so (6075 classes for 6-card hands and 4824 classes for 7-card hands). In some cases this is not so nice, because easy comparison is not possible, but numbers can be mapped to Brecher and back.

Source for Spears/RayW evaluator is this topic first post. So in my benchmarks are done with Java version. Copy paste C sources for RayW evaluator can be found at Two Plus Two Poker Forums 7 Card Hand Evaluators thread.


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Wed Mar 03, 2010 6:35 pm 
Offline
Senior member
User avatar

Posts: 125
Favourite Bot: wetbot
Quote:
Source for Spears/RayW evaluator is this topic first post.

Thanks, that narrows it down ... how is it labeled in Indiana's zip file? "Spears", "spears2p2", "twoplustwo", or something else?


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Wed Mar 03, 2010 6:53 pm 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi

In first page, very first post and first link. All code also found in my post on page 16 inside pokerai.zip.

P.S Put you email address to me in private message so I can send you those text files :-)


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Wed Mar 03, 2010 7:29 pm 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi

I managed to handle most of insignificant ranks. Code is still very ugly... Only problem class is two pairs... all my modifications makes errors in validation :-(

As I expected classes that are not aligned to current states are really interesting. I modified output little, so now it outputs first state address before it textual representation. Here is example:
Code:
Equivalent: [1294488 [Th,6x,5x,4h,3h,2h] [1294423, 1294488]]
Equivalent: [1294592 [Jh,6x,5x,4h,3h,2h] [1294527, 1294592]]

Both states are already handled in my compression code. Current version packs it like:
if each suit (cdhsx) state is represented as Xooo oXoo ooXo oooX oooo, where o and X is 13 int sequence. Compressin makes it to oXooooXo where indexes are d = d, c = d + 13, o = d + 26, s = d + 39, h = d + 52

So in our example case first state h = 1294488, currentIndex = 1294540
And second state d = 1294540, c = 1294553, o = 1294566, s = 1294579 h = 1294592
If we present it visually (second line from bottom shows current compression, lines above represent states that are packed and bottom line shows place where bluegaspodes code found same sequence)
Code:
    oAoo         
     Aooo         
      oooo
       oooA
        ooAo 
                 
            oBoo
             Booo
              oooo
               oooB
                ooBo
    oAooooAooBooooBo
           ooBo       

So optimal solution is following
Code:
                 
    oooA               
     ooAo             
      oAoo             
       Aooo         
        oooo         
                     
         oooB       
          ooBo     
           oBoo     
            Booo     
             oooo       
    oooAooooBoooo         

Even each set of 5 states are same size than previous, these sets can now overlap much more.

I think there are lots of this kind of situations, so lots of work :-)


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Fri Mar 05, 2010 1:33 am 
Offline
Senior member
User avatar

Posts: 172
Favourite Bot: don't know
Here is an addition to makeKey() to reduce two-pairs (without producing errors in later comparison)
The output still shows that there are some two-pairs left which I did not catch with the code below, like

Equivalent: [[Kx,Kx,Jx,8x,8x,2x] [Kx,Kx,Jx,8x,8x,3x] [Kx,Kx,Jx,8x,8x,4x] [Kx,Kx,Jx,8x,8x,5x] [Kx,Kx,Jx,8x,8x,6x] [Kx,Kx,Jx,8x,8x,7x] [2773147, 4595539, 5701501, 6335953, 6675019, 6840275]]

Anyway - too late tonight to go on ...
[code] // two pair in card 0-4
else if ((rankCount[(hand[0] >>> 4)] == 2 && rankCount[(hand[2] >>> 4)] == 2) || //
(rankCount[(hand[0] >>> 4)] == 2 && rankCount[(hand[3] >>> 4)] == 2) || //
(rankCount[(hand[1] >>> 4)] == 2 && rankCount[(hand[3] >>> 4)] == 2)) {
String keyString = keyToString(baseKey);

boolean reduce=true;
// card5 needs gap to prevent straight
// 887766 => 45 not allowed for card 5 (gap=2)
// 997766 => 5 not allowed for card 5 (gap=1)
int neededGap = Math.max((4 - ((hand[0] >>> 4) - (hand[4] >>> 4))), 0);
if (((hand[4] >>> 4) - (hand[5] >>> 4)) <= neededGap) {
reduce=false;
}

// possible A-high straights cannot be reduce
// AA544, AA554, A5544, A4433
if ((hand[0] >>> 4)==13 && (((hand[2] >>>4)==3) || ((hand[2] >>>4)==4))) {
reduce=false;
}


// if card5 still has its suit its part of the flush-handrank
if ( ((hand[5] & 0xF) != 0)) {
reduce=false;
}

if (reduce) {
hand[5] = (14 << 4);
}

}
[code]


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Fri Mar 05, 2010 10:05 am 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi

Here is current version. I tried two pair comparison, but unfortunately I couldn't get it working :-(

Anyway current size when compressed and splitted is 51.1 MB. Last level (handRank7) is very well compressed. If we count only state changes and overlap compression it is compressed by 75%. If we also count change from int array to char array it is compressed by 88% :-)

Because state changes, even original (card values from 1..52 and 0 index is used for 6 and 5 card hand rank values) table is now 11% smaller. It current size is 111MB.

This version contain also correctness test against Brecher Hand Evaluator.


Attachments:
File comment: current version
jokipii.zip [74.27 KB]
Downloaded 82 times
Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Fri Mar 05, 2010 9:40 pm 
Offline
Senior member
User avatar

Posts: 172
Favourite Bot: don't know
jokipii wrote:
I tried two pair comparison, but unfortunately I couldn't get it working :-(

Yeah for some reason it doesn't work anymore.
Anyway - here is a quick fix:
instead if using
Code:
   if (reduce) {
      hand[5] = (14 << 4);
   }

just use
Code:
   if (reduce) {
      hand[5] = (1 << 4);
   }

It seems that using (14<<4) changes some important ordering. (1 << 4) is equally good, turning an insignificant rank into the lowest possible rank.

Here are the adapted counts:
Code:
   private static int LEVEL6END      = LEVEL6START + 283417;   // End position of level6 states
   private final static int SIZE         = 543951; //612978         // lookup table size (states)


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sat Mar 06, 2010 12:02 am 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi

bluegaspode wrote:
It seems that using (14<<4) changes some important ordering. (1 << 4) is equally good, turning an insignificant rank into the lowest possible rank.

It works :-)

here little modification for 6 card flush kicker detection
Code:
         // made 6 card flush, remove low kicker (if not contributing strait flush)
         else if (suitCount[0] == 0) {
            // check if not A2345 draw or lowest 4 cards in sequence (ie. 2345)
            if ((firstRank == 13) && ((hand[3] >>> 4) != 3) && ((hand[3] >>> 4) != 4)
                  && ((hand[2] >>> 4) - (hand[5] >>> 4) >= 4)) {
               hand[5] = (14 << 4);
            }
            // if not one gapper or lowest 4 cards in sequence (ie. 2345)
            else if ((firstRank - (hand[5] >>> 4)  > 5) && ((hand[2] >>> 4) - (hand[5] >>> 4)  >= 4)) {
               hand[5] = (14 << 4);
            }
         }


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sat Mar 06, 2010 2:51 pm 
Offline
Senior member
User avatar

Posts: 172
Favourite Bot: don't know
jokipii - I think we can still go on a lot by trading some lookup time into even more compressed handrank-tables.
the question is - how far should one go ?

For me I'd draw the line at 100mill hands/seconds (thats still far ahead of all other algorithms). Everything above is good and should be achieved with the lowest possible memory.

I did a small analysis of the level6 table (because this one currently is the biggest).
I searched for duplicates of 13-pointer blocks.
If I didn't make a mistake, there are 27970 13xpointer-blocks which have 291.716 duplicated blocks.
If these could be ommited, we could save 291.716*13*4Bytes=14,5MB in a level6-table.

Only problem: actually we always need 52-pointer blocks.
What about an intermediate table ?
lets call it 'level6a', with a lookup like

int quarter=hand/13;
level6bPointer=level6a[quarter]
level7=level6b[hand-quarter*13]

a short tests shows, that even with this simple calculations we still stay above 100million hands/second.

What do you think about this idea - should we go in in this directions ?


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sat Mar 06, 2010 7:13 pm 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi
bluegaspode wrote:
jokipii - I think we can still go on a lot by trading some lookup time into even more compressed handrank-tables.
the question is - how far should one go ?

For me I'd draw the line at 100mill hands/seconds (thats still far ahead of all other algorithms). Everything above is good and should be achieved with the lowest possible memory.

I agree. If there is lookup table based approach that contains all needed information and takes less memory it is worth of trying. Line where to stop is Klaatu FastEval... it uses lookup table for ranks and suits are handled separately.
bluegaspode wrote:
I did a small analysis of the level6 table (because this one currently is the biggest).
I searched for duplicates of 13-pointer blocks.
If I didn't make a mistake, there are 27970 13xpointer-blocks which have 291.716 duplicated blocks.
If these could be ommited, we could save 291.716*13*4Bytes=14,5MB in a level6-table.

Yes. There are lots of repeated 13-pointer blocks, even after overlap compression. If we manage to get those only once it means much bigger saving than overlap compression can do.
If I calculated correctly, original uncompressed version of level6 contains exactly 194935 unique 13-pointer blocks and 415493 duplicates.
bluegaspode wrote:
Only problem: actually we always need 52-pointer blocks.
What about an intermediate table ?
lets call it 'level6a', with a lookup like

int quarter=hand/13;
level6bPointer=level6a[quarter]
level7=level6b[hand-quarter*13]

a short tests shows, that even with this simple calculations we still stay above 100million hands/second.

What do you think about this idea - should we go in in this directions ?

I don't get it... maybe we can develop it little... if we divide card to two part on part is suit (4-pointer) and other is rank (13-pointer). Now search first adds suit and search with it and it returns pointer to correct 13-pointer set which is then searched... so it looks like

int result = handIndex6[handIndex6[current + (card & 3)] + (card >> 2)];

OK. This idea must be tested!

Great job!


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 1:18 am 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi

This post is just thinking in loud :-)

There are three types of states:
  1. flush (including ready made and all witch are not require specific suit of next card)
  2. possible flush that requires specific suit of next card or it is not flush
  3. non flush
Flush state needs two 13-pointer blocks. Possible flush and non flush states need only one. Each state of course need one 4-pointer block.

When we fill 13-pointer index for flush we fill first 13-pointer block by adding cards with suit that makes flush and second by adding any other suit. When we fill possible flush state we use suit that makes flush, for non flush states we can use any suit. Then 4-pointer index for non flush states just repeats four times it 13-pointer address. For flush/possible flush states we put it 13-pointer address to correct suit position and then we remove suits from cards and search that state and fill 3 more pointers with that state pointers... in flush case we put first 13-pointer address to correct suit position and fill others with second block address.

Hopefully I have same time to implement it tomorrow.


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 3:03 am 
Offline
Senior member
User avatar

Posts: 172
Favourite Bot: don't know
jokipii wrote:
I don't get it... maybe we can develop it little...
[...]
int result = handIndex6[handIndex6[current + (card & 3)] + (card >> 2)];

I'm not sure if we mean the same, but we are very close.
Here an example, maybe its easier to get this way.

say level5 has the following pointers to level6 (for the first three cards):
0, 52, 104 (3pointers*4bytes=12bytes)
and level6 looks like the following (A,B,C,D representing 13pointers each to level 7)
ABCD BCAA DCBA (=12blocks*13pointers=156pointers *4Bytes = 624 Bytes, 8 duplicate 13pointer-blocks)

level5+level6 thus take 12+624=636 bytes
lookup is:
level6Pointer=level5[level5Pointer+card5]
level7Pointer=level6[level6Pointer+card6]

Now we compress it:

level6 will be splitted into two tables: level6a (intermediary table) and level6b (compressed level6 table with no duplicates)
level5 will get new pointers to table level6a (all previous pointers just divided by 13):

level5 (pointers to level6a): 0,4,8
level6a(pointers to level6b): 0,13,26,39, 13,26,0,0, 39,26,13,0 (=12 pointers * 4bytes = 48 bytes)
level6b:ABCD (4blocks*13 pointers = 52 *4 bytes = 208 Bytes (no duplicates)

now level5+level6a+level6b take 12+48+208 bytes = 268 bytes (368 less than before)

Lookup is now:
level6aPointer=level5[level5Pointer+card5]
level6bPointer=level6a[level6aPointer+card6/13]
level7Pointer=level6b[level6bPointer+card6-(card6/13*13)]

This compression is 'stupid' and can be done on the final tables, without even knowing if we compress flushes or any other types of hands.


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 6:32 am 
Offline
Senior member
User avatar

Posts: 125
Favourite Bot: wetbot
Quote:
Here are results (java -cp .;meerkat-api.jar -Xmx1024m -server pokerai.game.eval.PerformanceTest2):

( 7) Spears adaptation of RayW LUT hand evaluator, http://pokerai.org/pf3, http://forumserver.twoplustwo.com
--- Million hands per second: 163,894025, hands 133784560, checksum 1528972275512, total time(s): 0.816286986

(15) Klaatu FastEval with partial state generation, http://pokerai.org/pf3
--- Million hands per second: 107,221288, hands 133784560, checksum 264377938088, total time(s): 1.24774252


Quote:
But my results are as follows, so I cannot see a 'almost-as-fast' speed. Or did I start the wrong tests ?

( 7) Spears adaptation of RayW LUT hand evaluator, http://pokerai.org/pf3, http://forumserver.twoplustwo.com
--- Million hands per second: 170,273840, hands 133784560, checksum 1528972275512, total time(s): 0.785702373

(15) Klaatu FastEval with partial state generation, http://pokerai.org/pf3
--- Million hands per second: 40,557373, hands 133784560, checksum 215572899988, total time(s): 3.298649549


You two have benchmarked very different relative speeds for Klaatu with PSG. Have you tried to reconcile why they are so different?

Quote:
For me I'd draw the line at 100mill hands/seconds (thats still far ahead of all other algorithms). Everything above is good and should be achieved with the lowest possible memory.


Well, if jokipii's benchmark is correct, Klaatu is already exceeding 100mm/sec with memory usage of just 641k, and Klaatu uses an algorithmic FST minimization technique, so I doubt it can be reduced further. Klaatu just uses a few bit shifts and 5 array lookups, and my understanding was that RayW was pretty similar (ie relies primarily on array lookups). In fact, since Klaatu's arrays are so much smaller, my understanding is that it is much faster when RayW when evaluatiing random hands (different benchmark technique). What is RayW doing differently that accounts for its speed advantage? I guess it might have to do with the flush-checking algorithm? If someone wouldn't mind telling me how the RayW code is labeled within the source zip files, I could look for myself, but so far, I can't tell which one it is -- I don't see any files named RayW.


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 10:13 am 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi
bluegaspode wrote:
jokipii wrote:
I don't get it... maybe we can develop it little...
[...]
int result = handIndex6[handIndex6[current + (card & 3)] + (card >> 2)];

I'm not sure if we mean the same, but we are very close.

I mean that we use original card order where cards are ordered 2c, 2d, 2h,... Ah, As.
If I write it in same way as you (two separated tables), lookup is now:
level6bPointer=level6a[level6aPointer + (card6 & 3)]; // this takes 2 lowest bits and they meaning is suit of card6
level7Pointer=level6b[level6bPointer + (card6 >> 2)]; // this removes 2 lowest bits and means card rank
bluegaspode wrote:
Lookup is now:
level6aPointer=level5[level5Pointer+card5]
level6bPointer=level6a[level6aPointer+card6/13]
level7Pointer=level6b[level6bPointer+card6-(card6/13*13)]

What i don't get is last operation where cad6 - (card6/13*13), because is always equals to 0. OK, you probably mean card6 % 13, that makes exactly same thing that my but with card order 2c, 3c, 4c,... Ks, As.


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 10:36 am 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi
wetbot wrote:
...
But my results are as follows, so I cannot see a 'almost-as-fast' speed. Or did I start the wrong tests ?

Did you use -server parameter when you start test? without -server results are very different, because jvm doesn't optimize speed but class loading times.

wetbot wrote:
Well, if jokipii's benchmark is correct, Klaatu is already exceeding 100mm/sec with memory usage of just 641k, and Klaatu uses an algorithmic FST minimization technique, so I doubt it can be reduced further. Klaatu just uses a few bit shifts and 5 array lookups, and my understanding was that RayW was pretty similar (ie relies primarily on array lookups). In fact, since Klaatu's arrays are so much smaller, my understanding is that it is much faster when RayW when evaluatiing random hands (different benchmark technique). What is RayW doing differently that accounts for its speed advantage? I guess it might have to do with the flush-checking algorithm?

It is exactly flushes what makes the difference. When Klaatu FastEval uses calculation and one more table check to get flush ranks, RayW contains all states in look up table and needs only lookup.

wetbot wrote:
If someone wouldn't mind telling me how the RayW code is labeled within the source zip files, I could look for myself, but so far, I can't tell which one it is -- I don't see any files named RayW.


It uses spears2p2 generated handRanks table (StateTableEvaluator) and whole thing is inlined to test method inside PerformanceTest2. It is like:
Code:
   public static void testRayW() {
      StateTableEvaluator.initialize();
      int h1, h2, h3, h4, h5, h6, h7;
      int u0, u1, u2, u3, u4, u5;
      int[] handRanks = StateTableEvaluator.handRanks;
      long time = System.nanoTime();
      long sum = 0;
      for (h1 = 1; h1 < 47; h1++) {
         u0 = handRanks[53 + h1];
         for (h2 = h1 + 1; h2 < 48; h2++) {
            u1 = handRanks[u0 + h2];
            for (h3 = h2 + 1; h3 < 49; h3++) {
               u2 = handRanks[u1 + h3];
               for (h4 = h3 + 1; h4 < 50; h4++) {
                  u3 = handRanks[u2 + h4];
                  for (h5 = h4 + 1; h5 < 51; h5++) {
                     u4 = handRanks[u3 + h5];
                     for (h6 = h5 + 1; h6 < 52; h6++) {
                        u5 = handRanks[u4 + h6];
                        for (h7 = h6 + 1; h7 < 53; h7++) {
                           sum += handRanks[u5 + h7];
      }}}}}}}
      print(sum, time, 133784560, 6);
   }


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 12:04 pm 
Offline
Senior member
User avatar

Posts: 172
Favourite Bot: don't know
jokipii wrote:
bluegaspode wrote:
Lookup is now:
level6aPointer=level5[level5Pointer+card5]
level6bPointer=level6a[level6aPointer+card6/13]
level7Pointer=level6b[level6bPointer+card6-(card6/13*13)]

What i don't get is last operation where cad6 - (card6/13*13), because is always equals to 0. OK, you probably mean card6 % 13, that makes exactly same thing that my but with card order 2c, 3c, 4c,... Ks, As.


Yeah card6%13 is the same.
I was thinking of a way I could easily compress the tables.
When I use card/13 I can just remove duplicated blocks. When you use card6&3 you had to reorder the blocks.
Both had to be tested though, as different handrank-order might lead to different and better compressions.


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 12:17 pm 
Offline
Senior member
User avatar

Posts: 172
Favourite Bot: don't know
jokipii wrote:
Hi
wetbot wrote:
...
But my results are as follows, so I cannot see a 'almost-as-fast' speed. Or did I start the wrong tests ?

Did you use -server parameter when you start test? without -server results are very different, because jvm doesn't optimize speed but class loading times.


I didnt, but did now.
Indeed hotspot is now optimizing the code path (one of the thing I like java - the longer the server runs, the faster it will be :) ) ... but get the following results:

Code:
---- Test set run 1----

Loading evaluation tables ...
Evaluation tables loaded in 1.118 seconds
Memory used: 128 Mb
( 7) Spears adaptation of RayW LUT hand evaluator, http://pokerai.org/pf3, http://forumserver.twoplustwo.com
--- Million hands per second: [b]129,677271[/b], hands 133784560, checksum 1528972275512, total time(s): 1.03167316

(15) Klaatu FastEval with partial state generation, http://pokerai.org/pf3
--- Million hands per second: [b]59,319313[/b], hands 133784560, checksum 215572899988, total time(s): 2.255328889

[...]

---- Test set run 5----

Loading evaluation tables ...
Evaluation tables loaded in 1.108 seconds
Memory used: 0 Mb
( 7) Spears adaptation of RayW LUT hand evaluator, http://pokerai.org/pf3, http://forumserver.twoplustwo.com
--- Million hands per second: [b]195,763829[/b], hands 133784560, checksum 1528972275512, total time(s): 0.68339775

(15) Klaatu FastEval with partial state generation, http://pokerai.org/pf3
--- Million hands per second: [b]104,577318[/b], hands 133784560, checksum 215572899988, total time(s): 1.279288499


So one can see big improvements for both, but they are still worlds apart.


Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 5:42 pm 
Offline
Senior member
User avatar

Posts: 172
Favourite Bot: don't know
So I implemented level6 compression (on top of the splitted and compressed tables), here are the results:

Level6-Size (MB):23.8
Level6a+6b-Size (MB):9.8

We save 14MB :)

Attached you will find a new Test.java.
I didn't change the Generator-class, because creating Level6a+6b is so fast, that I do it on the fly.
Thus I don't need to wait for the tables to be created each time.

This is what I changed:
TESTRUNSPERTEST - each test is run more times, to get better timings
testJokipiiSplitCompressed2() - uses level6a+level6b
testCorrectnessSplitCompressed2() - uses level6a+level6b
create6ab() creates level6a+6b

This are the results, with '-server', test-run 5 to allow java warm-up-time
Code:
---- Test set run 5----

( 7) Spears adaptation of RayW LUT hand evaluator, http://pokerai.org/pf3, http://forumserver.twoplustwo.com
--- Million hands per second: [b]188,596522[/b], hands 1337845600, checksum 1528972275512, total time(s): 7.093691796

(19) Jokipii's compressed LUT Evaluator, http://pokerai.org/pf3/
--- Million hands per second: [b]164,788160[/b], hands 1337845600, checksum 1528972275512, total time(s): 8.118578409

(19) Jokipii's compressed LUT Evaluator, http://pokerai.org/pf3/
--- Million hands per second: [b]150,759759[/b], hands 1337845600, checksum 1528972275512, total time(s): 8.874023234


So the current change looses us 14mill hands/sec.
Anyway - using (card%3) might be faster for lookup - but as written would involve some reordering of level6b table.


Attachments:
Test.zip [5.38 KB]
Downloaded 66 times
Top
 Profile E-mail  
 
 Post subject: Re: 7-card Poker Hand Evaluators
PostPosted: Sun Mar 07, 2010 7:35 pm 
Offline
Junior member
User avatar

Posts: 39
Favourite Bot: none
Hi

Seem like I am late :-) Here it is anyway... currently it work only on handIndex6... same thing should work also on handIndex5, but something isn't right so current version uses it only to handIndex6.

My algorithm also have some problem because I get handIndex6 12578540 bytes :-( So there must be still repetitions.

I made also other changes like check that ensures that loaded jhandRanks.ser is created with same mode that it is used, and speed optimization to index creation etc...


Attachments:
File comment: new compression mode
jokipii.zip [75.66 KB]
Downloaded 79 times
Top
 Profile E-mail  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 399 posts ]  Go to page Previous  1 ... 15, 16, 17, 18, 19, 20  Next


Who is online

Users browsing this forum: No registered users and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: