Multiprocessors weren't commonplace until users of the Windows 9x kernel were dragged screaming and kicking to the XP kernel. 64-bit processors were not commonplace until AMD came out with a clever way to make them look like 32-bit ones that could run 32-bit Windows.
In the meantime, Unix users were using 64-bit multi-processor boxes since ages. Yet, there was no mainstream consumer 64-bit multi-processor architecture before there was no 64-bit multi-processor mainstream consumer OS.
The same applies here - most current improvement is directed towards making current x86 and ARM computer architectures faster because there is no popular corpus of software that could take advantage of different architectures. Sony, IBM and Toshiba tried with the Cell and failed. The Xeon Phi may prove to be an interesting stepping stone in that direction but it too uses a shared memory model.
I'd love to see some radical ideas tried, but, right now, I think I won't.
It's a bit tragic that the most popular OSs of today are the bastard descendants of the most popular mini-computer OSs of the 70's.
Although Unix was not designed for multi-processors originally, its main run-time abstraction (process networks) is easy enough to port to any platform with a common store. So there's not much to discuss about single-core vs multi-core, it's either one VN or multiple VN machines connected to a single abstract memory.
Remove the shared memory, then issues start to rise.
You say "radical ideas tried" but I believe that is not relevant. Radical ideas typically don't fly because they are radical. However you can already see things happening that are not radical but are breaking the Unix machine model very hard:
- "accelerators": these are really fully fledged co-processors with their own local memory. There is no easy way to conceptually delegate Unix threads to accelerators precisely because they don't share the memory. (Now with recent GPUs the architecture was modified to actually share the memory between the CPU and GPU so things become possible, but not all "accelerators" have that feature)
- on systems-on-chip you now have scratchpads next to cores on the architecture. Some cores may not have access to the "main" memory of another core (eg the radio controller in telephones) although they are fully-fledged cores as well. Because of this lack of shared memory, it is not conceptually possible to envision a Unix system where processes access these extra processors transparently.
tl;dr there are already hardware architecture with separated memories and Unix can't cope with that easily because its main abstraction requires shared memory.
In the meantime, Unix users were using 64-bit multi-processor boxes since ages. Yet, there was no mainstream consumer 64-bit multi-processor architecture before there was no 64-bit multi-processor mainstream consumer OS.
The same applies here - most current improvement is directed towards making current x86 and ARM computer architectures faster because there is no popular corpus of software that could take advantage of different architectures. Sony, IBM and Toshiba tried with the Cell and failed. The Xeon Phi may prove to be an interesting stepping stone in that direction but it too uses a shared memory model.
I'd love to see some radical ideas tried, but, right now, I think I won't.
It's a bit tragic that the most popular OSs of today are the bastard descendants of the most popular mini-computer OSs of the 70's.