More platforms supported in enki::GetNumHardwareThreads about enkits HOT 5 CLOSED

Is it conscious decision to support only Windows manually, and delegate other platforms to STL?

Yes.

If yes, what's the reasoning behind this?

See below.

If not, do you plan to add more platforms?

No, there is no need. Other platforms should work with the STL implementation (note: UWP and MinGW on Windows 10 an earlier may not be able to address >64 hardware cores, but there is no workaround for this).

Explanation

This is because on some versions of Windows have an issue where std::thread::hardware_concurrency() will not report more than 64 hardware threads, thus we need to both use the Windows SDK function GetActiveProcessorCount() and also use a complex approach to distributing the task threads in StartThreads(): https://github.com/dougbinks/enkiTS/blob/master/src/TaskScheduler.cpp#L387-L437

The reason for this is that Windows only used to support up to 64 hardware threads. Support for more was added via processor groups, which needed the application to be processor group aware. The standard STL implementation was not processor group aware since processor groups are not part of the C++ standard. Microsoft has since modified this, and with WIndows 11 (or Windows Server 2022) applications are by default not constrained to a single processor group.

For more details see:
https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups

So for other platforms we can rely on the C++ STL.

from enkits.

Somewhat realted question: what's the return value of enki::GetNumHardwareThreads on hyperthreaded platforms: virtual or physical cores? If it was a deliberate choice, what's the reasoning behind it?

from enkits.

GetNumHardwareThreads() returns the number of hardware threads or logical processor cores, more properly named execution contexts. This supports hyperthreading.

In the case of a 4 core CPU with hyperthreading (2 execution contexts per core) GetNumHardwareThreads() would return 8.

You'll often see Intel (and other industry) documents refer to CPUs as having nCmT (for example 4C8T) where C means Core and T means Threads.

There is much debate on hyperthreading vs non-hyperthreading, but this can be very application specific, so enkiTS defaults to exposing all available hardware threads.

from enkits.

I am sorry that this discussion strays off-topic, but you seem the right person to ask.
How can I decide if I want to default on logical or physical processor cores? Any material to read maybe?
We are working on game engine, which used to stick to "thread pool size == num hardware cores", but it always felt like an arbitrary choice for me, not something properly motivated and reasoned.

from enkits.

The only really valid approach is to profile both alternatives. Hyperthreading's advantages rely on the processor being able to co-issue instructions from different threads, and thus any performance advantages/disadvantages depends on the code you run as well as the CPU architecture.

However do note that controlled tests may not exhibit the same behaviour as deployed applications on customer computers. For example in order to ignore hyperthreading place your one thread per physical core you will need to use CPU affinity. If another application running also uses CPU affinity you could end up in a situation where you map your threads to the same logical cores as the other application, which would be worse than supporting hyperthreading.

Additionally, CPUs are becoming more complex. We now have hybrid CPUs where some cores have hyperthreading and some do not. If your code does not support this you could end up not using some physical cores.

Another approach is just to reduce the number of threads you launch, and let the OS schedule.

from enkits.