[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple and the Holy War
- Subject: Re: Apple and the Holy War
- From: supertimer@aol.com (Supertimer)
- Date: 2000/05/04
- Newsgroups: comp.sys.apple2
- Organization: AOL http://www.aol.com
- References: <8eok8n$4s7$1@merope.saaf.se>
pausch@saafNOSPAM.se (Paul Schlyter) wrote:
>> I did a series of tests in the past decompressing zip files,
>> jpg files, and running GUIs on a 640x200 resolution screen.
>> The IIGS crushed the 4.77Mhz 8086 XT and the 10Mhz
>> Turbo XT too. It ran the GUI faster than an 8Mhz AT and
>> unzipping files and converting JPGs were about the same
>> (and way faster than on the Turbo XT).
>
>None of these are floating-point intensive programs though.
True. But back in those days, few programs actually made
extensive use of floating point operations. This was before
the days of Quake. Way before.
Most people did word processing, painting, spreadsheets,
databases, and terminal emulation back then.
In my opinion, in those days, integer performance was far
more important.
>> In my tests, the XT and AT were not equipped with math
>> coprocessor chips. They were not standard equipment
>> back in those days.
>
>They were standard options though: all PC's were equipped with a
>socket for the 80x87. If you wanted it, all you had to do was to buy
>the chip and plug it in to that empty socket.
True, but none of the PC owning friends I knew back then
had the FPU chip. They were extremely expensive options
back then. Buying the chip was as expensive on the PC
as buying an FPU card for the IIGS.
>> If you want to throw in the math coprocessor chips, then the IIGS
>> would need an FPU card (such as the Number Cruncher)
>
>As I said above: on the PC you didn't need any "FPU card", you
>just had to plug in the FPU on that FPU socket which was available
>on all PC motherboards.
This is correct, but as I said before, it was expensive.
But the main point was that you have to compare non-FPU
equipment with non-FPU equipment and FPU equipment
with FPU equipment. Otherwise, it would be like putting
a turbocharger in one model car and comparing it to
another model without turbocharger.
>> which patches into the SANE toolset,
>
>Aaahhh --- SANE! I always though SANE was quite insane - why?
>Because it added the overhead of function calls to f.p. computations.
True, but it lets all programs benefit from system
enhancements. The PC world does this too. Microsoft's
Direct3D has overhead too, but it allows many different
graphics cards to interface with software. But video cards
that have the option of software that directly support them
will run faster with that software because there is no
overhead. But Direct3D is not insane, now, is it? Of
course not.
>If you want maximum performance form your FPU, you should of course
>use a compiler which generates FPU instructions inline. In that way
>you'll avoid the overhead of library function calls, and will be able
>to boost the performance by a factor of perhaps 2 to 3. "But what if
>the FPU is missing?", I hear you ask. On the PC this would generate
>a trap, which was handled by an FPU emulation library which mimiced
>the FPU in software.
Orca C can generate FPU instructions inline. Thus,
programs written specifically with the option of supporting
an FPU card on the IIGS will run faster. Examples
include the math programs like GS Symbolix and
GS Numerics.