3 ms·
As soon as you are putting a noisy dataset through multiple iterative algos, though, if a bit error hits the control flow code or data structure delimiters, you
by vegabook 10y ago
As soon as you are putting a noisy dataset through multiple iterative algos, though, if a bit error hits the control flow code or data structure delimiters, you face the possibility of massive silent, propogating corruption. Imagine your hash table getting a bit error in it (all R lists and Python dicts use them), or an incorrect branch in your code. Admittedly the risk is ultra low, but you have enough problems to worry about to have, in addition, a niggling sensation of RAM-risk as you work.
More generally, it's not unreasonable to say that our entire computing paradigm rests on accurate RAM. Above 16GB, the risks just become too big for anybody doing serious work, and not just messing around with prototypes.
- semi-extrinsic 10y ago> Admittedly the risk is ultra low Exactly this. The size of your code is positively infinitesimal compared to your data. And unless you're writing your code and then running it exactly once, which is a) even more unlikely and b) bad practice, you'll catch any of those bit-flip errors in your code or data structures. This has been discussed a lot in the literature, especially for GPUs where ECC carries a performance penalty both on speed and available memory, e.g. in this paper where they've tested it on a GPU cluster: http://www.rosswalker.co.uk/papers/2014_03_ECC_AMBER_Paper_10.1002_cpe.3232.pdf http://www.rosswalker.co.uk/papers/2014_03_ECC_AMBER_Paper_1...