Notes on two presentations by Gordon Bell ca. 1998
|
From: Eugene Miya on 18 Feb 2010 20:34 In article <1hej47-uk.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <4b68a53b(a)darkstar>, Eugene Miya <eugene(a)cse.ucsc.edu> wrote: >>In article <hk8oks$afs$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >>>In article <4b6780bb$1(a)darkstar>, Eugene Miya <eugene(a)cse.ucsc.edu> wrote: >>What computer was that? Nick has not answered that. >>I just got an email marvelling how much "power" is in my particular (or .... >>Sid Fernbach, for whom one of the IEEE awards is given, started a briefly >>class classification of supercomputers, and outsiders wondered what they >>VAX, the mainframe, their IBM PC rated on his scale where a Cray 1 was a >>"Class 6" machine. Since I had Sid handy, I had a chance to ask him: >>Oh, they are "class 1/2". They barely even rate. They aren't supercomputers. >>Other friends (in and out of computing) call computers the drug >>equivalent of pot/marijuana. > >Are there any firm definitions of these classes? No, thank god. If you want to read up (and this is in part why the IEEE gives an award by his name): %A Sidney Fernbach, ed. %T Supercomputers, Class VI Systems, Hardware and Software %I North-Holland %C Amsterdam %D 1986 %O ISBN 0-444-87981 1 %K book, text, cray, cdc cyber, data flow, NEC SX-2, Fujitsu VP-200, Hitachi 810/20, vector processing, %K trade/popular/business press, industry references, %X A collection of papers surveying existing computer architectures rather than newer proposed supercomputer architectures. %X A book from one of the men who set up the "Class system" of the DOE. So any say laptop or workstation of our or recent vintage which can demo Cray-1 speed isn't a class 6 machine. Because it's not current. It's not an absolute performance metric. Let me say that the decade I had a chance to meet and know Sid, we would say in hindsight, Sid had ideas peculiar to the DOE/AEC and that period of time and whom a few people still are alive. Sure he wanted the same OS on his Crays, his VAX, his IBM PC, just not COS, MS/DOS, nor VMS. Not Unix at that time for that matter. It is a good thing that CRI didn't listen to him. At least at that time. >>acoustic kitty. ... >>"What makes you think we stopped there?" > >We are seeing huge breakthroughs in audio codecs these days. Phones >audio quality may be improved. Are these cats roaming around the Afghan-Pakistani border? -- Looking for an H-912 (container).
From: Eugene Miya on 18 Feb 2010 20:36 In article <hl5dep$9c5$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >In article <4b74affb$1(a)darkstar>, Eugene Miya <eugene(a)cse.ucsc.edu> wrote: >>Santa Clara Valley is truly an amazing place where you just simply run >>into people. > >I was told that the drivers had that reputation when I worked in >San Jose, though I never saw it myself :-) Right now, it's more pilots. 8^( Amdahl on the other hand is one of a bunch of dirty just not spoken about secrets. -- Looking for an H-912 (container). ------------ And now a word from our sponsor ------------------ Do your users want the best web-email gateway? Don't let your customers drift off to free webmail services install your own web gateway! -- See http://netwinsite.com/sponsor/sponsor_webmail.htm ----
From: Robert Myers on 19 Feb 2010 16:43 On Feb 18, 8:34 pm, eug...(a)cse.ucsc.edu (Eugene Miya) wrote: > In article <1hej47-uk....(a)laptop.reistad.name>, > Morten Reistad <fi...(a)last.name> wrote: > > >In article <4b68a53b(a)darkstar>, Eugene Miya <eug...(a)cse.ucsc.edu> wrote: > >>In article <hk8oks$af...(a)smaug.linux.pwf.cam.ac.uk>, <n...(a)cam.ac.uk> wrote: > >>>In article <4b6780bb$1(a)darkstar>, Eugene Miya <eug...(a)cse.ucsc.edu> wrote: > >>What computer was that? > > Nick has not answered that. > > > > >>I just got an email marvelling how much "power" is in my particular (or > ... > >>Sid Fernbach, for whom one of the IEEE awards is given, started a briefly > >>class classification of supercomputers, and outsiders wondered what they > >>VAX, the mainframe, their IBM PC rated on his scale where a Cray 1 was a > >>"Class 6" machine. Since I had Sid handy, I had a chance to ask him: > >>Oh, they are "class 1/2". They barely even rate. They aren't supercomputers. > >>Other friends (in and out of computing) call computers the drug > >>equivalent of pot/marijuana. > > >Are there any firm definitions of these classes? > > No, thank god. > > If you want to read up (and this is in part why the IEEE gives an award > by his name): > > %A Sidney Fernbach, ed. > %T Supercomputers, Class VI Systems, Hardware and Software > %I North-Holland > %C Amsterdam > %D 1986 > %O ISBN 0-444-87981 1 > %K book, text, cray, cdc cyber, data flow, NEC SX-2, Fujitsu VP-200, > Hitachi 810/20, vector processing, > %K trade/popular/business press, industry references, > %X A collection of papers surveying existing computer architectures > rather than newer proposed supercomputer architectures. > %X A book from one of the men who set up the "Class system" of the DOE. > > So any say laptop or workstation of our or recent vintage which can demo > Cray-1 speed isn't a class 6 machine. Because it's not current. It's > not an absolute performance metric. > > Let me say that the decade I had a chance to meet and know Sid, we would > say in hindsight, Sid had ideas peculiar to the DOE/AEC and that period > of time and whom a few people still are alive. Sure he wanted the same > OS on his Crays, his VAX, his IBM PC, just not COS, MS/DOS, nor VMS. > Not Unix at that time for that matter. It is a good thing that CRI > didn't listen to him. At least at that time. Oh, for shame, Eugene. I don't know exactly how smart you are, but you are smarter than that. Shilling for a DoE bureaucrat, whom the ACM sucked up to? Robert.
From: "Andy "Krazy" Glew" on 20 Feb 2010 12:35 Robert Myers wrote: > Andy Glew has said that a supercomputer is nothing but a big, multi- > tiered switch. That is certainly what supercomputers have come to be, > and I don't want to give the impression that I think even the lame > interconnects we get are necessarily trivial. > > Someone here asked what the subject matter of computer architecture > really is, and one of the "real" architects responded with a list of > subject matter that extends no further than the front-side bus or > whatever has replaced it. I'm glad the "real" computer architects are > here, but the things that once obsessed them have been pretty > thoroughly worked over. Did I? Oh, I'm sure that you can find a post from me along that line. Along the Israeli lines of explanation = simplify + exaggerate. I'm not sure that I would agree (with myself?) that a supercomputer is "nithing but" a big switch. However, the switch, the network, is certainly one of the most important parts, if not THE most important parts, because a) it is important b) it is the part that people working at supercomputer companies can change. E.g. the guys at Cray can't change the CPU much, if they are buying commercial off the shelf CPUs or GPUs; they can't change the DRAMs much; but they have significant control over the interconnect, and some control over the boards/blades that the CPUs go onto. Therefore, present day supercomputer designers are much more expert in the interconnect than anything else. This is not to say that there could not be good stuff to do in the CPU or GPU - in the compute engines. The IBM folks have had some fun with this, but even they have to build CPUs mainly inspired by commercial stuff. Rejiggerng of the cache protocols can certainly be done to make things more supercomputer friendly. Now, much of this can be done outside the CPU. But, as more and more stuff goes into the CPU, this becomes harder. Oh, its not hard to create uncached memory, or memory wghose coherence can be managed in software, using just stuff outside the chip. But you can often do significantly better if you can get some support for the chip. Uncached memory is one particular example. It should be no secret that modern day x86s deprecate this. Not of necessity - way back on P6 I architected 4 different types of UC memory, ranging from something even slower than what we now have, but even more guaranteed to be compatible, through the UC we have now, to fast UC that was weakly ordered, etc. But we decided to go only with the fairly slow but 99.44% compatible version of UC we have now, and not implement the rest. Many supercomputer types want the faster sorts of UC. Unfortnately, they won't get it unless they can change the CPU. (By the way, since leaving Intel I have thought of ways to make UC even faster.) We have discussed in earlier news posts some ideas for cache protocols that, I hope, may make software managed cache coherence more programmer friendly. E.g. using masks visible to the external system to prevent writes from being lost the way conventional software coherence can actually lose writes. I.e. non-lossy, but weakly ordered, SW coherence. Again, this *could* be implemented outside the CPU, e.g. by usng conventional UC to get to the chip boundary. But you would give up the vast majority of the benefit. Similarly, ... oh, so many topics How about efficient fences and synchronization. I hope that you get the idea: there ARE things that can be done inside the CPU to make a big difference to supercomputers. But: you can ship a modern supercomputer using COTS CPUs and GPUs, but if you don't have a good interconnect you don't have a supercomputer product. I.e. a supercomputer-friendly CPU is not in itself a product. The best reason to talk about supercomputer-friendly features inside CPUs and GPUs is if you have reason to expect that the features may be useful in commercial, consumer, etc, markets.
From: "Andy "Krazy" Glew" on 20 Feb 2010 12:54
Morten Reistad wrote: > In article <0384a40d$0$1344$c3e8da3(a)news.astraweb.com>, > Nicholas King <ze(a)zerandconsulting.com> wrote: >> On 02/10/2010 01:31 PM, Robert Myers wrote: > Programming in the real world is about dealing with complexity, and > doing whatever you can to contain it. But we are forgetting the most > important tool we have for dealing with that complexity : language. > > The success of languages like PHP is that they make layers of languages > to deal with that complaxity. You program the machine API in plain C, > and build another language on top. > > People can handle finite amounts of code lines; and complexity correlates > directly with code lines when the project becomes more than trivial in > size. This is where programming projects explode in programmer count. > > But we can address the semantics by having specialist languages.... > > All the large projects I have seen the last 4 decades have had huge > internal semantic gaps. One example of such a gap is programming > business logic where you have to take care of database consistency > issues all the time. > ... > I have long advocated "surface languages" to address such complaxity. > This may mean actually designing new languages for the applications. > There is huge resistance to doing this. But I see daily the productivity > that it generates. >... > > We need more languages. > > This is where the junior programmers scream foul, of course. When > they have to master language implementation and a new, initially > pretty volatile language definition. > > But it is the only path I see to contain complexity. > > -- mrr I mainly agree with Morton on this. Invent a new notation that simplifies thinking about the problem, and use that notation directly to express the solution as a program. Even better if somebody else can make the implementation of the idioms of the new notation faster, better. My only difference is that I hope that it may be possible to define a meta-language, in which many of the new notations can be expressed. Do we really need a new language that defines yet another form of IF-THEN-ELSE syntax? Yet another form of blocking and scope? (E.g. yesterday I learned that Javascript's curly brace { } does not have the same scoping significance as in other languages.) A big problem with everyone defining their own new language, whether translated to C or the Java bytecodes or whatever, is that if two people A and B have their own new languages, it is often hard to write a program that uses both notations A and B in the same code If A and B are completely mutually exclusive, you may have to serialize the data (maybe al the way to XML) to pass it from the A module to the B module. I just hope (and would love to have the chace to work on) that we could create a language framework, a metalanguage, so that the same programmer can intermix A and B notations at as fine grain a level as possible. Ideally within the same {block}. Possibly in different functions or classes. Possibly in different files or compilation units. Possibly communicating only via least-common-denominator daastructures common to both A and B in the base language. (E.g. no B datastructures accessible to A, or vice versa.) But possibly, occasionally, expressing the datastructures of B in a form accessible to the base language, so that A can manipulate them. I have a dream: * New languages, yes * But no more gratuitous invention of new languages * New languages for the new stuff only |