Re: fixed point vs floating point

[dewar@merv.cs.nyu.edu (Robert Dewar)]

tmoran says

<<  So the current crop of systems has fast fpt, slow integer */, and
slow memory.  A few years ago that was not the case.  Things like
MMX instructions start to move back toward fast integer arithmetic.
What's fast this year is not the same as what's fast next year.
As Mathew Heaney pointed out earlier, it would be wise to design
data types, etc, to match the problem, and then, if speed is
an issue, change things to optimize for the particular current target.
>>

That's true only if you think a few means 5-10 years. This pattern
is fairly old by now, you have to go back a long way (really to the
early 80's to find fast memory -- i.e. main memory comparably fast
to the processors). When I bought my first PC1 in 1981, the memory
was 250ns, and the processor was 4.77MHz (= approx 210 ns), a reasonable
match (remember the visibility of "wait states" in those days?) Now a
decent PC has a 266MHz processor (60 times faster clock, and of course
really the factor is higher), yet memory is only 5-6 times faster.

By all means one should choose floating-point or fixed-point in reponse
to the problem these days. But remember in this thread that a number of
people were in the mindset that one of the possible reasons for choosing
fixed-point was greater speed, and it seems that quite a few people were
unaware that with modern processors this reason, to the extent it is
valid at all, points in the other direction (of course specialized
processors, e.g. those with no fpt, may point in the opposite direction).

However, it is not simply a matter of optimization to flip between
fixed- and floating-point formats, they have radically different
semantics, and you choose the one that matches your semantic requirement.
Matthew's point that because the definition of angle nicely fits the
fixed-point declaration, that is what should be used, is fundamentally
flawed. The decision on whether to represent an angle as fixed-point
or floating-point depends on the operations to be performed on the
quantity and not much else!

By the way, Tom, you keep mentioning MMX (one might almost think you were
an Intel salesperson), but I see MMX has having zero impact on general
purpose computing and general purpose compilation. It is intended for
very specialized hand-written code, and it seems very unlikely that it
is good for anything else.

(I partly base this estimate on the experience with the i860. Remember that
these kinds of instructions are not new, they were on the i860 7 years ago,
but in practice were not useful for general purpose computing).