Detecting the number of CPUs

[Tord Romstad]

In Linux and Mac OS X, I use the following function to find the number of available CPUs:

Code: Select all

int cpu_count() {
  return Min(sysconf(_SC_NPROCESSORS_ONLN), 8);
}


This seems to work fine, but I also need a similar function for Windows. After some Googling, I came up with the following function, but because I don't have any Windows computers, I can't test if it works. Does the following look correct?

Code: Select all

int cpu_count() {
  SYSTEM_INFO s;
  GetSystemInfo(&s);
  return Min(s.dwNumberOfProcessors, 8);
}


The Min(<whatever>, 8) thing in the code is there simply because my program is currently limited to a maximum of 8 threads.

Tord

[Teemu Pudas]

It works here. The real test is whether it detects hyperthreading processors correctly, though.

[Tord Romstad]

It works here.

Thanks, great!

The real test is whether it detects hyperthreading processors correctly, though.

Probably not, I guess a hyperthreading processor will be incorrectly classified as multiple cores. Because hyperthreading processors are rare (are they even produced any longer?), I don't consider it to be a big problem. My program will be able to correctly detect the number of CPUs on most computers, and when it fails, it is always possible for the user to manually set the number of search threads.

Tord

[Tord Romstad]

I use getenv("NUMBER_OF_PROCESSORS"). Works with my P4 HT and AMD X2.

How does it compare to my function on the P4 HT? Do they give the same result?

Tord

[H.G.Muller]

Why would classifying hyper-threading as two cores be incorrect? It seems to me that if an SMP program has the opportunity to hyper-thread, it should make use of it for a significant spead-up. Chess programs are very often branch-predict limited, so hyper-threading should help to make much better use of the execute units.

[Dann Corbit]

Why would classifying hyper-threading as two cores be incorrect? It seems to me that if an SMP program has the opportunity to hyper-thread, it should make use of it for a significant spead-up. Chess programs are very often branch-predict limited, so hyper-threading should help to make much better use of the execute units.

From the measurements I have seen, using hyperthread CPUs as real ones has neither cost nor benefit for chess programs.

I think that the value gained by the free context switch is probably a wash with the battle for the *real* single register set.

[bob]

Why would classifying hyper-threading as two cores be incorrect? It seems to me that if an SMP program has the opportunity to hyper-thread, it should make use of it for a significant spead-up. Chess programs are very often branch-predict limited, so hyper-threading should help to make much better use of the execute units.

From the measurements I have seen, using hyperthread CPUs as real ones has neither cost nor benefit for chess programs.

I think that the value gained by the free context switch is probably a wash with the battle for the *real* single register set.

There isn't a "single real register set". But there _is_ a single real processor core. I found that enabling SMT produced a small NPS increase, but the overhead from the parallel search actually made performance (for crafty) worse. On my dual-xeon box, I have it disabled.

Some programs with excessive memory traffic might get a bit more from it, but once a program is tuned for Intel, hyperthreading generally hurts rather than helps. Thankfully it is a dead horse now...