Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!news
From: melling@cs.psu.edu (Michael D Mellinger)
Subject: Re: Blitter vs. 040 (was: Computer Architecture question
In-Reply-To: davewt@NCoast.ORG's message of 15 May 91 12: 59:54 GMT
Message-ID: <lv2H#zg5@cs.psu.edu>
Sender: news@cs.psu.edu (Usenet)
Nntp-Posting-Host: sunws5.sys.cs.psu.edu
Organization: Penn State Computer Science
References: <viaHiuz3@cs.psu.edu> <caw.0521@miroc.Chi.IL.US>
	<?iaHpry4@cs.psu.edu> <1991May15.125954.1993@NCoast.ORG>
Date: Thu, 16 May 1991 01:20:51 GMT
Lines: 68


In article <1991May15.125954.1993@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes:

	   Can you REALLY be this dumb? The point people have been trying to make
   is that if a 68030+blitter is faster than just a 68030, then a 68040+blitter
   will be faster than just a 68040. Of course a 68040 will be able to update
   screens faster than the blitter in many cases, but in doing so it will be
   stealing time that could have been handling OTHER programs, just to update the
   display. Gee, this sounds just like the nExt. No wonder you can't understand
   it. Where will your argument stand with a 3000 with an 040 in it? You are still
   trying to compare a 68030 machine to a 68040 machine, like you were 3 months
   ago.

Well, where are the 040 boards for the Amiga?  NeXT has shipped at
least 8,000 68040 boards, and there isn't even one 040 board for the
Amiga shipping.  -- Just felt like taking a shot.

Yes, an 040 + blitter will be better than just an 040.  I was trying
to get the point acrossed that animation is possible on the NeXT, not
as good as the Amiga, but it seems like 20 to 30fps is possible,
unless something else has been overlooked.

	   Don't you notice how SLOW the nExt updates it's windows and displays
   (not what is happening within them, but move a window around and see how long
   it takes to redraw the display (especially with 5 or 6 windows open)) when
   compared even to an Amiga 500, a 16-bit machine running at 7Mhz.

Are you running an 030 NeXT with 8MB of memory.  The problem isn't the
CPU, it the paging to and from disk.  We have been through this
before.  Thanks for joining us late!

	   The point is, what if you have SOMETHING ELSE running as WELL AS the
   ray tracer. Why should EVERY program, EVERYWHERE have to slow down just to
   make the screen update MAYBE 1/10th of a seccond faster?

Dedicated hardware is nice, but it can become a problem if people
write directly to it.  Microprocessors are improving at an incredible
rate.  NeXT year people aren't going to be asking if they should buy a
486 instead of an Amiga, it's going to be SPEC 30+ Compaq machine.  As
I was trying to demonstrate with my 030 + blitter < 040 argument.
There are extra cycles to burn, it doesn't matter if you have to
context switch, you still win.

	   What is this? The old "oops I'm getting my butt kicked here, lets
   quick change the subject to something else" trick? We were talking about
   whether a 68030+blitter is faster than just a 68030, and therefore whether a
   68040+blitter is faster than just a 68040.

Wrong.  Amigoids were screaming that the NeXT is so slow at animation
and thought that NeXT users would be lucky to get 5pfs.  Then someone
pointed out that the blitter is only as fast as a 68030.  So, I
naturally realized that the 68040 was at least three times faster than
an 030, and then proceeded to point out that there is more horsepower
in the NeXT than the A3000.

	   You just don't seem to understand that:
           [ 1 and 2 deleted]
	   3) Having two CPUs is ALWAYS faster than just 1, as long as you
	      pick the jobs that each does correctly

Not necessarily. Can I pick the 1 CPU?  I would think that it depends
on how the system is designed.  1 fast CPU can definitely beat 1
dedicated CPU and another general purpose CPU.  Not to mention the
fact that half of your hardware is being wasted when you aren't doing
graphics.  A ray tracer would definitely win with the 1 fast CPU.

-Mike

