glassman@ames.arc.nasa.gov (Steven Glassman) (04/11/88)
I have seen (and heard) lots of mentions of Amdahl's laws, but never a
concrete source for any of them. Did Amdahl really invent (or even say) these
laws? Or has he become a legend like the unlucky (law generating) Murphy?
I have heard of at least two laws of parallelism attributed to him. "Amdahl's
First Law" gives the potential speedup of a parallel program based on the
number of processors and the fraction of parallel work available. "Amdahl's
Second Law" (which my reference admitted isn't due to Amdahl and that he
didn't even believe it) gives limits on the amount of speedup in a parallel
program as the number of processors and the program size grow linearly.
Yesterday, I heard a new law attributed to him. This one related the amount
of I/O to the MIPS of the processor (unfortunately, I don't remember it
exactly, but it was something like: one bit of I/O per ??? per MIP).
Anyway, this is a request for a collection of Amdahl's laws and sources for
these laws. They can't all be legends.
Thanks,
Steve Glassman
{decwrl|ames}!acornrc!glassmanrpw3@ames.arc.nasa.gov (Rob Warnock) (04/18/88)
In article <1354@hubcap.UUCP> acornrc!glassman@ames.arc.nasa.gov (Steven Glassman) writes: +--------------- | Yesterday, I heard a new law attributed to [Amdahl]. This one related the | amount of I/O to the MIPS of the processor (unfortunately, I don't remember | it exactly, but it was something like: one bit of I/O per ??? per MIP). +--------------- This is actually the oldest "Amdahl's Law". It dates back to the IBM/360 days, and was a rule of thumb for balancing CPU, memory, and I/O... with the caveat that it was intended for the 360 (now 370) instruction set, when running business (read "COBOL") programs (mostly big sorting jobs). It went (approximately -- sorry, no formal reference): "For each instruction/second of CPU, you need one byte of main memory, and one byte/second of I/O performance." Using current terminolgy, that would say that, for example, a 15 VUPS machine needs 15 Mbytes of RAM and 15 Mbyte/sec of I/O. For RISC machines, better add some memory to account for the lesser code density. For Unix, add some memory for disk buffer caches, network "mbuf"s, etc. For timesharing machines in general, add more memory to give good interactive performance (hold down swapping/paging). Enough memory (say, twice the amount called out above) lets you skimp a little bit on I/O performance. Still, today's relatively low-priced Unix systems (with a few notable exceptions among the higher-priced brands) tend to be really bottlenecked on I/O. Note that an Ethernet can't give a sustained Mbyte/sec, and an ST412 disk can't do half that. RISC systems with 10-25 VUPS are gonna be hurting. MASSIVE amounts of disk buffer cache (30-100 Mbyte) can help the disk problem, though... Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403