Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320
From: jb10320@uxa.cso.uiuc.edu (Desdinova)
Newsgroups: comp.sys.apple2
Subject: Re: End this nonsense comparison
Message-ID: <1991Jan5.102818.7986@ux1.cso.uiuc.edu>
Date: 5 Jan 91 10:28:18 GMT
References: <1991Jan5.014646.26135@ux1.cso.uiuc.edu> <10904@ucrmath.ucr.edu>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 110

In article <10904@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes:
>>> Apple II GS 7Mhz 650 Dhrystones
>>> 386 33Mhz 10000 Dhrystones
>
>Did you write all this in "C"?  Even I would expect a 7Mhz '816
>to run a little faster than ~1/18th the speed of a 33 Mhz 386.
>If this is in "C", I'm sure the STRCMP and STRCPY functions were
>carefully crafted in assembly to optimize Dhrystone ratings, vs.
>ORCA/C where those routines were probably written in "C".
>If this is a legitimate measurement, I would suspect that ORCA/C
>is even worse than I thought it was or your code is blowing the
>cache on your transwarp and the '816 is running slower than 7 Mhz
>as a result.

   Really? Wow. Okay, I'll check out the source, optimize STRCMP and STRCPY
(after looking at the library, of course), and re-run it.  If they can
play games so can I. The 10000 number was quoted to me by a '386-owner
I know. 
   I didn't think about Orca being THAT bad (the test was with optimization
on, whoopdedoo), but perhaps so.  I'll experiment and see what I can come
up with.
    
>I would like to see some reasonable benchmarks around here comparing
>a 1Mhz 6502 against a 4.77 Mhz 8088.  Alas, I wouldn't even know if
>I could locate a 4.77 Mhz machine myself these days.  Maybe there is
>one hidden around at UCR I could find.  Only some real, substantial
>benchmarks will shut everyone up on these subject (or, at least, it
>will refocus the argument on the quality of the benchmark!).
>
>>> 2*2 on the 386 about 20-30 times faster...
>Not if you use ASL vs. SHL!  Perhaps you should pick a better pair of
[..]

  That was a bad example.  I meant to signify the concept of multiplication,
for which the '386 has microcode and the '816 has "Integer Math Toolset".
Integer Math is a sloth.  The bottleneck is in there and the C library routines.
Our Dhrystone tests came as a result of our desire to have a way to base
comparisons of various souped-up IIgs's.

>>> Give me a 25Mhz '816 over a 33 Mhz '386 any day.
>Assuming zero wait states, I'd go along with this.  Question is, will we
>ever really see such a beast?  Better yet, give me a 65c832 or even a
>65032 at 20-25Mhz.  Alas, by the time such a chip exists, Intel will
>probably have given us 100 Mhz 586 or 686 chips.  Of course, the big
>problem with all of these fast chips is "where are we going to get the
>high speed memory to go along with them?"

  Intel marketing has for a couple years now promised things they can't
deliver (or deliver quite late).  I suspect that 100MHz is a pipe dream
and that there's really no sound engineering reason to strain the already
creaking design of the 'x86 series further.  Perhaps more support hardware
on-chip, but not a lot more.

>>> designed to be programmed in assembly.
>Yes and no.  Certainly the '816 has a poor architecture for supporing HLLs
>and the original intent of the chip was for video games and controller
>applications.  I don't think the designer (Bill Mensch), however, went
>out of his way to make it easy to write assembly code for the '816.
>Those M & X bits are a big source of trouble in complex programs.

  True, but then I avoid them completely and use the macros SHORT and LONG.
And I also avoid using them by doing such things as
   Bad				 Good
 --------			------
 short m			lda location
 lda location			and #$ff
 long m	

And sticking in 16-bit mode.  Takes less time, actually, to do it WITHOUT
switching in 8-bit mode.  For doing I/O stuff, sure it can be a pain,
but then GS/OS and the tools are provided so you don't have to fuss with
it.
It's funny you should mention video games as a target market- the new
16-bit Nintendo machine will use the '816. Ain't that nice? It'd be
cool to run GS/OS thru my NES.  What apple needs to do is make an NES
compatible IIgs.  They'd sell BILLIONS of the things.

>True.  Alas, Apple II people who are willing to writing in assembly are
>a dying breed.  
  I have to disagree with this.  I program in assembly and I know many
others who do (not exclusively of course- best language for the job),
and I'm beginning to think RISC/HLL 'supported' CPUs are a divergence from
where CS should be going.  

                Long gone are the days that someone would learn assembly
>so they could get rich writing a video game for an Apple II.  It's
>much easier to write in C on a PC, and the market is about 100 times
>larger, so guess what?  They won't bother.  It would be nice if there was
>a really good C for the GS that was reasonably compatible with PC C compilers
>so we could entice some of those people to port their stuff to the GS.

I'd prefer a Unix-compatible C compiler, but that's a personal preference.
And, I really could care less that my GS doesn't have a million bad games
ported to it.  We get some of the best ones, simply because it's a hell
of an effort that doesn't pay back well to program them.
Re: Immortal, Rastan, Arkanoid, etc...

>I would hate to have the GS as my only machine.
>I would also hate not to have a GS at all.

Beautiful.

>*** Randy Hyde


--
Jawaid Bazyar               | Being is Mathematics 
Senior/Computer Engineering | Love is Chemistry
jb10320@uxa.cso.uiuc.edu    | Sex is Physics
   Apple II Forever!        | Babies are engineering