Path: utzoo!utgpu!attcan!uunet!peregrine!elroy!ames!ncar!oddjob!uxc!uxc.cso.uiuc.edu!urbsdc!aglew From: aglew@urbsdc.Urbana.Gould.COM Newsgroups: comp.arch Subject: Re: Self-modifying code (and bitblt Message-ID: <28200184@urbsdc> Date: 30 Jul 88 16:52:00 GMT References: <306@hobbit.sci.kun.nl> Lines: 39 Nf-ID: #R:hobbit.sci.kun.nl:306:urbsdc:28200184:000:1678 Nf-From: urbsdc.Urbana.Gould.COM!aglew Jul 30 11:52:00 1988 > Can you say "imbalanced system"? Getting away from the Blitter wars, what exactly do people mean by a "balanced system", and why is it so important. This is a somewhat rhetorical question. And yes, I know about Amdahl's MIPS/MB/s rule of thumb, and a few others. I ask this because I have seen several situations where building unbalanced systems has been an attractive corporate strategy. Eg. a small company that can't do everything at once, and wants to maintain a high rate of delivery of new projects: Start off with a really fast memory system, and good, but not necessarily the fastest CPUs. Deliver this as your first system. Keep the memory system, but work all out on the CPU. Deliver this as your second system - with the advantages that the memory system is tried and proven, so all that you have to devote debugging and langauge effort to is the CPU system. Now the memory is tired, so spend time and effort working on it - but keep the proven CPUs... And so on. This is an overlapping product development strategy - eventually, the whole system gets redone, but at any time you don't have the expense and risk of giving the customer a completely new system. Reactions? Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have MX records aglew@xenurus.gould.com - if you don't ...!ihnp4!uiucuxc!ccvaxa!aglew - paths may still be the only way My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.