jpaulm
commented
9 years ago Response from Humberto Madeira (via email):
From what I recall, Windows NT 3.1 (circa 1993) was already multiprocessing capable. It could allocate processes and threads across multiple processors.
At the time, the performance profile was such that you would get steadily decreasing performance gains up to a peak of 4 processors, but the scheduling overhead made performance actually drop past that, so much so that at 8 processors, it would actually run slower than one.
Scheduling with cores is more efficient than scheduling across processors, so that Windows XP could take better advantage of a 8 core (4 core 2 processor) setup (circa 2007) specially since many applications (and the OS itself) were more multi-threaded by then.
Since then, a lot of improvements have been made in the hardware to reduce the cost of moving data between cores (and to a lesser extent, processors) I'm currently building a 32 core (16c x 2p) box that's not too outrageously expensive.
And for those of us with really deep pockets, you can even build up to a 144 core (18c x 8p) system using the latest Xeons (running a more expensive version of Windows).
In addition to cores, some of the Intel chips have hyper-threading, where one core can run 2 separate threads concurrently. That 144 core Windows setup should be able to run 288 concurrent threads at the same time.
So yes, processes and threads can take advantage of multiple processors, multiple cores and hyper-threads. The limiting factor has more to do with the amount of interdependency (mutexes, semaphores) between application threads
As far as I know, only CppFBP of the three implementations mentioned (THREADN, THREADN with fibers and CppFBP) can support multiple cores. However, https://msdn.microsoft.com/en-us/library/windows/desktop/ms681917%28v=vs.85%29.aspx seems to suggest that processes and/or threads can take advantage of multiple cores - curious if this is true...? Windows has probably gotten more sophisticated since THREADN was written...!