> While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity.
Have you ever played around with BeOS or its community-driven successor Haiku? They are what's called "pervasively multithreaded" such that every single widget in the standard UI toolkit has its own thread. It's literally possible in BeOS/Haiku to lower the priority of a single radio button.
This is an OS designed around early '90s era dual CPU hardware. Considering that they made this choice at that time and still ended up with an OS that's remembered primarily for its performance and responsiveness when multitasking it seems hard to believe that threading overhead itself is too big of a deal even at extreme levels.
> IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.
This is for entirely different reasons. The specialized supercomputer interconnects exist to minimize the cost of sharing data across nodes. Basically they provide DMA over a network fabric. It only really matters once your workload is large enough that you can't just throw a larger single machine at it but also impossible to split up in to smaller chunks that would fit within individual nodes.
If you're familiar with NUMA in multi-socket systems (or first-gen Epyc/Threadripper) you can think of the supercomputer interconnects as basically extending that principle up another tier to encompass multiple independent servers.
> It's literally possible in BeOS/Haiku to lower the priority of a single radio button.
This is not true, individual widgets most definitely do not have their own threads. Windows each have their own threads, which is indeed different from virtually every other OS which does not have this (or even allow off-the-main-thread UI operations.)
Have you ever played around with BeOS or its community-driven successor Haiku? They are what's called "pervasively multithreaded" such that every single widget in the standard UI toolkit has its own thread. It's literally possible in BeOS/Haiku to lower the priority of a single radio button.
This is an OS designed around early '90s era dual CPU hardware. Considering that they made this choice at that time and still ended up with an OS that's remembered primarily for its performance and responsiveness when multitasking it seems hard to believe that threading overhead itself is too big of a deal even at extreme levels.
> IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.
This is for entirely different reasons. The specialized supercomputer interconnects exist to minimize the cost of sharing data across nodes. Basically they provide DMA over a network fabric. It only really matters once your workload is large enough that you can't just throw a larger single machine at it but also impossible to split up in to smaller chunks that would fit within individual nodes.
If you're familiar with NUMA in multi-socket systems (or first-gen Epyc/Threadripper) you can think of the supercomputer interconnects as basically extending that principle up another tier to encompass multiple independent servers.