fixed point vs floating point 
Author Message
 fixed point vs floating point

Quote:
>Indeed with the modern progression of ever increasing values for the
>ratio (processor-speed / main-memory-speed), table lookup can often
>be quite unattractive. On a really fast processor a second level cache
>miss is enough time to compute LOTS of floating-point stuff.

  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.


Mon, 15 May 2000 03:00:00 GMT  
 fixed point vs floating point

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



Mon, 15 May 2000 03:00:00 GMT  
 fixed point vs floating point


Quote:
>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.

Comparing main memory speed and ignoring cache is hardly reasonable.

Quote:
>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!

  I agree with the point I understood him to be making, that the
program should be designed with an application oriented, not a machine
oriented, view.  It sounds like you are agreeing that matching the
semantics of the type to the application is what's important, and
optimization decisions should be made after it's been determined that
there is an excessive cost in using the code the compiler at hand
generates for the type in use, on the target machine, as compared to
switching to another, less natural, type.  Or in the case at hand:
does the part of his app that multiplies or divides angles have such a
performance impact that it should force the decision on their
representation?

Quote:
>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

  Perhaps MMX is strictly Intel hype (no, I'd not an Intel employee or
salesperson), but the general issue remains.  MMX is a way to speed up
certain repetitive operations using SIMD parallelism.  But the
opportunity for such parallelism must be recognized, either by the
programmer, who codes in asm or calls an asm library routine, or by the
compiler/optimizer.  It's easy for a programmer to recognize that his
signal filtering loop can be done faster with a library procedure that
uses MMX, but what about something like using PMADD to calculate an
index into a multi-dimensional array?  It's much more practical if the
compiler can recognize that and generate the MMX code.
  Perhaps today's MMX operations are so restricted, or have so little
benefit, they can be ignored by a compiler.  But SIMD pallelism may
well be used more in hardware in the future, in which case
compilers/optimizers that can make use of it will have an advantage
over those that don't.
  The original reason to mention MMX in this thread, of course, was as
an illustration that, though hardware designers may have been working
in the last few years to optimize fpt performance, they have also
started more recently to remember that some kinds of integer arithmetic
are extremely important in a growing class of programs, and they've
started to optimize integer performance.  The pendulum swings both ways.


Tue, 16 May 2000 03:00:00 GMT  
 fixed point vs floating point

Tom says

<<Perhaps MMX is strictly Intel hype (no, I'd not an Intel employee or
  salesperson), but the general issue remains.  MMX is a way to speed up
  certain repetitive operations using SIMD parallelism.  But the
  opportunity for such parallelism must be recognized, either by the
  programmer, who codes in asm or calls an asm library routine, or by the
  compiler/optimizer.>>

I am beginning to get the idea that you have not actually looked at the MMX
instruction set in detail. I think you should, you would find that it is not
what you think it is!

<<The original reason to mention MMX in this thread, of course, was as
  an illustration that, though hardware designers may have been working
  in the last few years to optimize fpt performance, they have also
  started more recently to remember that some kinds of integer arithmetic
  are extremely important in a growing class of programs, and they've
  started to optimize integer performance.  The pendulum swings both ways.>>

There is nothing at all new about the MMX style of instructions. Such
instructions have been an integral part of graphics processors for a long
long time. Even the appearence of such instructions on a general purpose
microprocessor is not new, the i860 had similar instructions seven years
ago. These instructions are very specifically designed for certain graphics
operations, they are not some kind of general lets-make-things-run-faster
SIMD magic, which is the idea you seem to have. I really think you should
grab a copy of the MMX instruction manual and look at it!

There is no pendulum swinging here, except perhaps in the images generated by
the Intel PR machine and those who react to it without looking at details :-)



Tue, 16 May 2000 03:00:00 GMT  
 fixed point vs floating point

Quote:

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

Quote:
> 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

//   Support you local rescue centre: GET LOST!



Wed, 17 May 2000 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. fixed point vs floating point

2. fixed point vs floating point

3. Floating Point vs Fixed Point

4. code with fixed-point or floating-point

5. fixed point vs floating point (When do you use it ?)

6. floating vs. fixed point

7. An alternative to floating point (was Re: Floating point non-exactness)

8. IBM 370 Floating point to IEEE floating point

9. fixed point vs fixed decimal

10. Bug fix to floating point emulation.

11. Fixed or Floating point for MP3 algorithim?

12. Fixed or floating point?

 

 
Powered by phpBB® Forum Software