[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple and the Holy War
I'll let Paul et al look at the quotes below if they wish; my point is
that below Paul admits that the program that he was citing was a VERY
special case.
The fact is that in using what most people use a micro computer for
(productivity that is), an Apple //e is as good as a 1 ghz Wintel.
Consider this posting which I am doing on my 100 mhz pentium. I could
log onto my shell account with my //c or //e, and read an post there as
well, and as fast (except for my DSL) as I am doing with this out of
date Wintel.
Word processing??? When writing a paper for grad school, or a letter, or
a report for presbytery, my Kaypro 2X with it's letter quality printer
does a better looking job, though the printer is slower, than my laser
printers driven by my Wintel or my 040 Mac. Or I could use WordPerfect
on my //e, or my GS version on my GS and my ImageWriter LQ or WP on my
Kaypro 16 and my Epson 24 pin dmprinter and have great looking stuff
without all the overhead of a GUI.
The only reason I turned to a GUI, and Wintel for that matter, is I had
some special needs that only a GUI could do, and the only software at
that time I could get was on Windows, not the Mac. Otherwise, I was VERY
happy with my WordPerfect for DOS office suite, and I do miss the solid,
sane software that I used to use everyday.
Roy
Paul Schlyter wrote:
>
> 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