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,f03830a80d247012
X-Google-Attributes: gid103376,public
From: tmoran@bix.com
Subject: Re: fixed point vs floating point
Date: 1997/11/28
Message-ID: <65nafm$u8@lotho.delphi.com>#1/1
X-Deja-AN: 293479076
Organization: Delphi Internet Services <http://www.delphi.com/>
Newsgroups: comp.lang.ada
Date: 1997-11-28T00:00:00+00:00
List-Id: <comp.lang.ada>


In <dewar.880661467@merv> Robert Dewar said:
>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.

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

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