Which version of C should I use when Perl is too slow?

Sorry if this question sounds particularly naive.

I'm getting ready to write code to analyze a poker game variant. I expect that the computations will require a computer to run for, literally, months, to complete the analysis. (I've become certain that the analysis for this game has not been done before, so I can't just find the analysis online.)

The program will need to look at every possible player hand, and for each hand evaluate what to do against every possible dealer hand; there will be over a quadrillion iterations happening.

There'll be simple math, lots and lots of comparisons, array lookups, loops and loops and loops, hopefully not that much sorting.

I am not a professional programmer, and I do 99% of my programming in Perl, which is easy for me. It'd be (fairly) straightforward for me to write the necessary code in Perl, but I'm afraid it would take forever to run. Or longer.

I have programmed a couple of medium-complicated iPhone/iPad apps, which use Objective C. So, I do have some foundation in C, although it's been a couple of years since I did any Objective C programming.

My questions are: Is this likely to be a disaster if I do it in Perl? Then, I understand there are different "versions" of C  --  straight C, C#, C+, etc. If I'm to start as a not-quite-beginner learning some C to use for this project, is it clear which C I should be using?

Thanks for any insight.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AndyAinscowFreelance programmer / ConsultantCommented:
Forget C.
C++ should run faster than C# (provided you code it well).

Have you done some maths or is that a guess?  
I expect that the computations will require a computer to run for, literally, months, to complete the analysis.
I've not done the maths but you might want to substitute centuries for months in that sentence.
Kent OlsenData Warehouse Architect / DBACommented:
Hi Steve,

That kind of analysis is beyond the ability of a mere mortal to process.  

There are approximately 37 million poker hands from a 52-deck pack.  Multiply that by the number of possible hands per dealt hand and the numbers are staggering.  Managing the volume of results is beyond the ability of most desktop computers.

I suggest that you base your analysis on patterns and pattern matching.  The programming might seem a bit more complex, but you'll get a quantity of answers that you can manage.  And an heuristic algorithm can adjust to its findings in real-time whereas the brute force approach never can.

Any C compiler should be just fine.  gcc is as good as any of them.

Good Luck!
Personally, I'd recommend plain C.  Have you done research to see if there are any language that is more appropriate to what you are trying to do?

Can you write the code that you think will run the slowest in both Perl and C and benchmark them?

C++ is a superset of C.
You probably know more about Objective C than I do
C# actually has nothing to do with C - it is much more akin to Java.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

C or C++ should be about the same if you aren't using inheritance or any of the "fancy" C++ stuff.

Brute force for this is never going to work. Even if you bought time on an Amazon cluster or something, it will never finish.

You probably could pull it off by thinking of "every possible hand" as "every possible type of hand" (straight, flush, one card off from straight, etc). Without knowing what variant, it's tough to make precise suggestions. That should get your search space down into the millions or something else feasible.
Kent OlsenData Warehouse Architect / DBACommented:
Rank the possible hands by general type

- straight flush
- 4 of a kind
- full house
- straight
- 3 of a kind
- 2 pair
- 1 pair
- high card

Then determine what you want to solve.  i.e. what are the odds of this hand winning.

Are you playing straight poker?  (deal 5)
Are you playing 5 card draw?  (deal 5, draw up to 3)
Are you playing the popular Texas Holdem?  (with common cards)

The analysis is quite a bit different between them.  But the goal is the same.
+1 for AndyAinscow's recommendation. These days, the "plain C" actually means to use some C++ compiler and use the subset of the language. It also means that the compiler uses the same optimizer of the produced machine code. When using C++ code, the optimizer have more information to optimize better than the same solution written in plain C. (This is for the case when the same design is used, and when the C++ is used correctly.)

If you can choose, use C++11 standard compliant compiler. The new syntax allows much nicer code (to write and to read). For Windows, try Visual Studio 2013 Community Edition (for free; https://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx), for Linux, probably the latest gcc.

C++, C#, and Java are the C-family languages (because of the syntax). However, plain C and C++ are close to the hardware, while C# and Java are otherwise.
AndyAinscowFreelance programmer / ConsultantCommented:
Further to my first comment, some crude approximations.
5 card hand for player from 52 cards means
52*51*50*49*48 possible combinations, call it 50 to the power 5 which is then a bit more than 300,000,000.  Call it the same for the dealer so combinations are 90,000,000,000,000,000.
Say the PC can handle 1 million hands per second (WOW, some PC) that means it will take 90,000,000,000 seconds.
One year is 365*24*60*60 seconds which is a bit over 30,000,000.
So this will take about 3,000 years on this extremely fast PC.

So I'll make a correction to my first comment:

I expect that the computations will require a computer to run for, literally, months, to complete the analysis.
I've not done the maths but you might want to substitute millenia for months in that sentence.

replaced centuries with millenia
> 52*51*50*49*48
If you pick up all 5 cards at once, rather than betting after each hand, you could divide this by 5*4*3*2*1
dividing again for the dealer might reduce millennia to months.
You might also rename all the suits without changing the value of hands, which could let you reduce another factor of 24
It might also behoove you to use any other combinatorial shortcuts you can find.
But depending on the exact problem you are solving, it still may not be enough, and you may have to use some approximations instead of an exact count.
If you can specify the exact problem, we may be able to suggest some short cuts, but then it might be more mathematics suggestions than programming language suggestions.
StevenMilesAuthor Commented:
Thank you everyone for responding.

Andy, I was actually also worried that I would run out of time, because even the proton has a half-life of only about 10^40 years.

Kdo, I appreciate your input, but I was intentionally vague about exactly the game that is to be processed: a poker *variant*, not exactly poker. My thinking is that my project is possible, with attention to optimization, as you recommend. I was more interested in  generally whether I should leave Perl for C and which C I should go to.

Wilcoxon, it's a great idea to do a benchmark, although from what people comment, it'd probably be just to confirm for me that C is better.

Tommy, your comment about C vs C++ is about what I've been reading elsewhere. I've used inheritance, etc., in Objective C, but I don't think I'll need it for this.
Kent OlsenData Warehouse Architect / DBACommented:
Hi Steven,

If you'll program to the logic, perl, C, C++, FORTRAN, COBOL, or most any other language will be just fine.  You won't need lifetimes to complete the analysis (completely disregarding storage of the results).

But if you choose a processor intensive solution, most of the C compilers will produce similar results.

Going forward, you'll get better answers if you'll frame the question to better align with your needs.  :)

Good Luck!
StevenMilesAuthor Commented:
Kent, I appreciate the feedback. I don't post that often, and I can see now the importance of an exact definition of the question!
AndyAinscowFreelance programmer / ConsultantCommented:
>>Andy, I was actually also worried that I would run out of time, because even the proton has a half-life of only about 10^40 years.

It ought to have finished processing by then.  ;-)  

I was pointing out a brute force approach wouldn't work.  Even optimising things the time scale is still likely to be unrealistic - as soon as one card is dealt a lot of the symmetry is broken.  (eg.  Without a trump suit all 4 suits are equal, so the first card has 'only' 13 possibles but once that is drawn then the chance of another of that suit drops marginally compared to the other 3 suits).  I don't know what you wanted to achieve but a more specific target may be do-able.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.