Re: Apple and the Holy War

[pausch@saafNOSPAM.se (Paul Schlyter)]

In article <20000502212654.18549.00001044@ng-fo1.aol.com>,
Supertimer <supertimer@aol.com> wrote:
 
> pausch@saafNOSPAM.se (Paul Schlyter) wrote:
> 
>> Performance isn't just user response.  To put things in perspective,
>> I've had a program which originally was written in 1982-83, and which
>> have been ported a few times.  It performs one useful function: it
>> computes rise/set times for the Sun and Moon daily, and the six
>> planets out to Uranus once a week, for one full calendar year at any
>> place of your choice.  I first started this project on Apple DOS
>> + Applesoft, but never finished it there: the first running verison
>> ran on CP/M.  Since htere never was any Applesoft verison of this
>> probram, I can only guess the run time under Applesoft:
>> 
>>   4-5 hours    1 MHz 6502, Apple II+, Apple DOS, Applesoft Basic  (a guess)
>>   1.5 hours    2 MHz Z80, Apple II CP/M, Fortran-80
>>    30 minutes  6 MHz Z80, Apple II CP/M, Fortran-80
>>    10 minutes  4.77 MHz 8088+8087, C
>>   1.5 minutes  16 MHz 80386+80387, C
>>    12 seconds  66 MHz 486DX, C
>>     3 seconds  90 MHz Pentium, C
>>     1 second   300 MHz Pentium-II, C
>> 
>> After this, please try to convince me that the Apple II+ is more
>> powerful than a PC....  <g>
> 
> This is a bad comparison because Applesoft is an interpreted
> language.
 
This won't make such a large difference in this case.  These are
floating-point intensive calculations, and even under a compiled
language the floating point must still be done in software.
A floating-point intensive Applesoft program will run perhaps twice
as fast if compiled than if interpreted.
 
> Recompile the program under Orca C on a stock
> 2.8Mhz IIGS and I predict that you will see a time of around
> 15 minutes which should be similar to an 8Mhz to 12Mhz 286
> computer without 8087/80287 math coprocessor chips.
 
If I did that I predict I would see an execution time of this program
of perhaps 8 hours on the Apple II, and perhaps 3 hours on that IIGS.
 
Why?
 
Because these were floating-point intensive programs, which did a lot
of trigs too.  And typically a C compiler only does floating-point
computations in double precision.  When implemented in software,
double precision arithmetic is some 4-5 times slower than
single-precision arithmetic.  Trigonometric functions in double
precision are some 10 times slower than in single precision, if
the f.p. arithmetic is done in software.
 
I checked some C compilers for CP/M, but I quickly discarded them for
this project, because they lacked single-precision floating-point
arithmetic (yes, C has single-precision f.p. variables, but when
doing arithmetic on them, the values were always converted to double
precision, and then converted back to single precision after the
computation).  If I had done all calculations in double precision,
the run time of the execution time of program would probably have
been some 8 hours on the 2 MHz Z80, and 2.5 - 3 hours on the 6 MHz
Z80.  By choosing Fortran-80 instead, which did implement not only
single precision VARIABLES but also single precision ARITHMETIC, and
by doing as much as I could in single precision, I was able to
drastically reduce the execution time of this program.
 
On the PC (with an 80x87 FPU) this issue became moot, since the FPU
performed double precision arithmetic as quickly a single precision
arithmetic -- and much faster than software floating-point arithmetic.
 
 
 
> 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.
 
> 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.
 
> 
> The CP/M stuff is misleading too because the Z80 was
> slower at a given clock speed than the 65C02.
 
Yes: the Z80 required a minimum of 4 clock cycles for a machine
instruction, while the 6502 did many machine instructions in only 2
cycles.  On the other hand, the Z80 had a 16-bit add/subtract
instruction and a block move instruction -- this had to be done
with subroutines on the 6502.  The Z80 also had more CPU registers,
while the 6502 had to access "page zero" all the time.
 
> A 1Mhz 65C02 should be able to match a 4Mhz Z80 quite well
> if not best it.
 
You're over-optimistoc about the 6502 here.  I did some benchmarks
on this long ago, and found that the 1 MHz 6502 was a little faster
(by perhaps 10-30%) than the 2 MHz Z80.
 
> 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.
 
> 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.
 
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.
 
> thereby speeding up standard programs including ones generated
> in Orca C.  These cards used Motorolla FPU chips, so
> I predict if your program uses floating point calculations
> that the IIGS' advantage would grow in relation to the
> '287 FPU the AT would be using.
 
The 80287 was actually the worst of all Intel FPU's: it wasn't really
faster than the 8087, but it had to handle protected mode as well.
As a result, the 80287 in the AT ran *slower* (only at some 3 MHz,
even though the 80286 ran at 6 or 8 MHz) than the 8087 FPU in the XT
(at 4.77 MHz).  When the 80386 was introduced, thre was at first no
80387, so early 80386 PC's included an option to run the 80287 FPU,
which yileded the same miserable FPU performance as on the AT.  But
when the 80387 was introduced, there was a strong boost in FPU
performance.  The rest is history...
 
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch