Re: Apple and the Holy War

[pausch@saafNOSPAM.se (Paul Schlyter)]

In article <20000503205738.14509.00001458@ng-ck1.aol.com>,
Supertimer <supertimer@aol.com> wrote:
 
> 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.
 
There were etensive floating-point computations before Quake!
Why do you think e.g. the ENIAC (the very first electronic
computer) was built?  That's right -- to perform floating-point
operations, so people wouldn't have to do it by hand....  The
ENIAC was slower than a good picket calculator today btw, but it
still made economical sense to dedicate a whole room plus a staff
of technicians, because otherwise you would have to hire,
and pay salary to, (human) computers to do the computations.
 
Some 100 years ago, the word "computer" was in the English language,
but it did mean something else than today: back then, a "computer"
was a person hired to do computations all day long, usually by hand,
later with a desk calculator as an aid.
 
> Most people did word processing, painting, spreadsheets,
> databases, and terminal emulation back then.
 
That was later -- in the really early days of computers,
most people involved with computers did computations.  Only
later did computers get cheap enough to make it feasible to
toy around with them too.
 
> In my opinion, in those days, integer performance was far
> more important.
 
You're of course entitled to your opinion....
 
BTW did you ever benchmark an RSA computation on the Apple II ?
(is there even such software for the II ?)  Yes, RSA is done
by integer modular arithmetic, using very long integers.
 
Aaah, I see ... you mean only short integers, no longer than
16 bits -- right?
 
>>> 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.
 
This says something about your friends.... :-)
 
> They were extremely expensive options back then.
 
They weren't cheap, sure, but they weren't "extremely" expensive
either!  You could have one for perhaps 10-15% of the cost of the
entire computer -- that's not much if FP performance is essential to
you.  And if FP performance is so unessential to you that you never
would pay extra for an FPU, then you might as well keep your old
8-bit computer.  For non-FPU related tasks, my first 4.77 MHz 8088 PC
was outperformed by my old 6 MHz CP/M machine: the CP/M machine had
both a faster CPU and bigger floppy disks (640K on the CP/M machine
vs 360K on the PC; at that time I had no harddisk on my PC).  The
PC then had only one advantage: meomory space (640K RAM on the PC
vs 64K on the CP/M machine), which sometimes mattered.
 
> Buying the chip was as expensive on the PC as buying an FPU card
> for the IIGS.
 
Can you quote some prices?
 
BTW when I got my first PC, in 1986, I had dreamt about the 8087
for several years, but I had not yet heard about 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.
 
If so, you can hardly ever compare computers to one another, because
they're always different.  Should you compare a computer with a HD
to one without a HD?  Or one with color graphics to one without
color graphics?  Et cetera et cetera....
 
Also: when you talk about the Apple II, you're always considering the
IIgs, while I'm always thinking about the II+ since that's what I had.
Getting a new IIgs was quite expensive.  Getting a new original IBM PC
was of course equally expensive, so I never got one until the
considerably cheaper clones did appear.
 
I would prefer the following terminology:
 
Apple II:   the "classic" Apple II line:  the II, II+, IIe, IIc
 
Apple IIgs: the Apple IIgs, which really was a different computer,
albeit with backwards compatibility to the classical Apple II's,
much like today's Pentiums have backwards compatibility to the
good ol' XT...
 
Could we agree on that?  If you mean the IIgs, please say so.
 
>>> 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.
 
The Direct3D is a much more recent invention.....
 
Today the CPU performance of personal computers are so vastly larger
than you can afford some inefficiencies.  Like SANE, or Direct3D, or
Java.  Java is btw an interesting phenomenon: basically it's a
revival of the old UCSD Pascal concept of portable object code for a
pseudo-machine which is interpreted on each actual machine.  Back in
the days of the Apple II and the Lisa, interpreting pseudo-code made
the programs considerably slower (that's why the Apple II+ with
Applesoft outperformed the Lisa with Lisa Pascal, for instance: the
interpretation overhead in Lisa Pascal was too big).  Nowadays
interpreting pseudo-code can still be reasonably fast, because
there are so many clock cycles available in today's processors.
So ther we are: there is at least ONE good use for those 1 GHz
CPU's of today....
 
Anyway, Direct3D is a compromise.  If you really want the best
performance out of your graphics card, you should of course avoid
Direct3D and instead use a driver specific to your graphics card.
 
>> 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.
 
But here you're again talking about the IIgs rather than the II .....
 
There were FPU cards for the II too -- but those I was only did
single-precision floating-point arithmetic.
 
-- 
----------------------------------------------------------------
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