(333.75 * b6) + (a2 * firstexpr) + (5.5 * b8) + (a / (2.0 * b)) Īh the joy of the so called Reals as digitally approximated by IEEE754 or similar, next stop full on numerical analysis! I don’t have an M1 Mac to test on.ĬhaoticBank. Both Macs reported identical results which are far closer to expected. I wrote a bash script which calls bc (listed below). (2018) Handbook of Floating-Point Arithmetic, 2nd ed, Birkhäuser, ISBN 978 5 9.ġ) Mac Pro 2009 flashed to 5,1 with dual Xeon X5690s.Ģ) MacBook Air 13″ Mid-2013 with i7-4650U. These imply that results from floating-point arithmetic on the two processors should be almost (if not completely) identical, even when they don’t match the results of exact calculation. On each of these three unusual test cases, the erroneous results returned by the M1 using double precision arithmetic are identical to those returned by current Intel processors, specifically a 3.2 GHz 8-Core Intel Xeon W. On a modern Intel processor using Doubles, this returns -1.1805916207174113e+21, and that’s exactly the same when run on an M1. On Rump’s IBM S/370, this returned 1.172603… in single, double and extended precision, although the exact result is -0.827396…. The numbers have been carefully chosen here to be exactly representable in binary floating-point arithmetic with a precision of more than 17 bits. Rump designed a function in 1988 which has continued to return incorrect results since he first ran it on an IBM S/370 computer. On Intel processors, the final value of account is 1201807247.4104486, and again that’s exactly the same when run on an M1. However, if the initial estimate of (e – 1) is slightly below the actual value, the result tend to minus infinity if that initial estimate is slightly above actual, the result tends to positive infinity. Var account: Double = 1.71828182845904523536028747135Įxact arithmetic shows that the amount in the account tends to 0. double at the end of the first year, triple at the end of the second, until it’s multiplied by 25 in the 25th and final year. This is phrased in a story in which a man goes to a bank, which promises him that, if he deposits exactly $(e – 1) in an account, they will deduct $1 each year as their fee, and multiply the remaining balance by the age of the account in years plus one, i.e. On Intel processors, when max = 21, the final value of v is 99.8985692661829, and that’s exactly the same when run on an M1. On otherwise accurate processors, rounding errors occur even in early iterations, and the sequence converges on 100. The value of v should, using exact arithmetic, converge on 6 as the number of iterations (max) tends towards infinity. This calculates a sequence which seems to converge to an incorrect limit, when compared against exact calculations. This may seem perverse, but looking through a vast number of correctly-performed calculations tells you far less. I have chosen three from the Handbook of Floating-Point Arithmetic (see reference), in which current Intel processors don’t return the result obtained by exact calculation. One good way of testing the ARM CPU’s floating-point accuracy against that of Intel processors is to look at some well-known calculations which are generally performed incorrectly, yielding results which vary in their errors. For a long time now, they’ve been replaced by floating-point numbers, so every calculation for the display relies on floating-point arithmetic. Way back in the days of crude colour displays, screen graphics were computed using integers, after all that’s what a display pixel was. But it’s very important, as so much in macOS relies on the processor’s floating-point instructions working perfectly. If speed benchmarks seem a bit geeky, floating-point arithmetic might appear as dull as ditchwater. This article asks the other essential question: how accurate are they? Specifically, how does ARM floating-point arithmetic compare with that on Intel processors? In the last five months, we’ve read endless benchmarks run on M1 Macs, and a great deal about their speed.
0 Comments
Leave a Reply. |