[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How many times must Apple make such DRASTIC architecture changes?
- Subject: Re: How many times must Apple make such DRASTIC architecture changes?
- From: Paul Schlyter <pausch@NOSPAMsaaf.se>
- Date: Mon, 13 Jun 2005 00:27:22 +0200
- Newsgroups: comp.sys.apple2, comp.sys.mac.system, comp.sys.mac.apps
- References: <1OIpe.17401$QX1.14703@fe06.lga> <1gxykbw.1h7o2pe1jygz5cN%neillmassello@earthlink.net> <dtz*kBQQq@news.chiark.greenend.org.uk> <11am8lu3aj5i71a@corp.supernews.com> <bhy*JGXQq@news.chiark.greenend.org.uk>
- User-agent: MicroPlanet-Gravity/2.70.2067
- Xref: g2news1.google.com comp.sys.apple2:11966 comp.sys.mac.system:49406 comp.sys.mac.apps:24743
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....
>Tim
--
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se
WWW: http://stjarnhimlen.se/