Hi all!

Do you know any working version of 2+2 poker evaluator that can be used in Python project?

I'm not that familiar with the evaluator, but if it's written in C or C++ it should not be too hard to make a python wrapper for it.

OP, I assume you mean this code:
https://github.com/tangentforks/TwoPlusTwoHandEvaluator

If so, RustyBrooks has the right idea. Cython wrapper:
https://medium.com/@shamir.stav_8331...n-b09db35012a3

Ref to 2017 thread about evaluator that has links to the original thread:
https://forumserver.twoplustwo.com/1...stion-1685353/

I should expect quite big drop in efficiency, shouldn't I? Thanks for the answers.

Reading the tutorial your C/C++ will be compiled so you should have the speed benefit of that language.

The wrapper just lets you make calls and receive output from your python code. The bulk of the evaluator will still execute in the c code so I wouldn't expect a huge loss in efficiency.

Unless I'm mixing up the 2+2 evaluator with another one, an evaluation is really just 7 consecutive reads from a large integer array.

Idk much about Python performance, but if you are doing individual hand evaluations through a C wrapper then that's probably going to see a massive performance hit. That just based on the fact that a single evaluation is nothing more than a bunch of array reads, even a fairly efficient wrapper is likely going to introduce significant overhead there. If you are doing entire enumerations with a single call to the C library, that's a different story and you'd probably get very close to the C performance.

For individual evaluations you are probably better off to read the lookup array into Python and then do the evaluation there, there's no actual hand evaluation code beyond generating the lookup table. Or use an entirely different evaluator, as the 2+2 one isn't very efficient for individual/random evaluations anyway.

Did you guys think to create a poker evaluator working on GPU? Sounds like a possible thing to me considering all paralellization possibilities when simulating new hands.

What OS would run on the GPU? Not windows. Linux maybe?

Is there a single core processor running on recent desktops today? You don’t need a GPU to implement parallel algorithms.

@adios High end GPUs can run more than hundred times as many floating point operations per second than a high end CPU of comparable cost. But GPUs are only efficient for certain types of work loads.

Yes, it's possible to run 7 card evaluations on the GPU in principle. The 2+2 evaluator would be trivial to run on a GPU, although I believe it would have bad performance due to the GPU memory model. Whether it makes sense to run hand evaluations on the GPU in general depends on what you are trying to do. Hand evaluations rarely make up a significant chunk of the overall runtime anyway.

I was under the impression that the benefit of a GPU wasn't running things in parallel.

The GPU is better at manipulating vectors so if your algorithm or part of your algorithem is intensive vector manipulation the GPU can provide you better performance.

You don't run an OS on the GPU - you use a programming paradigm like CUDA.

Running things on a GPU provides massive parallelization if the problem can be broken up appropriately. Modern GPUs have thousands of small cores - like the nvidia 1080 Tis has 3500-something cores. Like plexiq said, I don't think you'd get a lot of benefit here because the cores would all be fighting for their own memory.

I've been out of the space for a long time but there were people doing really amazing graph theory algorithm stuff on GPUs years ago.

I'll just have this idea in mind. Lookup tables aren't the best way to aproach this problem but I believe there's a way to treat it in a more gpu friendly manner. I'll let you know in case I figure out something. I'm sure there's a bunch of low, high-level language developers who would like to use it. Cheers

Idk, what's your use case for a GPU accelerated hand evaluator?

As I mentioned before, the hand evaluator is almost never the bottleneck unless you just want a plain equity calculator. And these run fast enough even with regular evaluators.

There was going some kind of a competition which algorithm is faster. That would be just cool to create an algorithm for Python as fast as C++ 2+2 evaluator. Coding is fun. Nothing beyond that

The 2+2 evaluator would not be a good candidate for GPUs.

There is an evaluator that I'm working on converting to a GPU that is comparatively fast (about 1 second on my Dell to evaluate all 133,784,560 7 card combinations in Java). It involves clever bit-shifting which a GPU can do well. The code uses 1 IF statement which I am in the process of removing, which as you may know kills GPU performance.

Apologies for not addressing this sooner. The fastest I could get my 1080ti was 70M/second, which is only about half the speed of the Java based hand evaluator running on a single thread.

Because efficient hand evaluators require only a few operations per hand, GPUs lag behind a CPU. I'm guessing if 100+ operations were required per hand, then GPUs would be faster.

I did not test my GPU evaluating multiple hands per iteration to return the best hand(s), i.e. multiple input array arguments. There would be a point of diminishing returns as a larger input array reduces the number of parallel threads on the GPU.

Update 2: I was able to integrate SKPE into a 3-gpu config with some pretty impressive results, on the order of 20 billion heads up evals/second. It gets slower obv for more villains.

I wrote it specifically for win equity values, so there is some state optimization going on. But IMO I don't see a the purpose of a super fast eval other than for WE calcs.