I wonder if certain applications would benefit from redundant setups in different cpu arches to check for discrepancies.. kinda like NASA stuff but different.
Ah, that could be. Though could that be talking about redundant processing (i.e. two dependent algorithms making the same decision) rather than duplicate hardware?
i guarantee the people building the spacecraft and choosing the CPUs have thought about this more than you, and have much more knowledge about the problem space than anyone here questioning their decision-making processes.
if it was a good idea to have multiple redundant CPUs on these spacecraft, the spacecraft would have multiple redundant CPUs.
You could probably do something like using idle cores (or idle hyperthreads) to duplicate instructions on an opportunistic basis to verify outcomes on a less than complete basis. There would be thermal and power consequences but some situations care about that less than others.
Static analysis would probably work in this case because the in-order core would be very GPU-like while the other core would not.
In cases where performance characteristics are closer, the OS could switch cores, monitor the runtimes, and add metadata about which core worked best (potentially even about which core worked best at which times).
Yes but you can see the most number of frameworks there running on the same hardware and same settings doing the same job. Also you can see the configuration how to achieve that.
Perhaps we should stop running multiple programs on the same hardware at the same time while making sure information isn't leaked between domains?
If the future provides us with large but thermally limited dies, I could see a scenario where CPU components are duplicated but not all running at once. A thread or set of threads could own a hierarchy of caches, for example. Caches are die-intensive, so I don't see this happening soon, but maybe at some point in the future.
OTOH, this could allow us to have very heterogeneous processors in a single system, each with an ISA tailored to a kind of task and the OS knowing which core can run which program.
Comparing bus states of two CPU's running of same clock is perfectly feasible and there are no problems with glitches as long as the whole mechanism is synchronous (and the CPU is completely deterministic, which it should be, but then there are things like RNG-based cache eviction policies). In fact both original Pentium and some m68k processors have all the required hardware for this included and building error checking pair of them involves literally connecting all bus pins of two CPUs in parallel.
If you divide that giant piece of silicon into 400k processors, and then only use the ones that actually work...
I wonder if they figure that out every time the CPU boots, or at the factory. At this scale, maybe it makes sense to do it all in parallel at boot. Or, even dynamically during runtime.
There may be edge case cores that sort of work, and then won't work at different temps, or after aging?
Sometimes you even have different firmware/software teams write code for each of the three different configurations (often targeting different processors/architectures, etc). Pretty cool
Not really, at least with how it currently works. Most OSes will redirect threads to the different cores based on their resource usage, which is impossible if each core was running a different architecture. No amount of magic will make it work elegantly, I'm afraid.
I think there would be a pretty large hardware cost to ensure the input signals come to both processors at the same clock everytime on the many high speed interfaces a modern CPU is using.
And you'd need to eliminate use of non-deterministic CPU local data, like RDRAND and on die temperature, power, etc sensors. Most likely, you'd want to run the CPUs at fixed clock speed to avoid any differences in settling time when switching speeds.
This could probably effectively fine broken CPUs (although you wouldn't know which of the pair was broken), but you could still have other broken devices resulting in bad computations. It might be better to run calculations on two separate nodes and compare; possibly only for important calculations.
With some software work, you could pair differing cores. You'd just deliver a signal to a process saying 'youre about to be moved to a different core type, please recheck the capabilities'.
Then, you'd have a compatibility shim that emulates unimplemented instructions using traps for software that hadn't yet been rewritten to understand the above signal.
A "chance"? Maybe, but would there be anything to gain from such uniformity? Big CPUs are made by big teams, just like software. And you try to maximize re-use of vetted recipes, i.e. no need to reinvent power management. I would assume that for specialty backstage processors the core that the specialist team already knows is the one that gets used. Even if the backstage is disclosed, no code will ever be shared between the main cores and the support cores.
reply