4 ms·
If it takes 90s to test 2^32 floats then it should only take about 12,257 years to test 2^64 doubles.
by zomgbbq 13y ago
If it takes 90s to test 2^32 floats then it should only take about 12,257 years to test 2^64 doubles.
- Someone 13y agoIt's perfectly parallelizable. Go to AWS, fire up 2^20 four core instances for a day, and you are all set :-)
- kordless 13y agoAssuming you could do it, would it be worth it to do it?
- croddin 13y agoThat would only cost 7.5 million dollars using c3.xlarge instances! I am actually surprised that it is that close to being feasible.
- _delirium 13y agoAre there any estimates on how much on-demand capacity Amazon typically has? If I tried to spin up instances as fast as the API will let me, how long until I run out of quickly provisioned instances? Can I get thousands on short notice? Tens of thousands? Millions?
- deleted 13y ago[deleted]
- techdragon 13y agoYou would need to ask them very nicely ahead of time for permission to spin up that many instances. The default limits are rather a lot lower than that. 20 instances per global region. Going to need a fair few more than that.
- kazagistar 13y agoIsn't distributing hardware tests missing the point?
- zvrba 13y agoActually, 2^53 different mantissas, plus a few different exponents, depending on the function under test. Also, there's a huge number of NaNs, all of which are equivalent. For ceil/floor, it wouldn't make sense to test exponents larger than 54.
- brucedawson 13y agoThere are a huge number of double-precision NaNs in the absolute sense -- there are 2^54-2 of them. But they are a small portion of all of the doubles (roughly 1/2048) so omitting them from the tests does not help significantly with saving time. And, skipping testing of large numbers and NaNs can lead to missing bugs. One of the fixed ceil functions handled everything except NaNs correctly. Implementations that failed on exponents beyond 63 or 64 are easy to imagine. But, testing doubles requires compromises. Testing of special values plus random testing plus exhaustive testing of the smallest ten trillion or so numbers should be sufficient -- better than the current status quo at least.
- qwerta 13y agoYou could test corner cases very quickly. Just define important bites, and run permutation on those.
- wglb 13y agoAh, but with floating point that can really be quite tricky.
- VLM 13y agoAn opposition to "test everything" is to play telecom signal to noise ratio type games. And error rates. So attempting a 1 part in 2 ^ 64 implies your memory access error rates and disk error rates are already far under 1 in 2 ^ 64 which is quite expensive. There are of course solutions to those problems, but they may be more expensive and complicated than you want. With non-ECC memory and a simplistic brute force algo it doesn't make much sense to talk about doing 2^64 tests because any errors will swamp the memory errors that will be detected. Depending on who's numbers you select (1e-10? 1e-15?) to get the predetermined result you want (LOL) At 1 in 2 ^ 32 range its commodity desktop hardware time. To pull off 1 in 2 ^ 64 hardware error rates is way harder.