CCC/TCEC and processor affinity

[jdart]

I have started to look again at the NUMA support in Arasan, partly because of the Windows issue with >64 thread support requiring processor group support.

For those for whom that needs a little more explanation: normally programs with multiple threads have the threads assigned to processing units (which could be a core, or part of a core, if hyperthreading is enabled), by the operating system scheduler. This assignment is not necessarily permanent: a thread could be moved to another processor later, to balance the load on the system. There is some performance cost to reassignment, though.

It is common in HPC (High Performance Computing) applications to "pin" threads to processors, so they can't migrate. This is called setting processor affinity. This is for several reasons. For one thing if you're not using the whole machine you probably want to ensure that application threads are located "near" each other, where "near" depends on the machine but could be on the same socket, or same local memory bank, for example.

(I am omitting a bunch more details - but this is probably enough for now).

Quite a few engines now support this. Some may do it by default. The issue with tournaments is this: using affinity pretty much assumes your program has the freedom to use CPU resources as it wants, regardless of what else might be running on the system. If you have two programs running that both make this assumption, they can do things like allocate threads to the same processing unit(s) rather than equitably sharing resources, as the OS scheduler would do. This will work, but it won't be optimal because some processors might be over-allocated (forced to share work between two processes) and some might be idle. There is no standard that I am aware of that lets programs be aware of what other programs might be doing with affinity or that lets one program safely allocate part of the machine and another program allocate another part (CPU numbering is not standard, and "part" can mean a lot of things depending on the hardware).

So if TCEC or CCC plan to run programs that use processor affinity, IMO they should run each program on a separate physical machine or separate VM configured to correspond to one or more NUMA nodes. (SSDF has always used two machines for their matches).

(Note that for Arasan affinity is an option - however with >64 threads in use on Windows, threads are still bound to processor groups, which may raise similar issues if that number of threads is allocated).

This might also apply to CEGT and CCRL, etc. but most of their matches are single core.

--Jon

[megamau]

Or play without Ponder.

[jdart]

No ponder alleviates the issue but may not eliminate it completely, because I think you still may not get the full benefits of affinity if different programs are pinning the same cores.

--Jon