From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,183ebe04e93f0506 X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: fixed point vs floating point Date: 1997/11/22 Message-ID: <34776A06.5855@flash.net>#1/1 X-Deja-AN: 291664657 References: <9711221603.AA03295@nile.gnat.com> To: chat@gnat.com Organization: Flashnet Communications, http://www.flash.net Reply-To: Ken.Garlington@computer.org Newsgroups: comp.lang.ada Date: 1997-11-22T00:00:00+00:00 List-Id: Robert Dewar wrote: > > < fixed point is, to us, unreliable. By that I mean the ultimate result > is not what we want. We agree that fixed point is much faster, but > floating point is, almost always, plenty fast enough.>> > > *very odd* > > First, please do some experiments, all of those who believe that fixed-point > is faster than floating-point. Especially if you include some multiplications, > and especially if you are using precisions greater than 32 bits on a 32-bit > machine, you are going to be MIGHTY surprised, I would even say schocked > by what you see. Fixed point arithmetic other than very simple adition > and subtraction of identical types (which is the same speed as fpt on > typical machines) is drastically slower than floating-point. If you don't > believe me, try it out and see! This is probably true if you include your earlier qualifier - on "modern" architectures. On MIL-STD-1750s, however, most implementations have far more clock cycles required for floating-point multiplies and divides than for integer shifts -- on the order of 30-50 cycles for the floats vs. 5-8 for the shifts. There is also a penalty if you're dealing with slow memory, and having to fetch the 32-bit float vs. the 16-bit integer. So, IF... - you can live with the precision of 16 bits, AND - you use power-of-two deltas, AND - you have an Ada compiler that optimizes well for fixed-point you could get better performance for fixed-point. I was on a project where one team used fixed-point extensively, and another used mostly floating-point. The fixed-point and floating-point appeared to be about the same performance-wise, mostly because the Ada 83 compiler used did not do a lot of fixed-point optimization. > Second, fixed-point is FAR more reliable in practice, because as Bob > Eachus notes, the error analysis is far simpler. Mars seems to say that > fixed-point is unreliable because off incompetent programmers and > unreliable compilers, but this is a comment on a particular set of > incopmpetent programmers and unrealiable compilers, not on the fundamental > nature of fixed vs floating-point. We did notice incorrect object code for fixed-point generated by our compiler for fixed-point, but I agree that fixed-point is more reliable in the abstract. > In my experience programmers are woefully ignorant about floating-point > (the completely extraordinary thread on CLA), and this leads to a lot of > serious problems in floating-point code. > > Interestingly in high critical systens, the objection to fpt is related > to Mars' concern about reliability. The general perception is that fpt > hardware is too complex to be reliable. Intels' widely publicized > difficulties in this area can only help to confirm this worry! We've never had anyone raise this objection in our systems, although I have yet to use a 1750 CPU that didn't have a bug in its floating point implementation. I guess its due to the "obvious" fact that hardware is more reliable than software :)