Threads and cores questions

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Casey

Threads and cores questions

Post by Casey »

Some newbie questions. Suppose we have a processor of n cores:
1) Can we auto detect number of cores (specific for C++ and Debian Linux)?
2) What is the maximum number of threads should we create?
3) Is there any method to start and run a thread in a given core (C++ and Debian Linux)?
4) (Similar to 3) If a thread is created and started running on a core, this thread will "stick" forever with that core or it could "jump" from core to core?

Many thanks for any help.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Threads and cores questions

Post by bob »

Casey wrote:Some newbie questions. Suppose we have a processor of n cores:
1) Can we auto detect number of cores (specific for C++ and Debian Linux)?
2) What is the maximum number of threads should we create?
3) Is there any method to start and run a thread in a given core (C++ and Debian Linux)?
4) (Similar to 3) If a thread is created and started running on a core, this thread will "stick" forever with that core or it could "jump" from core to core?

Many thanks for any help.
1. Yes. Easiest way is to open /proc/cpuinfo and count the number of processors reported there. Works for all flavors of linux and most unix flavors (but not all).

2. Perhaps N+1, N searchers and one I/O thread. I use N. More than N is a bad idea as all you do is introduce extra context switching where one CPU flips back and forth between 2 threads (assuming you start 2N threads), extra locking overhead, and extra search overhead.

3. Any system that supports libNUMA supports user-controllable processor afinity. This includes any linux implementation at least, and I have used it on NUMA boxes (8-way AMD boxes, 16-way AMD boxes, etc...)

4. Recent linux kernels are very good at this. But that does not mean there is "zero bouncing". Interrupts still take precedence over running processes, so there will always be a bit of bouncing around, but it has become _very_ infrequent in recent kernels... Note that on core-2 duos it doesn't matter much since L2 is shared.