Cores that don't count • Hacker News Board

Re: Cores that don't count

#31

Post by etaioinshrdlu » Sun, Jun 27, 2021, 3:56 AM UTC

cmeacham98 wrote: post #24

etaioinshrdlu wrote: post #9

Maybe we should run the code twice on different cpu architecures and only accept the results if they are identical. I’ve heard of high reliability environments doing this, but maybe there are cases for doing it in web/IT as well. This would help catch a large variety of possible errors, including but not limited to cpu bit flips, cpu bugs, memory errors.

In my experience, achieving perfect determinism across two architectures is a problem that cannot be easily hand waved away. For 99% of cases it is fine, but when you run into that last 1% it hurts.

It might be a huge hassle but it might be worth it if high reliability is desired.

Re: Cores that don't count

#32

Post by Someone » Sun, Jun 27, 2021, 4:21 PM UTC

extrapickles wrote: post #29

Someone wrote: post #17

Earlier quoted context omitted.

I’m fairly sure you can’t do that. For example, suppose you have logic that uses some inputs to compute an output: A, B ⇒ C Add ECC bits to the inputs, and you want Aa, Bb ⇒ Cc Now, if you want this to detect errors made by the “⇒” part, you can’t do this as “drop the ECC bits, compute the result, compute the ECC bits of the result”. So, how do you compute the ECC bits from only the Aa and Bb bits without having to c…

You would have to develop a ECC that worked similar to homomorphic encryption, where you can do computations on the chipertext (or in this case, the ECC) without knowing the plain text. For this application, plain text would effectively be the int/float you are doing math on. Since its possible with crypto, I don’t think it’s an insurmountable problem to create an ECC code where Ecc(a+b)=Ecc(a)+Ecc(b) It will likely…

“I don’t think it’s an insurmountable problem to create an ECC code where Ecc(a+b)=Ecc(a)+Ecc(b)”

It wouldn’t, but that ECC wouldn’t work for multiplication instructions, square roots, etc. Dropping floating point and multiplication instructions will correct that, at the cost of significant speed.

I also think any such ECC effectively would be a copy of computing a+b modulo some constant you can pick.

If so, we’re effectively back at “compute the result twice, trap if the two results aren’t identical”

Re: Cores that don't count

#33

Post by IshKebab » Sun, Jun 27, 2021, 8:08 PM UTC

rejectedandsad wrote: post #11

evancox100 wrote: post #4

The conclusion is an utter joke: “Maybe this will lead to abondonment of complex deep-optimizing chipsets like Intel chipsets, and make simpler chipsets, like ARM chipsets, more popular for datacenter deployments.”

Why is that a joke? There's a reason why AWS is pushing Gravitron so hard (and they are pretty damn fast)

Probably because datacentre ARM chipsets aren't significantly simpler than Intel ones. Not in any ways that would reduce this problem anyway!

The article even says this is because of reduced feature size, not chip complexity.

Re: Cores that don't count

#34

Post by sennight » Mon, Jun 28, 2021, 1:37 AM UTC

etaioinshrdlu wrote: post #9

Maybe we should run the code twice on different cpu architecures and only accept the results if they are identical. I’ve heard of high reliability environments doing this, but maybe there are cases for doing it in web/IT as well. This would help catch a large variety of possible errors, including but not limited to cpu bit flips, cpu bugs, memory errors.

Triple modular redundancy - explored on the earliest computers, when these kinds of CPU errors were common (but for other reasons). It isn't commonly implemented today for the same reason that ECC RAM isn't in everything by default - people tend to prefer paying less and just crossing their fingers.

Rad-Tolerant Lockstep Quad Core 8051:

https://www.eetimes.com/rad-tolerant-lockstep-quad-core-8051...

Tolerating rads with cold-war mcu softcores. Glorious.