std::vector<std::vector<bool>> result;
for (int card = 0; card < kNumCards; card++) {
result.push_back(std::vector<bool>());
for (int hand = 0; hand < kNumHands; hand++) {

Reserve. Reserve. Reserve. You know the sizes of your results, so reserve.

result.reserve(kNumCards);
for (int card = 0; card < kNumCards; card++) {
  result.push_back(std::vector<bool>());
  result.back().reserve(kNumHands);

This will avoid a lot of allocation/copy that is happening behind the scenes, and will help improve your write speed.

So, thi is a static method and only called once, at the start of the program. I dont care too much how slow that is, I'll fix it though obviously. But does it matter for later performanece of my program? Like, does the data lie in the memory more organized or something like that, so that the acccess is quicker?

Oh and what do you think about using two thread working parallel? My code looks like this:

/*** FICTICIOUS PLAY ***/
void StrategyPair::equilibrize(bool finish) {
        /* Couldnt I split this spart into a seperate thread and then work both strats simultaniously? */
        /* Part A */
	setMaxExploitEVs(SB, BB, finish);
	std::map<int, Range> sbMaxEVStrat = getMaxEVStrat(SB);
	updateRanges(SB, sbMaxEVStrat, totalIterationsDone);
        /* Part B */
	setMaxExploitEVs(BB, SB, finish);
	std::map<int, Range> bbMaxEVStrat = getMaxEVStrat(BB);
	updateRanges(BB, bbMaxEVStrat, totalIterationsDone);

	totalIterationsDone++;
}

Could I expect a double speedboost with that?

kNumHands is 1326. I believe it does have to be that large, because for every hand a player CAN have, I need the frequency (float) with which he holds that hand. While we're talking about floats. I could give up a little precision and use bytes to represent a percentage from 0to100 instead, but that has nothing to do with my performance, does it?

Using bytes instead of floats may help performance mainly because it makes the table 4 times smaller. Integer operations are also faster than floating point, but when you're using a lot of memory, that's not your bottleneck.

kNumHands is 1326. I believe it does have to be that large, because for every hand a player CAN have, I need the frequency (float) with which he holds that hand. While we're talking about floats. I could give up a little precision and use bytes to represent a percentage from 0to100 instead, but that has nothing to do with my performance, does it?

Using bytes instead of floats may help performance mainly because it makes the table 4 times smaller. Integer operations are also faster than floating point, but when you're using a lot of memory, that's not your bottleneck.

So, just to let me understand how this works. The problem of using alot of memory, is that it's split up over more caches and when I'm trying to access that memory, my program first has to search for where the data lies? So when I'm using 4times smaller data, the program should be able to find it ~4timmes as fast and thus speeding up all the array accesses by a factor of ~4?

Edit: would this still be an improvement, even tho I would have to convert the bytes to floats every time i access them? When I need the equity, saved in a byte, I would return it as float(value/255). Is that too slow?

Ok thanks, I read a little bit about it and think there are a few ways to improve. This question still remains tho:

would this still be an improvement, even tho I would have to convert the bytes to floats every time i access them? When I need the equity, saved in a byte, I would return it as float(value/255). Is that too slow?

Now I encountered another weird phenomenon. There are situations where I initalize both players strategies with a range containing only the top 25% of alls pokerhands f.e.

So instead of 1326 hands, the ranges only contain 1/4 of that. What I did now, was that when I initialize my strategies, I create two vectors<startingHand> only containing those hands which are played with a nonzero frequency (the top25% of hands in this example). Now instead of iterating over ALL hands when finding my best strat, I did something like this:

std::map<PlayerType, std::vector<startingHand>> rangeHands;

for(int i=0; i < rangeHands[playerA].size(); i++) {
      // now instead of "i" representing the hand, I use "rangeHands[playerA][i]"
      //e.g.
     EV[playerA][DecisionPt1][rangeHands[playerA][i]] = equity(rangeHands[playerA][i]) * pot;
}

I expected this to be alot quicker than iterating over all hands for the given 25% ranges. Indeed it was.

Previously:

After improvement:

What I also expected was, that when running the full 100% ranges again, this would most likely be slower, or at least the same speed, since I always had to look up the startingHand in the vector first. But I checked that again, and even with full ranges, this was quicker:

Without improvement:

With improvement (meaning iterating over the vector<startingHand>):

How is that possible?

kNumHands is 1326. I believe it does have to be that large, because for every hand a player CAN have, I need the frequency (float) with which he holds that hand. While we're talking about floats. I could give up a little precision and use bytes to represent a percentage from 0to100 instead, but that has nothing to do with my performance, does it?

Using bytes instead of floats may help performance mainly because it makes the table 4 times smaller. Integer operations are also faster than floating point, but when you're using a lot of memory, that's not your bottleneck.

So, just to let me understand how this works. The problem of using alot of memory, is that it's split up over more caches and when I'm trying to access that memory, my program first has to search for where the data lies? So when I'm using 4times smaller data, the program should be able to find it ~4timmes as fast and thus speeding up all the array accesses by a factor of ~4?

Edit: would this still be an improvement, even tho I would have to convert the bytes to floats every time i access them? When I need the equity, saved in a byte, I would return it as float(value/255). Is that too slow?

There's no searching involved. A cache (CPU or otherwise) is a local copy of data that would otherwise be slow to fetch each time. For example, your browser cache keeps a copy of the websites you visit, so that whenever you return to the same page, it loads faster. A cpu cache is fundamentally the same. It's high speed memory that's closer to the cpu core. But just like you can't download the whole internet (unless you're google), cpu caches have limmited space. So it will forget what's in memory that you haven't accesses in a while. Using less memory means you can fit more of your data in the cache.

That's a very rough overview of caching. The details of the cpu cache are more complicated than other caches, and there can be 3 levels of CPU cache. It's not a simple fifo queue for what gets removed, because the whole thing is optimized to be really fast to access. But that's the idea, and it explains why using less memory is better.

So, just to let me understand how this works. The problem of using alot of memory, is that it's split up over more caches and when I'm trying to access that memory, my program first has to search for where the data lies? So when I'm using 4times smaller data, the program should be able to find it ~4timmes as fast

this would have happened only if you had perfect cache no-escaping from within your cycles.

for(int i=0; i < rangeHands[playerA].size(); i++)

Compiler optimization will sure not optimize the condition expression and you will always read from a dynamic value samwhere far away, escaping a cache rapidly per cycle makes the fact that you reduced the size of array 4 times will do nearly nothing.

Ok, sorry for not responding in a while, I've been a little bit busy.

I just wanted to let you know that - thanks to your help - I was able to significantly improve the performance, but more importantly, this thread really taught me alot ;)

Thanks to all of you!