11–20 of 34 posts
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.”
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)
What needs to happen is to bring ECC to all levels of a chips logic to solve this. ARM vs RISC-V vs x64 doesn't address the problem as nothing in them inherently solves the problem. Making adders that add with ECC will. If all of the logic also operates on ECC with the data, chip yields will also be improved. Say an core of the chip only produces the correct result 99% of the time, currently you have to disable that…
What needs to happen is to bring ECC to all levels of a chips logic to solve this. ARM vs RISC-V vs x64 doesn't address the problem as nothing in them inherently solves the problem. Making adders that add with ECC will. If all of the logic also operates on ECC with the data, chip yields will also be improved. Say an core of the chip only produces the correct result 99% of the time, currently you have to disable that…
What leads us to believe that there is not already fault detection in execution units? We have really no idea what's going on at the gate level in CPUs.
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.
What needs to happen is to bring ECC to all levels of a chips logic to solve this. ARM vs RISC-V vs x64 doesn't address the problem as nothing in them inherently solves the problem. Making adders that add with ECC will. If all of the logic also operates on ECC with the data, chip yields will also be improved. Say an core of the chip only produces the correct result 99% of the time, currently you have to disable that…
What needs to happen is to bring ECC to all levels of a chips logic to solve this. ARM vs RISC-V vs x64 doesn't address the problem as nothing in them inherently solves the problem. Making adders that add with ECC will. If all of the logic also operates on ECC with the data, chip yields will also be improved. Say an core of the chip only produces the correct result 99% of the time, currently you have to disable that…
A, B ⇒ C
Aa, Bb ⇒ Cc
So, how do you compute the ECC bits from only the Aa and Bb bits without having to compute the C part?
Depending on the ECC logic chosen, that might be doable for bit shifts, but for addition? For multiplication? For IEEE float square roots?
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.
Maybe, but in most situations you're probably better off adding some more developer time to work on software bugs than you are doubling your computation cost.
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.