Attached a standalone version of the code here, with a simple profiler running 10 mill random hands. Seems it only does 17M hands/s for me now, not sure if it's my compiler settings or if I did something wrong last time i tested it.

Didn't go through the comments, but guess they can be ignored for the most part :p

Guess I could share code for this too, but don't think I'll do so publicly.

Anyway, I read in hands at a format similar to what you mentioned, creating Range-objects hierarchically, combined with and or or links. After connecting all the rules it feeds hands through the different Rule-filters, eventually storing the final range as Hand-objects in a vector.

In no way rocket science, but it allows for complex combination of rules and a fast final product.

I use the solution " card evaluator and iterate over all possible combinations of board and holecards.".
The trick i use in addition when evaluating equity of range vs range, is to first iterate over all hands in both ranges and find best combination of board and holecard and write in dictionary (for fast access later). This is quite fast. Then when calculating range over range, it simply compares for every hand vs hand, the best combination of board nad holecard of hand1 with hand2, no need to find best combination in every iteration when calculating range vs range equity.
Still the issue i have is that ranges in omaha are quite huge, and it still gets slow to calculate range vs range.