In article <bhy*JGXQq@news.chiark.greenend.org.uk>,
timc@chiark.greenend.org.uk says...
In article <11am8lu3aj5i71a@corp.supernews.com>,
G.T. <getnews1@dslextreme.com> wrote:
Absolutely. Integer performance is all that matters for the vast
majority of desktop consumer applications (games might be an exception,
these days).
Aren't sound and video exceptions, too?
Not as I understand it; 2D image processing and video (and sound) are
integer operations. In the case of e.g. TIFF, you use integer values to
represent the levels of red, green and blue. It's all integer numeric
data.
....however if you want to manipulate the image somehow, e.g. increasing
the blue intensity by a specific percentage, it's much easier if you have
floating-point operations available.
The same's true of digital sound; you use integer values to
represent the intensity.
The Altivec, heavily used for image processing, is an integer vector
unit.
And even in floating point applications, doing an approximation using
integer maths is often good enough, by and large, and considerably
faster.
....on hardware without any floating-point processor, that is. On PC's
that means up to the 386, where the floating-point processor was an optional
extra, and absent from most systems.
Any of you who have used 'Fractint' on a PC will have seen that
in action; generating these fractals is in theory a pure floating point
problem, but those guys developed a blisteringly fast integer
approximation which works well at low magnifications.
Fractint was written when most PC's had a 386 CPU. True, you could add an
optnional 387 floating-point unit if you wanted, but most people didn't.
Starting with the 486 the floating-point unit was built in.
And on today's PC's, writing FractInt would be pointless, since a FractFloat
would most likely be faster....