Re: fixed point vs floating point

["Tarjei T. Jensen" <tarjei@online.no>]

Robert Dewar wrote:
> 
> 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.
> >>
>
> 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).

Whether floating point performs better than fixed point would depend on
the application. If you have an interrupt intensive application that
uses float or fixed point it is conceivable that the processor would
have a hard time getting value from a long floating point pipeline. I
suspect one would get the same problem if there is a lot of floating
point intensive processes (threads) and lots of context switches. I
don't know if fixed point would do better since there might be some
pipelining there as well. Shorter if I remember right, but there.

It's a long time since I studied these things. I'm not up to date with
the latest and greatest processors.

> 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).

The main problem with the i860 as I remember it was that it didn't cope
very well with interrupts. Its long pipelines takes time to fill and an
interrupt can devastate it in almost no time.

The answer to this was to make i860 co-processor boards where the front
processor handled interruptintensive things like I/O.

The instruction set and performance of the i860 made it very popular
with high performance graphics companies. To be honest I only know of
one company using it in their graphics accelerator; SGI.

Greetings,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!