I’ve been rewriting the topology code.
This code is partially an abstraction layer (and so that part must be friendly to users, easy to understand and implement). It has the job of representing the system processor topology in a btree, i.e. NUMA nodes, sockets, caches, physical cores, logical cores.
Under Linux, it’s easy.
Under Windows, OMG I don’t even
The problem is Windows has added into the mix a completely redundent, unnecessary and complicating concept called a “processor group”. Actual logical core IDs only go up to 64 – the largest number of logical cores in one processor group. So to identify a core, you must identify the processor group, too. Processor groups *SPAN NUMA NODES*, so the members are potentially HETEROGENEOUS.
Because the processor group must be specified, when you start using the Windows API for enumerating topology, you can have MULTIPLE entries for the SAME entity, where each entry lists a set of logical cores *for the same processor group*. So a given socket might have say four entries, all the logical procesors in processor group 0, then all those in group 1, etc.
Now, remember – I’m representing the topology in a btree. To link an element, I need in fact to know its full set of logical processors, so I can sort it to the correct location in the tree. In Windows, I can only KNOW that I know this BY FULLY ENUMERATING THE ENTIRE TOPOLOGY, i.e. I actually have to iterate over the entire topology for EVERYTHING I FIND, to ensure I have every logical processor which belongs to it.
The only reason for this madness is processor groups, which I’m going to utterly ignore, always (except I need to know them to be able to start threads on the logical cores I want).