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