Notes on two presentations by Gordon Bell ca. 1998
|
From: Eugene Miya on 24 Feb 2010 11:10 In article <nv6e57-raq2.ln1(a)ntp.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >> a quote misattributed to Cray (Ken Batcher said): >> a super turns a CPU bound problem into an I/O bound problem. > >It is interesting to note that the memory wall has made all modern >computers into supers Then I would assert that you don't see supers. Sure your laptop/iPhone runs faster than the ENIAC. That one might run out of applications which stress runtime doesn't mean those problems don't exist. >according to this rule: > >Flops are more or less free, only getting from/to memory decides your >effective speed. I have thought about ways of measuring this with program generators but w/o success. Managers wants short term tools for procurements. The number of researchers in performance is limited as is their time. The immediate audience wants a Y/N style decision based on buying. They can tolerate some scalars (ordered numbers with a context they can understand), but forget about 2-D and higher performance characterization spaces. >I guess that is one possible reason to remove the quote? I doubt that. The page has become shall we say political. I don't intend to maintain the page, merely watch it evolve. It gives me a sense how clueless people are. Really. It's become a poorly structured marketing/optimistic page. It's almost as bad as the wikipedia Usenet page (no money, has less marketing on it). I have to get back to real work. I just had some time to kill in a telecon. -- Looking for an H-912 (container).
From: Stefan Monnier on 24 Feb 2010 14:30 > 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.) Agreed, and that's why embedded DSLs (as used in Lisp and Haskell) make a lot of sense: you get to reuse all the infrastructure of the host/meta language and can concentrate on the actual parts that are specific to your specialized language. Stefan
From: "Andy "Krazy" Glew" on 25 Feb 2010 02:28 Andrew Reilly wrote: > On Tue, 23 Feb 2010 19:48:50 -0800, Andy \"Krazy\" Glew wrote: > >> So put that in a mini-language: > > You *really* want to play with the macro facilities in lisp or scheme. > > The fact that no one that you know is using them, even though they've > been around for dozens of years, doesn't mean that there's necessarily > anything wrong with them, only that not a large fraction of the > programming community has yet reached the level of sophistication to want > that sort of facility (and known how to get it.) > > Yes, you may be able to detect the enthusiasm of a newbie, but that > doesn't make me wrong. I'm quite familiar with these facilities. Overall, they are great, except (1) I think they have a fundamental problem with the distinction between macro-time and run-time. I.e. I think there is a problem with phases. (By the way, Perl, and I believe Python, also have such facilities to a greater or lesser degree.) (2) They haven't made it into wide use. Frankly, I suspect that part of the problem lies in the fact that they are Lisp or Perl. As an IETF member once said: <e> ... </e> does nothing you can't do with S-expressions. But S-expressions were around for decades, and did not take off, whereas HTML did.
From: Terje Mathisen "terje.mathisen at on 25 Feb 2010 08:07 Andy "Krazy" Glew wrote: > (By the way, Perl, and I believe Python, also have such facilities to a > greater or lesser degree.) Perl, just like Lisp, by default includes the compiler itself in any program, since you can call eval(...) on an arbitrary string. However, I suspect that most actual uses of this is similar to what I often do, and that is to use eval to wrap an expression which would always halt the program if it failed: With eval() that becomes a regular error return instead. > > (2) They haven't made it into wide use. Frankly, I suspect that part of > the problem lies in the fact that they are Lisp or Perl.' <BG> Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Eugene Miya on 19 Mar 2010 15:17
In article <32538b00-b169-408d-a3dc-39c75610b42b(a)g28g2000yqh.googlegroups.com>, Robert Myers <rbmyersusa(a)gmail.com> wrote: >On Feb 20, 12:35=A0pm, "Andy \"Krazy\" Glew" <ag-n...(a)patten-glew.net> >wrote: >> 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. Naw, mixed blessings. >That just about says it all. > >1. The people who buy and pay for "supercomputers" have little >understanding of the work-a-day world of the people who might want to >use them. They have even less understanding of where the science is. Oh yeah? Maybe pay. >2. No one designs supercomputers any more. People design networks, Oh yeah? Then, you are in the wrong circles. >where, no matter the rhetoric, the burden is on the work-a-day user to >worry about where things *actually* are and cache (and associated >mindlessly-repeated truisms) has left its costly, indelible mark. Systems people do design networks and caches. That's true. Bureaucratic entities have to justify their clusters, and those are argued for as supercomputers, but they have competition. Pay to play. >Given those ugly realities, I think it's time for the US taxpayer to >get out of the business of paying for "supercomputers," which are no >more a supercomputer than this desktop (Core i7 920). That's merely commodity. You don't even have the right vendors. If you are unable to ID your target, you won't hit it. You're in one community. -- Looking for an H-912 (container). |