Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!pyrnj!mirror!xanth!kent From: kent@xanth.UUCP (Kent Paul Dolan) Newsgroups: comp.arch Subject: Re: Josephson Junction computers (was: Message-ID: <716@xanth.UUCP> Date: Wed, 18-Mar-87 12:18:56 EST Article-I.D.: xanth.716 Posted: Wed Mar 18 12:18:56 1987 Date-Received: Fri, 20-Mar-87 03:44:14 EST References: <492@cpocd2.UUCP> <43700014@uicsrd> Reply-To: kent@xanth.UUCP (Kent Paul Dolan) Organization: Old Dominion University, Norfolk Va. Lines: 51 In article <43700014@uicsrd> turner@uicsrd.CSRD.UIUC.EDU writes: >At the end there you lost me; the serial bottleneck will NEVER fade >away completely. Some things just have to be done in order. >Admittedly parallel processing is a good thing, but haven't you ever >heard of Amdahl's Law? Parafrased as: The amount of speedup due to >paralleism in a program in inheirently limited to the reciprocal of the >sequential fraction. That is if a program is 99% parallelizable then >on an unlimited number of processors (even given perfect communication) >the maximum possible speedup is only 100. To achieve parallelism of >several orders of magnitude we will have to design algorithms that >compute in parallel more than 99.99% of the time, a difficult feat - >but what better challenge to the modern computer scientist. >--------------------------------------------------------------------------- > Steve Turner (on the Si prairie - UIUC CSRD) > No insult to Gene Amdahl, and maybe I just don't understand something here, but... Didn't we already solve this problem once? Scenario was "aaaargh, I have to go access the disk data! Now I can compute some more!". Scenario is "arrgh, i have to go access the disk Ah! Now I can work while I wait". Seems we called this one multiprocessing. Seems to me the same scam works for jobs that sometimes go serial. Since you were kind enough to provide me with unlimited processors ;-), I'll just put enough parallel jobs running so the the jitter in resource usage due to some jobs going serial for a while is smoothed out. No sense in coining a new word, we can still call this one multiprocessing. After all, as in the earlier case, what we usually want is job _stream_ throughput, rather than _job_ throughput especially. I do NOT volunteer to design, code, or debug the scheduling algorithm for this one...at least not until I get really desperate for a PhD thesis topic in a few years here. ;-) Basis for most of our troubles with Amdahl's Law right now is that our supercomputers are monoprocessors or very scant multiprocessors. Nothing like having a hundred thousand jobs in the run queue to calm down the resource bobbles. ;-) -- Kent Paul Dolan, "The Contradictor", 25 years as a programmer, CS MS Student at ODU, Norfolk, Virginia, to find out how I was supposed to be doing this stuff all these years. 3D dynamic motion graphics a specialty. Work wanted. Unemployment is soooo nice though...I never have to disclaim anything! UUCP : kent@xanth.UUCP or ...seismo!decuac!edison!xanth!kent CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559 Wisdom: "Peace in mankind's lifetime. Why leave a whole universe unexpexpesdos