Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utastro.UUCP
Path: utzoo!watmath!clyde!burl!hou3c!hocda!houxm!houxz!vax135!floyd!cmcl2!seismo!ut-sally!utastro!nather
From: nather@utastro.UUCP (Ed Nather)
Newsgroups: net.micro,net.micro.68k,net.arch
Subject: Re: 68020 vs. 32032, pros and cons
Message-ID: <98@utastro.UUCP>
Date: Wed, 13-Jun-84 12:27:13 EDT
Article-I.D.: utastro.98
Posted: Wed Jun 13 12:27:13 1984
Date-Received: Thu, 14-Jun-84 01:17:34 EDT
References: <4728@amd70.UUCP>
Organization: UTexas Astronomy Dept., Austin, Texas
Lines: 30

[]
    >It's a shame that Motorola thinks the way to high performance is
    >to crank up the clock rate. It's really expensive to provide the
    >kind of memory needed by a 16 MHz processor.
    >
    >	trying not to be biased,
    >-- 
    >Phil Ngai

This makes no sense to me.  Traditionally the cpu operations have always
been faster than memory operations, since the same technology applied to
either operation favors the simpler.  We've learned how to make registers
really fast, and cpu operations parallel and individually simple because
we can afford to dissipate a lot of power to crunch one word -- but we
can't afford the same power in a semiconductor memory system on a per-word
basis.

It seems to me the best way to make a computer go twice as fast is to double
the clock speed.  If the memory cost rises more than a factor of 2 we then
lose ground on all applications where the cost vs time tradeoff is linear --
not all applications by any means.  Now try to get the memory to go faster.
Trying to gain a factor of two by changing only the architecture, and keeping
the clock speed the same, is terribly difficult if not impossible.  I tried
it once, and lost.

-- 

                                 Ed Nather
                                 {allegra,ihnp4}!{ut-sally,noao}!utastro!nather
                                 Astronomy Dept., U. of Texas, Austin