gillies@m.cs.uiuc.edu (09/28/90)
DEC VAX-11/780 - first commercial supermini. ^^^^^ Second commercial supermini? I think Perkin-Elmer had the first 32-bit supermini (but it could have been Gould). How about: DEC VAX-11/780 - began RISC backlash that lasted more than a generation
fwb@demon.siemens.com (Frederic W. Brehm) (09/28/90)
>... I think Perkin-Elmer had the first >32-bit supermini (but it could have been Gould). You're probably thinking of the Interdata 32-bit mini that was introduced in the mid 70's. Interdata was subsequently purchased by Perkin-Elmer. Fred -- Frederic W. Brehm Siemens Corporate Research Princeton, NJ fwb@demon.siemens.com -or- ...!princeton!siemens!demon!fwb
aglew@crhc.uiuc.edu (Andy Glew) (09/29/90)
>DEC VAX-11/780 > - first commercial supermini. > ^^^^^ >Second commercial supermini? I think Perkin-Elmer had the first >32-bit supermini (but it could have been Gould). How about: Gould (actually, SEL, the company Gould bought out). -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
tom@stl.stc.co.uk (Tom Thomson) (10/01/90)
>>... I think Perkin-Elmer had the first >>32-bit supermini (but it could have been Gould). Of course the first commercial supermini was the ICL 2903; that was a 24bit machine, not a 32bit one. Its introduction effectively created the (European) market for superminis, in the early 70s. Interesting that the list so far seems to be very american - - I guess that's just the usual transatlantic chauvinism, nothing can conceivably happened this side of the pond since Atlas? Would you regard things like Content Addressable File Store, or the Distributed Array Processor, or an Algol-68 oriented machine as architectural advances? They all came out of ICL in the 70s. Or how about Iliffe's Basic Language Machine and all the ideas that that started off? Or Iann Barron's Modular One machine? Or Colmerauers work at Marseille (assuming software architecture counts)?
wright@stardent.Stardent.COM (David Wright @stardent) (10/04/90)
In article <3300185@m.cs.uiuc.edu>, gillies@m.cs.uiuc.edu writes: >DEC VAX-11/780 > - first commercial supermini. ^^^^^ >Second commercial supermini? I think Perkin-Elmer had the first >32-bit supermini (but it could have been Gould). The VAX is no better than third, since the Prime P400 was on the market ahead of the VAX. In fairness, I believe that Prime was not first either. -- David Wright, not officially representing Stardent Computer Inc wright@stardent.com or uunet!stardent!wright Groucho: America is waiting to hear him sing! Chico: Well, he can sing pretty loud, but not that loud. -- A Night at the Opera
seanf@sco.COM (Sean Fagan) (10/06/90)
In article <1990Oct4.001346.4139@Stardent.COM> wright@stardent.Stardent.COM (David Wright @stardent) writes: >In article <3300185@m.cs.uiuc.edu>, gillies@m.cs.uiuc.edu writes: >>DEC VAX-11/780 >> - first commercial supermini. > ^^^^^ I'm still wondering at why it's being called a 'supermini'... -- -----------------+ Sean Eric Fagan | "Never knock on Death's door: ring the bell and seanf@sco.COM | run away! Death really hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/09/90)
In article <8052@scolex.sco.COM> seanf (Sean Fagan) writes: | I'm still wondering at why it's being called a 'supermini'... Compare it to the mini's being sold at the time, and the mainframes. The VAX was a major step forward in price/performance. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
eliot@cs.qmw.ac.uk (Eliot Miranda) (10/10/90)
I think you have to include the Xerox Alto (ancestor of the Xerox D
machines). It was the first personal computer with
all of the following
a raster scanned display
keyboard/mouse (with buttons)
cartridge hard disc
interface to ethernet
multitasking microprogramming (8 different microcode
tasks at different priorities)
It was the first machine to run Smalltalk & the first machine
to run a WIMP interface.
Alto: A Personal Computer
Thacker, McCreight,Lampson,Sproul,Boggs
in
Computer Structures: Principles & Examples
Siewiorek,Gordon Bell & Newell
pp 549-572
McGraw Hill
--
Eliot Miranda email: eliot@cs.qmw.ac.uk
Dept of Computer Science Tel: 071 975 5229 (+44 71 975 5229)
Queen Mary Westfield College ARPA: eliot%cs.qmw.ac.uk@nsfnet-relay.ac.uk
Mile End Road UUCP: eliot@qmw-cs.uucp
LONDON E1 4NSseanf@sco.COM (Sean Fagan) (10/11/90)
In article <2750@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > Compare it to the mini's being sold at the time, and the mainframes. >The VAX was a major step forward in price/performance. Using your fingers to do addition is an incredible performance/price ratio (since price is 0). Price/performance has never, as far as I can tell, been an indication of a computers "class" (micro, mini, mainframe, super). The 750 and 780 had horrible performance; most current micros can outperform them (with the exception of I/O), and their I/O performance is low-end mini, even for the day and age. -- -----------------+ Sean Eric Fagan | "Never knock on Death's door: ring the bell and seanf@sco.COM | run away! Death really hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
henry@zoo.toronto.edu (Henry Spencer) (10/11/90)
In article <2926@sequent.cs.qmw.ac.uk> eliot@cs.qmw.ac.uk (Eliot Miranda) writes: >I think you have to include the Xerox Alto (ancestor of the Xerox D >machines). It was the first personal computer with >all of the following > ... > interface to ethernet > multitasking microprogramming (8 different microcode > tasks at different priorities) These last two are kind of cheating. The Alto was the first machine of any kind with an Ethernet interface, since Ethernet was invented as a fast communication system for the Alto. I suspect that if you dig for it, you could find earlier machines with fast communications links. And the multimicroprogramming is a dubious "first", since almost nobody has copied it; it qualifies as peculiar rather than history-making. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (10/11/90)
In article <8139@scolex.sco.COM> seanf (Sean Fagan) writes: >>The VAX was a major step forward in price/performance. > >The 750 and 780 had horrible performance... True, although comparing them against today's micros is cheating. A better comparison is against the contemporary pdp11s. The VAXes had an obvious advantage in address space, which gave them a decisive edge in handling problems involving large amounts of data. However, for problems that would fit in an 11, the comparison doesn't look so good. The 780 was no better than neck and neck with an 11/70, and the 750 was definitely slower than an 11/44... despite the VAXes being much bigger, much more expensive, and rather newer technology. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
peter@ficc.ferranti.com (Peter da Silva) (10/12/90)
aWhat made the VAX a "supermini" was that it was 32-bit, rather than 16+ bit. This let you run problems on it that would previously have required a mainframe, albeit slowly. As for what makes a mini/micro/mainframe... if you can hold the CPU in one hand (1 to a few chips) it's a micro. In two hands (1 to a few boards) it's a mini. Otherwise it's a mainframe. And if it's what you buy for no holds barred performance (extreme inflexibility in demand curve), it's a super. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jpk@ingres.com (Jon Krueger) (10/13/90)
From article <8139@scolex.sco.COM>, by seanf@sco.COM (Sean Fagan): > The 750 and 780 had horrible performance; > most current micros can outperform them Micros have an impressive history of performance improvements. Their architectures, however, are better termed retreats than advances. They skimped on address bits. And committed other abominations. VAX processor speed wasn't impressive. Ever. Its large flat virtual address spaces were. Particularly ten years ago and for a price that departments could afford. For that reason it could be considered an architectural advance. If "most current micros" means boxes sold, you're referring to a class of machines whose small physical spaces and ancient operating systems get diminishing returns on increased processor speed. In some cases negative returns. "Outpeform" is at best misleading in this context. If "most current micros" means a majority of architectures currently available for sale in microprocessor implementations, you're absolutely right. And it took ten years. In computing, that's history. -- Jon -- Jon Krueger, jpk@ingres.com
pcg@cs.aber.ac.uk (Piercarlo Grandi) (10/13/90)
On 11 Oct 90 16:49:04 GMT, henry@zoo.toronto.edu (Henry Spencer) said:
henry> In article <2926@sequent.cs.qmw.ac.uk> eliot@cs.qmw.ac.uk (Eliot
henry> Miranda) writes:
eliot> I think you have to include the Xerox Alto (ancestor of the Xerox
eliot> D machines). It was the first personal computer with all of the
eliot> following
eliot> ...
eliot> interface to ethernet
eliot> multitasking microprogramming (8 different microcode
eliot> tasks at different priorities)
henry> These last two are kind of cheating. The Alto was the first machine of
henry> any kind with an Ethernet interface, since Ethernet was invented as a
henry> fast communication system for the Alto.
This is not cheating -- it is a real first, IMNHO, as far as Ethernet is
concerned. But then I would also put the Cambridge ring system in as an
important historical first (as a processor pool system).
henry> I suspect that if you dig for it, you could find earlier machines
henry> with fast communications links.
Yes, the MU5 multicomputer complex.
Well, among the machines that made the history of architecture I would
put every architecture from Manchester University; the most recent ones
have been the MU5 (late sixties, early seventies) that among many other
things was the first heterogenous multicomputer complex with a portable
network operating system I can think of (the os was much, much faster
and more powerful than 4BSD networking, and 10-15 years before it, and
around one tenth the size), where the 'local net' was a giant OR-gate,
the MU6, which, among other things, as far as I know was the first 64
bit supermini (late seventies, early eighties), and the Dataflow Machine
(first operational general purpose dataflow architecture to run real
programs, and for a long time the only one that actually worked, from
what I remeber). Not to mention the previous generations, like Atlas
(MU4?), the first virtual memory machine (and much else besides) etc...
Naturally the problem is that only 'in' people know much about the
Manchester University work. This is amazing, because I know of no other
group (except perhaps for Zuse's group) that has had an unbroken record
of developing 6 successive generations of state of the art supercomputer
architectures over forty years. Many commercial companies have done it,
of course, but without the continuity (a doubt here: maybe Burroughs) of
the architecture group. Even Seymour Cray is a relative newcomer
compared to them.
henry> And the multimicroprogramming is a dubious "first", since almost
henry> nobody has copied it; it qualifies as peculiar rather than
henry> history-making.
Didn't the Burroughs minis have multimicroprogramming as standard long
before the Alto? From what I remember the 1700 had statically loaded
multi microprograms, while the 1800 even had *paged* microcode...
Note that the Burroughs concept was not bad -- they achieved phenomenal
code densities. They had a separate microprogram for each language, so
to run multiple language in multiprogramming you had to be able to
switch microcode (and instruction set) at every context switch.
Phenomenal code densities are also a property of the Burroughs
mainframe architecture, incidentally -- if only they had
multiple arithmetic stacks they would have been fast on
numeric problems too.
The instruction sets were tailored to each compiler, and each compiler
could thus make easy use of the complex instructions, thus removing one
of the major problems of CISC architectures, that complex instruction
almost never match what the compiler wants to do, and thus are rarely
used.
Note: phenomenal code densities means up to a a fifth/tenth of
VAX/68000/386 code size.
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukphil@motaus.sps.mot.com (Phil Brownfield) (10/14/90)
In article <1990Oct13.035313.174@ingres.Ingres.COM> jpk@ingres.com (Jon Krueger) writes: > >Micros have an impressive history of performance improvements. Their >architectures, however, are better termed retreats than advances. They >skimped on address bits. And committed other abominations. > >VAX processor speed wasn't impressive. Ever. Its large flat virtual >address spaces were. Particularly ten years ago and for a price that >departments could afford. For that reason it could be considered an >architectural advance. The MC68000 supports a 16MB linear address map. It has 8 32-bit address registers (as well as 8 32-bit data registers), and all address calculations are 32-bit precision. It was introduced in 1979. It is generally conceded that the 8Mhz MC68000, which went into production in '81, is around 0.8 VUPS. Just to refresh your memory. :-) -- Phil Brownfield | In America, anyone can become president. It's phil@motaus.sps.mot.com | one of the risks we take. - Adlai E. Stevenson {cs.utexas.edu!oakhill, mcdchg}!motaus!phil speaking for myself, not my employer
seanf@sco.COM (Sean Fagan) (10/14/90)
In article <0KC6TSG@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >What made the VAX a "supermini" was that it was 32-bit, rather than 16+ bit. >This let you run problems on it that would previously have required a >mainframe, albeit slowly. Uhm... in that case, you could always run interpreted code, a la Sweet-16. Doesn't make the 6502 a 16-bit machine, nor a mini-computer, though. >As for what makes a mini/micro/mainframe... if you can hold the CPU in >one hand (1 to a few chips) it's a micro. In two hands (1 to a few boards) >it's a mini. Otherwise it's a mainframe. And if it's what you buy for no >holds barred performance (extreme inflexibility in demand curve), it's a >super. Bzzt. I disagree, and quite strongly. I break things down based on performace characteristics. Micro, actually, I will, for the most part, agree with you. But what about things like the Iris family, from SGI? They are still micros, I think (supermicros, to be sure, but micros), even though they have multiple-board processors (CPU, graphics, etc.). The only reason I would still call a PDP-11 a mini is because of the I/O performance: it's still better than any micro I've ever seen (although I suspect that will change soon. I hope). The CDC Cyber 170 state machines were mainframes, because they maximised throughput: high CPU speed combined with incredible I/O throughput. A Cray YMP does not get I/O throughput to match its CPU performance; thus it is a supercomputer, not mereley a very fast mainframe. A mainframe should be able to handle a hundred or more users, simultaneously, without slowing down. A killer mainframe (not to be confused with a killer micro 8-)) should be able to handle more than 500 users without slowing down noticeably. A mini, on the other hand, should be able to handle 10-20 users, without slowing down. A super mini should be able to handle up to about a hundred (with the distinction between a supermini and a mainframe being that the supermini is the highend model 8-)). A micro should be designed to be a single-user machine, even if, in reality, several people use it. For example, my home computer, a 25Mhz '386, can handle 4 or 5 people logged in at once (although it does begin to get a bit slow), but that's taxing it. A supercomputer is a mainframe (hopefully faster than a mainframe, actually), but without the ability to handle as many users. For example, a Cray is not really a multi-user machine: it runs best with batch jobs, one job per CPU (or one job per multiple CPU, depending on the job). An Amdahl, on the other hand, won't necessarily speed up too much if you are the only person on it. (I guess I'm talking about performance curve, here.) This, btw, is why I don't think the VAX 780 was a supermini. A 780 with 5 people on it, all doing CPU and I/O intensive work, can be quite painful to be on; a 750 with more than one person on it is. (Personal opinions, of course 8-).) Now, if we want to start (again) a discussion of how to improve performance on a machine, I'm perfectly willing to post my arguments again 8-). -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
peter@ficc.ferranti.com (Peter da Silva) (10/14/90)
In article <1990Oct13.200414.3523@motaus.sps.mot.com> phil@motaus.sps.mot.com (Phil Brownfield) writes: > In article <1990Oct13.035313.174@ingres.Ingres.COM> jpk@ingres.com (Jon Krueger) writes: > >VAX processor speed wasn't impressive. Ever. Its large flat virtual > >address spaces were. ^^^^^^^ > The MC68000 supports a 16MB linear address map. [in 1981]... The MC68000 is a great CPU. It's a lot later (in computer generation terms) than the VAX, though. Plus, it doesn't support virtual memory worth a damn... it wasn't even up to PDP-11 standards there... remember the problems with the Bourne shell which assumed memory faults were recoverable? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (10/15/90)
In article <1990Oct13.035313.174@ingres.Ingres.COM> jpk@ingres.com (Jon Krueger) writes: > >If "most current micros" means boxes sold, you're referring to a class >of machines whose small physical spaces and ancient operating systems >get diminishing returns on increased processor speed. To nit-pick: The IBM PC (and it's operating system) is quite new when compared to IBM OS/360, Unix, VMS, etc. As Jon points out elsewhere in his article, newer does not mean better. By the same token, bad does not mean ancient. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!uunet!bnrgate!bcarh185!schow (613) 763-2831 ..!psuvax1!BNR.CA.bitnet!schow Me? Represent other people? Don't make them laugh so hard.
aglew@crhc.uiuc.edu (Andy Glew) (10/15/90)
>>VAX processor speed wasn't impressive. Ever. Its large flat virtual >>address spaces were. Particularly ten years ago and for a price that >>departments could afford. For that reason it could be considered an >>architectural advance. > >The MC68000 supports a 16MB linear address map. It has 8 32-bit >address registers (as well as 8 32-bit data registers), and all >address calculations are 32-bit precision. It was introduced in >1979. It is generally conceded that the 8Mhz MC68000, which went >into production in '81, is around 0.8 VUPS. And the MC68000 didn't have virtual memory. Not all instructions could handle page faults, etc. It took a while before the 68000 was suitable for use as a "real machine". I trust everyone knows about the twinned 68000s used in early Apollos? One a cycle behind the other, so that it could pick up at a page fault? -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
don@zl2tnm.gp.govt.nz (Don Stokes) (10/15/90)
phil@motaus.sps.mot.com (Phil Brownfield) writes: > The MC68000 supports a 16MB linear address map. It has 8 32-bit > address registers (as well as 8 32-bit data registers), and all > address calculations are 32-bit precision. It was introduced in > 1979. It is generally conceded that the 8Mhz MC68000, which went > into production in '81, is around 0.8 VUPS. - It had no MMU. - It was a processor, not a system. Serious 68000 based systems were quite a while coming, and weren't cheap. Don Stokes, ZL2TNM / / Home: don@zl2tnm.gp.govt.nz Systems Programmer /GP/ Government Printing Office Work: don@gp.govt.nz __________________/ /__Wellington, New Zealand_____or:_PSI%(5301)47000028::DON
roy@phri.nyu.edu (Roy Smith) (10/15/90)
aglew@crhc.uiuc.edu (Andy Glew) writes: > I trust everyone knows about the twinned 68000s used in early Apollos? > One a cycle behind the other, so that it could pick up at a page fault? Isn't Apollo the company that designed a new machine around the 68000 architecture but wanted to ship before they could get quantity silicon so they designed and built their own 68k emulator and shipped boxes with that in it? Or something like that? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
hank@masscomp.ccur.com (Hank Cohen) (10/16/90)
In article <AGLEW.90Oct14222151@basagran.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: > >And the MC68000 didn't have virtual memory. Not all instructions >could handle page faults, etc. It took a while before the 68000 was >suitable for use as a "real machine". > >I trust everyone knows about the twinned 68000s used in early Apollos? >One a cycle behind the other, so that it could pick up at a page fault? Not early Apollos early Masscomps. ( Of course Masswho or Whatcomp always suffered from a lack of recognition.) The first products from MASSCOMP used two 68000's one called the Executor and the other the Fixor. The fixor was mostly idle until a bus fault occurred at which time it would wake up and examine the state of the executor and try to make things right again by bring in pages and updating the MM (the MMU was a MASSCOMP design. As a previous poster noted Motorola didn't have one yet.) Later releases of the OS implemented floating point emulation on the fixor and when we got 68010s the executor could save the state of the faulted process and continue doing something else while the fixor made the world safe for virtual memory again. That was a big improvement since the 68000 executor had to wait for page-ins and was therefore horribly slow and unreliable for really big processes. Hank Cohen
jpk@ingres.com (Jon Krueger) (10/16/90)
>from phil@motaus.sps.mot.com (Phil Brownfield): >The MC68000 [had a 24 bit space in 1979 and support for future >models with 32 bit spaces]... Thanks for refeshing my memory. Perhaps you can help me with the other side of the comparison. I seem to remember that DEC was shipping a processor with a 30 bit space in 1978 and support for future models with 32 bit spaces. I wonder what ever became of that line. -- Jon -- Jon Krueger, jpk@ingres.com
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/17/90)
In article <8185@scolex.sco.COM> seanf (Sean Fagan) writes: | Uhm... in that case, you could always run interpreted code, a la Sweet-16. | Doesn't make the 6502 a 16-bit machine, nor a mini-computer, though. Amazing what you can do with interpreted code if you throw enough power at ti... A few years ago I got a program which did some data analysis on some number of interest. The problem was that the program was for Apple ][, and the source long gone. However, I found an Apple ][ simulator, written in PL-I. Unfortunately the only PL-I I have handy is for CP/M, and my CP/M system was doing something else. Not to worry, I have a simulator for CP/M which runs under DOS, but I don't usually have a DOS machine home. I do, however, have DOS encapsulation under UNIX, and that's how I finally ran it. The Apple ][ simulator compiled and ran under CP/M-80, as simulated under DOS, as encapsulated under UNIX, as run on a 386. The original version ran 12 minutes to do a data set, the deeply simulated version ran seven, on a system which was also supporting several BBS users and a uucp connection doing a news feed. If you didn't use micros in the 70's, you can't appreciate how far they've come. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
elm@sprite.Berkeley.EDU (ethan miller) (10/17/90)
In article <61266@masscomp.ccur.com>, hank@masscomp.ccur.com (Hank Cohen) writes: %In article <AGLEW.90Oct14222151@basagran.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: %> %>And the MC68000 didn't have virtual memory. Not all instructions %>could handle page faults, etc. It took a while before the 68000 was %>suitable for use as a "real machine". %> %>I trust everyone knows about the twinned 68000s used in early Apollos? %>One a cycle behind the other, so that it could pick up at a page fault? % %Not early Apollos early Masscomps. ( Of course Masswho or Whatcomp %always suffered from a lack of recognition.) [description of Masscomps omitted...] Perhaps it is true that Masscomp used two 68000s, but I *know* Apollo used dual 68000s in their DN300s. I used them as an undergrad at Brown, and learned a lot about their hardware. The CPU that was a cycle ahead would suffer the unrecoverable bus errors, and the trailing CPU would know to stop at that point, load the necessary page (via token ring net that slowed down really terribly with 50 active users :-), and continue after making sure the leading CPU was in the right place with the correct state. This was also the first time I saw virtual memory for the display. If a page wasn't present, the area was black. ethan ================================= ethan miller--cs grad student elm@sprite.berkeley.edu #include <std/disclaimer.h> {...}!ucbvax!sprite!elm Witty signature line condemned due to major quake damage.
peter@ficc.ferranti.com (Peter da Silva) (10/17/90)
In article <8185@scolex.sco.COM> seanf (Sean Fagan) writes: > > In article <0KC6TSG@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >What made the VAX a "supermini" was that it was 32-bit, rather than 16+ bit. > >This let you run problems on it that would previously have required a > >mainframe, albeit slowly. > Uhm... in that case, you could always run interpreted code, a la Sweet-16. > Doesn't make the 6502 a 16-bit machine, nor a mini-computer, though. Speed wasn't *completely* irrelevant... it did have to compete with timeshare services. Geeze... > Bzzt. I disagree, and quite strongly. I break things down based on > performace characteristics. Problem is, performance characteristics are a moving target. > Micro, actually, I will, for the most part, agree with you. But what about > things like the Iris family, from SGI? They are still micros, I think > (supermicros, to be sure, but micros), even though they have multiple-board > processors (CPU, graphics, etc.). Not familiar with it, but it sounds like a mini to me. Or is it a multiprocessor box? multiprocessors and coprocessors are another universe. > A mini, on the other hand, should be able to handle 10-20 users, without > slowing down. Well, we have a 68000 (yes, 000) based micro that soaks up 32 users. How about that... more than an 11/750 could ever handle. Performance figures are a moving target. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
mshute@cs.man.ac.uk (Malcolm Shute) (10/17/90)
In article <8139@scolex.sco.COM> seanf (Sean Fagan) writes: >Using your fingers to do addition is an incredible performance/price ratio >(since price is 0). Just to nit-pick... the price of fingers can't be zero, otherwise we'd each be able to order an unlimited number of them (at zero total cost). I agree with the rest of the point you were trying to make, though. -- Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all
rsc@merit.edu (Richard Conto) (10/19/90)
In article <1808@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >In article <8139@scolex.sco.COM> seanf (Sean Fagan) writes: >>Using your fingers to do addition is an incredible performance/price ratio >>(since price is 0). >Just to nit-pick... the price of fingers can't be zero, otherwise we'd each >be able to order an unlimited number of them (at zero total cost). It isn't a nit-pick. You need to determine how much fingers cost you, and how much the time it takes to perform the calculation costs you. Just think about hiring a bunch of teenagers away from McDonalds (at minimum wage, because the working conditions are better...). Suppose a teenager can perform 1 integer operation in 1 second, and 1 floating point operation in 2 seconds. (Fantasy, I know...) The price/performance here is ($4.25 /hr)/((1Flop/2seconds)* (3600seconds/hr)*(1Mflop/1000000Mflop)), or $2361/Mflop. Even if you can get faster teenagers, that number is still going to be pretty big. And who knows about accuracy. Now, all of these numbers seem pretty optomistic to me. And what happens when OSHA comes down on you when all the teenagers come down with carpal tunnel syndrome? --- Richard ;-)
lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (10/19/90)
In article <PCG.90Oct13101440@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Note that the Burroughs concept was not bad -- they achieved phenomenal >code densities. They had a separate microprogram for each language, so >to run multiple language in multiprogramming you had to be able to >switch microcode (and instruction set) at every context switch. I believe that the Cobol compiler achieved the most dramatic code density - an order of magnitude at times. Given this apparently big win, why did the idea die off? I suspect it's because they slimmed the user's code sizes by increasing the system's code size. The micromemory has to be faster than main memory, hence more costly: perhaps not all users got a net win. That may not be the reason. Somewhat later, Xerox invested effort in tuning an instruction set for maximum density. This was partly a bet that memory cost mattered more than speed, and partly a bet that code size would be a significant fraction of memory size. They pretty much lost their bet, and are now using SPARC. -- Don D.C.Lindsay
firth@sei.cmu.edu (Robert Firth) (10/19/90)
In article <1990Oct18.172601.24943@terminator.cc.umich.edu> rsc@merit.edu (Richard Conto) writes: >suppose a teenager can perform 1 integer >operation in 1 second, and 1 floating point operation in 2 seconds. Excuse me, but are these loosely coupled or tightly coupled teenagers? Contrary to architectural intuition, one tends to get substantially fewer Mflops from the latter.
jpk@ingres.com (Jon Krueger) (10/20/90)
From article <1808@m1.cs.man.ac.uk>, by mshute@cs.man.ac.uk (Malcolm Shute): > the price of fingers can't be zero, otherwise we'd each > be able to order an unlimited number of them (at zero total cost). Does make you wonder what project manager would sign off on construction of the human body. Assuming that they weren't already commercially available, of course. -- Jon -- Jon Krueger, jpk@ingres.com
peter@ficc.ferranti.com (Peter da Silva) (10/23/90)
In article <3450@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: > To nit-pick: The IBM PC (and it's operating system) is quite new > when compared to IBM OS/360, Unix, VMS, etc. Au contraire. The IBM-PC operating system was obsolete in 1965 (or whenever the first timeshare system went online). The fact that it wasn't implemented for another 16 years is irrelevant. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
sjc@key.COM (Steve Correll) (10/30/90)
>In article <8139@scolex.sco.COM> seanf (Sean Fagan) writes: >Using your fingers to do addition is an incredible performance/price ratio >(since price is 0). In article <6547@uceng.UC.EDU>, dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes: > If the price of your fingers is zero, does that mean I can hire you to > cut yours off for zero dollars? How much money would you accept in > exchange for agreeing to give up your fingers? That is their price. > > If the price of fingers was zero, nobody would have invented computers. > > Adding on your fingers is incredibly expensive. If anyone doubts this, > let them try to run a company that way. Hmm, time for an armchair-economist alert? I agree with Dan the price of your fingers is probably very high. But I agree with Sean that the marginal price of being able to add by counting on your fingers (that is, the value you place on being able to add with them given that you have the use of them for other purposes) is probably rather low. Assuming I still let you use your fingers to feed yourself, button your clothes, and enter data into a calculator, I probably won't have to pay much to get you to promise that you'll never count on your fingers again. That's their marginal price. It's incorrect to use the total price of a resource, rather than the marginal price, when estimating price-performance for a marginal use of the resource. Addition by counting on fingers is expensive for a business not because an insurance company will pay a lot for the loss of them--after all, for a pittance, you can hire a lot of third-world fingers to help you count things, without cutting anybody's fingers off. Rather, finger addition is slow and error-prone compared with calculators, computers, and pencils. In fact, competition from such superior technology is one of the factors which depresses the marginal value of fingers for purposes of addition... Clear? Now we return you to the other sense of "digital computation". :-) -- sjc@key.com or ...{sun,pyramid}!pacbell!key!sjc Steve Correll
mshute@cs.man.ac.uk (Malcolm Shute) (10/31/90)
In article <8185@scolex.sco.COM> seanf (Sean Fagan) writes: >A mainframe should be able to handle a hundred or more users, [...] >A mini, on the other hand, should be able to handle 10-20 users, without >slowing down. [...] Does your classification scheme handle a loosley coupled system (such as a department's worth of SUNs connected on a LAN)... Does the overall system (network) qualify as being a mainframe/supermini? -- Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all
seanf@sco.COM (Sean Fagan) (11/03/90)
In article <1868@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >Does your classification scheme handle a loosley coupled system >(such as a department's worth of SUNs connected on a LAN)... >Does the overall system (network) qualify as being a mainframe/supermini? Do you, your wife, and your two children qualify as a single person with 8 arms? No. -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
mshute@cs.man.ac.uk (Malcolm Shute) (11/06/90)
In article <8553@scolex.sco.COM> seanf (Sean Fagan) writes: >In article <1868@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >>Does your classification scheme handle a loosley coupled system >>(such as a department's worth of SUNs connected on a LAN)... >>Does the overall system (network) qualify as being a mainframe/supermini? >Do you, your wife, and your two children qualify as a single person with 8 >arms? No. Not so fast with your glib remarks! I asked the question expecting you to say "No", but I was interested in the logic behind your classification. I, my wife, and two children (if indeed I were married and had two children) would have different DNA, so you would be able to distinguish the 4.0e12 (or whatever) cells of our four combined bodies into four distinct organisms; you would have a harder job with four *interconnected* computers. What is the difference between a loosely coupled multicomputer system, and a tightly coupled multiprocessor computer? Granularity of processes for scheduling, and geography of the 'cabinet' size. That is all (just about). Our LAN fits into a cabinet called the Department of Computer Science. How much smaller would it have to be before you would consider it to be a single multiprocesser computer? Or, what other criterion would have to be met before it crossed the threshold? I am seriously interested in finding out how people in comp.arch make this distinction. Is it possible that there is *no* firm dividing line between the two? Does it matter to have an answer to the question? -- Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all
jsc@doc.ic.ac.uk (Stephen Crane) (11/07/90)
In article <1888@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >What is the difference between a loosely coupled multicomputer system, >and a tightly coupled multiprocessor computer? > >Granularity of processes for scheduling, and geography of the 'cabinet' >size. That is all (just about). Failure modes? Tightly-coupled multiprocessors are just that and may be assumed to fail as a single unit whereas, multicomputers exhibit partial failure. > >Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all Stephen, Stephen Crane, Department of Computing, Imperial College, 180 Queensgate, London (SW7 2BZ) #071+[ph]5895111x5092[fax]5818024.------``To my mind, Withers, there is no finer sight than that of a flock of kale in full flight.''"
hamilton@dg-rtp.dg.com (Eric Hamilton) (11/07/90)
In article <1888@m1.cs.man.ac.uk>, mshute@cs.man.ac.uk (Malcolm Shute) writes: |> In article <8553@scolex.sco.COM> seanf (Sean Fagan) writes: |> >In article <1868@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: |> >>Does your classification scheme handle a loosley coupled system |> >>(such as a department's worth of SUNs connected on a LAN)... |> >>Does the overall system (network) qualify as being a mainframe/supermini? |> >Do you, your wife, and your two children qualify as a single person with 8 |> >arms? No. |> |> What is the difference between a loosely coupled multicomputer system, |> and a tightly coupled multiprocessor computer? |> |> Granularity of processes for scheduling, and geography of the 'cabinet' |> size. That is all (just about). |> |> Our LAN fits into a cabinet called the Department of Computer Science. |> How much smaller would it have to be before you would consider it to |> be a single multiprocesser computer? Or, what other criterion would |> have to be met before it crossed the threshold? |> |> I am seriously interested in finding out how people in comp.arch make |> this distinction. Is it possible that there is *no* firm dividing line |> between the two? Does it matter to have an answer to the question? It is obviously and trivially true that there are degrees of loose coupling - in a practical sense the bandwidth and latency characteristics of the interconnect control the sorts of things that you use the interconnect for and hence the tightness of the coupling. I would like to see the term "tightly coupled" reserved for systems in which memory is shared and coherent for all processors and all the processors occupy the same physical address space. The distinguishing characteristic of these machines is that the C construct *p=... can be used to change shared data. A bunch of microprocessors on the same bus qualifies as tightly coupled in this sense.
mash@mips.COM (John Mashey) (11/08/90)
In article <1888@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >What is the difference between a loosely coupled multicomputer system, >and a tightly coupled multiprocessor computer? > >Granularity of processes for scheduling, and geography of the 'cabinet' >size. That is all (just about). >Our LAN fits into a cabinet called the Department of Computer Science. >How much smaller would it have to be before you would consider it to >be a single multiprocesser computer? Or, what other criterion would >have to be met before it crossed the threshold? Although I'd know people would argue with this, some, but I'd suggest that there is a fairly clear dividing line between: a) Uniprocessors, and shared-memory multiprocessors and b) Networks, or even loose-coupled multis in a box Now, clearly, there is a lot of work going on to find ways to make b) act more like a), and there has been a lot of progess, as in network file systems, distributed RPCs, etc, and new algorithms for using non-shared-memory systems. However, we're not there yet, and I doubt that some things EVER will get there. (In some cases, the only machine that helps you much is the fastest uni processor you can build.) Currently: in practice, I think the biggest distinction is USER EXPECTATION, which sounds pretty weird, but I suggest is true. If it is in one physical box, people expect: a) You can add another processor to the box, but the system administers like one system, more or less. *b) Performance on many job streams will be scaled up, if not by 100%, at least by some reasonable fraction, without restructuring of code, or doing anything in particular. In particular, people expect that load-balancing will occur almost invisibly, with relatively small granularity. c) With some work, some kinds of code can fairly easily exploit the random-access nature of shared memory, to make individual problems go faster (where problem could be a big scientific cruncher, or a DBMS, or...) Most customers expect b), whether they should or not! -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
bzs@world.std.com (Barry Shein) (11/08/90)
>What is the difference between a loosely coupled multicomputer system, >and a tightly coupled multiprocessor computer? Once you start talking about bus-speed LANs (e.g. Gb, ~100MB/s, which is as fast as most mini's busses can run) then the distinction becomes less interesting. Other than a little latency it becomes hard to distinguish such a system from one which you just strapped an extension cabinet into. Without that one of the biggest problems with loosely coupled multi-computer systems is the proper emulation of shared-memory (when the effect desired is in fact MIMD.) Reading is easy, writing (update) is harder. Caches make this even harder. Of course, even with a bus-speed LAN it's not enough to just hook up a network interface with some software. For example, if you want anything like MIMD you'll have to do something like a copy-on-write for every modified page in any system that might be addressable by the other system. That sort of thing generally begs a hardware assist, and probably wants multi-ported memory. Anyhow, yes, you can blur the distinctions, but that doesn't mean it is easy to do so. With very large granularity of processing then the whole thing sort of becomes a philosopical, epistemological question. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
jc@atcmp.nl (Jan Christiaan van Winkel) (11/08/90)
From article <1888@m1.cs.man.ac.uk>, by mshute@cs.man.ac.uk (Malcolm Shute): > What is the difference between a loosely coupled multicomputer system, > and a tightly coupled multiprocessor computer? > > Our LAN fits into a cabinet called the Department of Computer Science. > How much smaller would it have to be before you would consider it to > be a single multiprocesser computer? Or, what other criterion would > have to be met before it crossed the threshold? > > I am seriously interested in finding out how people in comp.arch make > this distinction. Is it possible that there is *no* firm dividing line > between the two? Does it matter to have an answer to the question? Let's see what A.S. Tanenbaum has to say ("Computer networks", second ed. Prentice Hall, page 4): interprocessor processors located example distance in same 0.1 m circuit board dataflow macine 1 m system [fuzzy... JC] multiprocessor 10m room Local network 100m building '' '' 1 km campus '' '' 10 km city long haul network 100 km country '' '' 1000 km continent interconnection of long haul networks 10,000 km planet [ ;-) JC] '' '' Maybe you do not like these classifications, but at least it gives us a 'standard' we can base our discussions on. (Who has not read ASTs book?) JC -- ___ __ ____________________________________________________________________ |/ \ Jan Christiaan van Winkel Tel: +31 80 566880 jc@atcmp.nl | AT Computing P.O. Box 1428 6501 BK Nijmegen The Netherlands __/ \__/ ____________________________________________________________________
keith@mips.COM (Keith Garrett) (11/09/90)
In article <2443@gould.doc.ic.ac.uk> jsc@doc.ic.ac.uk (Stephen Crane) writes: >In article <1888@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >>What is the difference between a loosely coupled multicomputer system, >>and a tightly coupled multiprocessor computer? >> >>Granularity of processes for scheduling, and geography of the 'cabinet' >>size. That is all (just about). >Failure modes? Tightly-coupled multiprocessors are just that and may be >assumed to fail as a single unit whereas, multicomputers exhibit partial >failure. I have to disagree. Tightly-coupled MP's can be designed for partial failure. The OLTP folk don't even lose the process. -- Keith Garrett "This is *MY* opinion, OBVIOUSLY" Mips Computer Systems, 930 Arques Ave, Sunnyvale, Ca. 94086 (408) 524-8110 keith@mips.com or {ames,decwrl,prls}!mips!keith
peter@ficc.ferranti.com (Peter da Silva) (11/11/90)
In article <1990Nov7.155719.24413@dg-rtp.dg.com> hamilton@dg-rtp.dg.com (Eric Hamilton) writes: > I would like to see the term "tightly coupled" reserved for > systems in which memory is shared and coherent for all > processors and all the processors occupy the same physical > address space. Fair enough. > The distinguishing characteristic of these > machines is that the C construct *p=... can be used to > change shared data. This means that any group of systems on an Ethernet suddenly become tightly coupled as soon as you boot up Andy Tannenbaum's Amoeba on them, no? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
mshute@cs.man.ac.uk (Malcolm Shute) (11/13/90)
In article <1990Nov7.155719.24413@dg-rtp.dg.com> hamilton@dg-rtp.dg.com (Eric Hamilton) writes: >I would like to see the term "tightly coupled" reserved for >systems in which memory is shared and coherent for all >processors *and* all the processors occupy the same physical >address space. The distinguishing characteristic of these >machines is that the C construct *p=... can be used to >change shared data. A bunch of microprocessors on the >same bus qualifies as tightly coupled in this sense. I worked for some time on a research project in which the machine used a low-level form of some of the Manchester Dataflow ideas combined with some of the Wafer Scale ideas involved in Ivor Catt's Property-1A machine. Since it was originally a dataflow machine (later converted to being a fully-lazy reduction machine), the test for use of the *p= assignment doesn't really work (though being fully-lazy, the concept of pointers is relevant). Since it uses a token-passing machine (packet-based), it could not be described as a shared-memory machine. Indeed, in my favourite form of the project, there was no memory at all other than the storage involved in buffering the tokens from one processor to another, and to the ALU. There was no microcode, no scratch area; just a handful of random combinatorial logic, and a few buffers. So, the clause on the left hand side of your *and* (which I have highlighted with ***s in the quote above), is not applicable either. However, the clause on the r.h.s. of the *and* is applicable to the machine... so maybe I can agree with your definition if you change the *and* into an *or*. Admittedly, the machine was never built. It fell foul of the bain of all multiprocessor computer architecture design: communications costs, and the harnessing of locality. So, maybe you could argue that you are not upset that this machine does not qualify under your definition as it stands. As a last comment, I would be interested to here from anyone who knows of any other non-von Neumann machines which are made entirely from non-von Neumann machine components. I know that certain cellular automata can be shown to be equivalent to a Turing machine... but they make my project look truely efficient!! -- Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all
hamilton@dg-rtp.dg.com (Eric Hamilton) (11/14/90)
In article <GT-6BMG@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: |> In article <1990Nov7.155719.24413@dg-rtp.dg.com> hamilton@dg-rtp.dg.com (Eric Hamilton) writes: |> > I would like to see the term "tightly coupled" reserved for |> > systems in which memory is shared and coherent for all |> > processors and all the processors occupy the same physical |> > address space. |> |> Fair enough. |> |> > The distinguishing characteristic of these |> > machines is that the C construct *p=... can be used to |> > change shared data. |> |> This means that any group of systems on an Ethernet suddenly become tightly |> coupled as soon as you boot up Andy Tannenbaum's Amoeba on them, no? Of course, I shouldn't have said "THE distinguishing characteristic..."; almost any characteristic can be emulated at some cost, so it's hard to come up with truly distinguishing characteristics. I believe that you've described one technique for realizing the semantics of globally shared and coherent memory on top of hardware which doesn't do coherent sharing, and I expect the readership of this newsgroup to come up with many more similar examples. So I'll take the position that the answer to your question is no. You've described a loosely coupled system that emulates a tightly coupled one. Also, I'll take the position that trying to rigorously pin down the distinction between an emulation and the real thing is a sterile exercise - the better the emulation is, the less useful the distinction. And if we look down inside the snooping caches that tie a shared and coherent memory system together, we find local replication of read data, broadcast invalidates, and all the other machinery used to share data in our loosely coupled systems. None of this means that a shared memory system is not usefully different from a loosely coupled system building shared-memory semantics out of, say, the LAN.