lte678

It should be fine for normal use cases when used with error correcting codes without any active scrubbing.

According error rates for ECC RAM (which should be at least by an order of magnitude comparable) of 1 bit error per gigabyte of RAM per 1.8 hours^1^, we would assume ~5000 errors in a year. The average likelyhood of hitting an already affected byte is approx. (5000/2)/1e9=2e-6. So that probability * 5000 errors is about a 1.2 percent chance that two errors occur in one byte after a year. It grows exponentially once you start going a past a year. But in total, I would say that standard error correcting codes should be sufficient to catch all errors, even if in hibernation for a whole year.

[1] https://en.wikipedia.org/wiki/ECC_memory

TMR (so the tripilicate method) wouldn't be super suitable for this kind of application since it is a bit overkill in terms of redundancy. Just from an information theory perspective, you should only have enough parity suitable for the amount of corruption you are expecting (in this case, not a lot, maybe a handful of bits after a year or two). TMR is optimal for when you are expecting the whole result to be wrong or right, not just corrupted. ECC and periodic scrubbing should be suitable for this. That is what is done by space-grade processors and RAM.

The gold around satellites are actually very thin layers of mylar, aluminum foil and kapton (a type of golden, transparent plastic) which are used to keep heat inside the satellite inside, and heat outside, outside (See Multi-Layer Insulation). Radiation shielding usually comes from the aluminum structural elements of the spacecraft, or is close to the electronics so you do not waste too much mass on shielding material. Basically, shielding efficacy is most determined by its thickness, so it quickly becomes quite heavy.

Indeed, because those two things were only exemplary, meaning they would be indicative of your system having a bottleneck in almost all types workloads. Supported by the generally higher perforance in 64-bit mode.

Clearly you can address more bytes than your data bus width. But then why all the "hacks" on 32-bit architectures? Like the 36-bit address bus via memory mapping on SPARCv8 instead of using paired index registers ( or ARMv7 width LPAE). From a perfomance perspective using an address width that is not the native register width/ internal data bus width is an issue. For a significant subset of operations multiple instructions are required instead of one.

Also is your comment about turing completeness to be taken seriously? We are talking about performance and practicality. Go ahead and crunch on some 64-bit floats using purely 8-bit arithmetic operations (or even using vector registers). Of course you can, but the point is that a suitable word size is more effective for certain computational tasks. For operations that are done frequently, they should ideally be done at native data-bus width. Vectored operations will also cost performance.

I am unsure about the historical reasons for moving from 32-bit to 64-bit, but wouldnt the address space be a significantly larger factor? Like you said, CPUs have had vectoring instructions for a long time, and we wouldn't move to 128-bit architectures just to be able to compute with numbers of those size. Memory bandwidth is, also as you say, limited by the bus widths and not the processor architecture. IMO, the most important reason that we transitioned to 64-bit is primarily for the larger address address space without having to use stupidly complex memory mapping schemes. There are also some types of numbers like timestamps and counters that profit from 64-bit, but even here I am not sure if the conplex architecture would yield a net slowdown or speedup.

To answer the original question: 128 bits would have no helpful benefit for the address space (already massive) and probably just slow everyday calculations down.

Huh. Apparently we justed needed to start a new platform to start dropping the real life pro tips. Seriously, where have you guys been keeping these??!?