>Yes but your computer will not gracefully handle CPUs randomly failing or RAM randomly failing
That's incorrect.
There are plenty of machines/OSs which are (or can be) resilient to a CPU failing; Linux, for example. From the OS point of view, you just kill the process that was running on the CPU at the time and move on.
Resilience to spontaneous RAM failures is rarer but possible.
Killing the processes running on the compute element seems not very graceful, right? I'd expect a gracefully handled failure to have some state staved from which the computation can be continued.
Which would be overkill on a single node, given that CPUs don't really fail all that often.
It's up to userspace to do more than that. There are other issues which can cause processes to be spontaneously killed (OOMkiller for example) so it's something you should be tolerant of.
Disagree. An environment that's being reaped by OOMK is not stable enough to make assumptions about. You're in "go down the hall and turn it off and on again" territory.
Attempting to account for such environments in user programs massively inflates their complexity, does little to enhance reliability, and the resulting behavior is typically brittle or outright broken from the get go.
This is why, for example, the C++ committee flirts with making allocation failure a UB condition.
That's incorrect.
There are plenty of machines/OSs which are (or can be) resilient to a CPU failing; Linux, for example. From the OS point of view, you just kill the process that was running on the CPU at the time and move on.
Resilience to spontaneous RAM failures is rarer but possible.