Page 3 of 3 FirstFirst 123
Results 27 to 31 of 31

Thread: MGP: Comp speed that doesn't make sense...

  1. #27
    MGP
    Guest

    MGP: Good Idea!

    > When running the all-inclusive version, have
    > you tried displaying the
    > "incremental" values for
    > ProcessorTime as the upcard changes? If the
    > extra time is spread out through all upcards
    > proportionally, you probably won't learn
    > anything, but if the extra time comes from
    > just one or two upcards, it could help you
    > zero in on the problem.

    > Admittedly, it's a longshot! I'm just not
    > believing that memory-allocation can be
    > that expensive.

    Ok, so the reason I had actually checked them all separately was for exactly the reason you stated, but I didn't think to check the individual times within the full run.

    The result gives a partial explanation of how poor a programmer I am... When I did the run, all the upcards took about 50s. I realized right when I saw that, that when I run through the dealers hands, I use all of them and just multiply by zero for hands that aren't possible for a given upcard... When I run them separately, only the relevant dealer hands for the given upcard are determined. In a very early version of the program I had tried using only the relevant dealer hands vs multiplying by zero for the given upcards and the latter was faster for some reason. I'm guessing now with all the additions to the program the former will be, so I have to fix that now.

    It's not the entire explanation though since the longest time for an individual upcard was with 2 and that was 25s - which is still 2x faster than the calculations for a 2 upcard when all are run together.

    Great idea though and I'll let you know if it speeds things up adding a tag to ignore hands for given upcards. I'll also move the upcard loop to the outside since that cut some time off as well.

    Thanks,
    MGP

  2. #28
    Magician
    Guest

    Magician: Re: The numbers and the code

    > Ok, below is what the highly abbreviated
    > code looks like:
    > for player hands
    > for dealer hands
    > for upcard=minupcard to maxupcard
    > Calculate StandEV
    > next upcard
    > next dealer hands
    > next player hands

    Hi MGP. This doesn't seem like the best way to nest your loops to me. I would have thought:

    for upcard=minupcard to maxupcard 
    for player hands
    for dealer hands
    Calculate StandEV
    next
    next
    next


    This may or may not significantly effect the execution time - I can't be sure without seeing the actual code.

  3. #29
    MGP
    Guest

    MGP: Re: The numbers and the code

    > Hi MGP. This doesn't seem like the best way
    > to nest your loops to me. I would have
    > thought:
    > for upcard=minupcard to maxupcard
    > for player hands
    > for dealer hands
    > Calculate StandEV
    > next
    > next
    > next
    > This may or may not significantly effect the
    > execution time - I can't be sure without
    > seeing the actual code.

    I tried that just to check the time difference and it did save a little (see one of my posts above). If I can get some time to get back to my program, after this discussion I've decided to move the upcard loop to outside the dealer hands loop, i.e.:
     
    for player hands
    for upcard=minupcard to maxupcard
    for dealer hands
    Calculate StandEV
    next
    next
    next

    .
    The reason I need to keep the player hands loop on the outside is because when I incoporate counting probabilities, you need to actually deal out the player hands to get the correct probs. This is very slow and so I want to limit that to once per hand.

    This discussion has also given me several ideas on how to speed things up. It's going to take some time to get everything programmed and try a couple of variations, but once I do I'll post the results.

    Thanks again to everybody who helped.

    Sincerely,
    MGP

  4. #30
    MGP
    Guest

    MGP: Problem Solved - Thanks

    Ok, so I finally got around to trying a few things and the problem is now solved. I rearranged the loops as mentioned and I found a redundant calculation that was really slowing things down and limited the calcs to only hands that are used for a given upcard and the total calculation time is now down to 65s This is compared to 396s all upcards together and 123s separately before. Calculating each upcard separately now adds up to about the same time as doing them all together. I can't explain why because I'm not sure...

    Now I'm not sure if how the array is accessed is making a big difference anymore but I know the program is a lot faster now.

    Sorry for all the confusion but it really had me stumped and this discussion helped clarify things a lot for me, so, thanks to all that helped!!

    Sincerely,
    MGP

  5. #31
    Keith Collins
    Guest

    Keith Collins: Gr8! :-) *NM*


Page 3 of 3 FirstFirst 123

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

About Blackjack: The Forum

BJTF is an advantage player site based on the principles of comity. That is, civil and considerate behavior for the mutual benefit of all involved. The goal of advantage play is the legal extraction of funds from gaming establishments by gaining a mathematic advantage and developing the skills required to use that advantage. To maximize our success, it is important to understand that we are all on the same side. Personal conflicts simply get in the way of our goals.