Why so little parallelism?
|
From: Eugene Miya on 15 Dec 2006 12:11 >> My point is that this is the exactly wrong way to go about it. Rather than >> hope the compiler will do the right thing, you should be able to write the >> code in such a way that the compiler understands that it is expected to >> parallelize the loop in a particular way (or better, if that can be defined >> "objectively") and that it's a bug in the source code if it can't. Writing is merely a notation. While I would not overload the word loop, the problem is the data structure. "Oh the elephant is like a wall...." In article <4ua7jjF17dupaU1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >Then I don't need a compiler any more. And I will end up with brittle code, >i.e., code that works well on one incarnation of a certain system and be >abysmal on a (perhaps only slightly) different one. "Our current state". But, I would not use the word well. >I'm all for giving my tools a helping hand in providing as much information to >them as possible, in the form of annotations or whatever. What I don't want to >do is to make premature decisions that are not required: and serialising an >array expression is an example for such a premature decision, because there >might be a different execution of that expression that is better for the >system in hand. I regard this as a stepping stone. It's OK for now. We want to do better. --
From: Anne & Lynn Wheeler on 15 Dec 2006 13:56 eugene(a)cse.ucsc.edu (Eugene Miya) writes: > Sure. Your major funding organization makes business machines, not > research machines. > > It merely happens that it has 3 things it chose to name Research Centers > and a number of lesser "Science" centers and similarly acronymed > facilities. the major funding organization for RP3 was not the business machine unit ... this particular organization had been responsible for a lot of machines used in various gov. operations.
From: Anne & Lynn Wheeler on 15 Dec 2006 13:59 eugene(a)cse.ucsc.edu (Eugene Miya) writes: > I sat in on Greg Pfister's presentation at SJ RC (with numerous people > outside IBM like DEC). Sounded like an interesting case study in O(N lg n) > interconnection architectures like the NYU Ultracomputer. Then one of > your employees asked the question about whether the RP3 would be > instruction set compatible with the 370-line (he clearly had not been > listening to the earlier CPU portion of the talk but also aligned with > the pre-PC mainframe mind set). But that's history. > > Later when we were approached to buy one, gee that's over 20 years ago, > and unlike most NDAs that I've signed, IBM is still in existence. > Anyways, it was your choice. You guys don't have research in your names. > > Other than Greg's book, I only hope we can preserve history, > as opposed to economic revisionism. What's left of the hardware, what > ever is left except for the cited RIOS, is on the East Coast. my wife's analysis of RP3 had nothing to do with 370 instruction set compatibility ... it had more to do with whether it could really achieved the scaleup being claimed .... especially in the (mostly federal) gov. market segment. i haven't tried to do either ... i've just presented actual email exchanges from the period.
From: Anne & Lynn Wheeler on 15 Dec 2006 14:20 eugene(a)cse.ucsc.edu (Eugene Miya) writes: > I sat in on Greg Pfister's presentation at SJ RC (with numerous people > outside IBM like DEC). Sounded like an interesting case study in O(N lg n) > interconnection architectures like the NYU Ultracomputer. Then one of > your employees asked the question about whether the RP3 would be > instruction set compatible with the 370-line (he clearly had not been > listening to the earlier CPU portion of the talk but also aligned with > the pre-PC mainframe mind set). But that's history. re: http://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism? http://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism? http://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism? and with regard to even statement about 128 processor configuration discussed here in a meeting in ellison's conference room http://www.garlic.com/~lynn/95.html#13 http://www.garlic.com/~lynn/96.html#15 here is greg pfister's comment in old post/thread that ran in comp.arch, comp.sys.super, alt.folklore.computers http://www.garlic.com/~lynn/2000c.html#21 Cache coherence [as re: TF-1] Greg Pfister writes: > I never heard anybody say 128-way, and I was somewhat in the > middle of this. What I saw was that it was always intended as an > SMP replacement (yes, SMP, don't ask, some people's heads were in > a strange place then). The software bill, not the hardware, was > always the sticking point. Anyway, the SP became by definition > the "right" solution, and Live Oak was not resurrected again. .... snip ... more in that same thread http://www.garlic.com/~lynn/2000c.html#22 Cache coherence [as re: TF-1] the cluster-in-a-rack/medusa was 32 processors in a rack ... and the discussion in the meeting in ellison's conference room was to have four rack operation (128 processors) in customer shops by ye92. this was before the project got transferred to kingston and we were told we couldn't work on systems with more than four processors. a couple recent postings with old email discussing medusa and cluster-in-a-rack http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack misc. other posts mentioning RP3 http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?) http://www.garlic.com/~lynn/2000c.html#6 TF-1 http://www.garlic.com/~lynn/2000d.html#27 Superduper computers--why RISC not 390? http://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design
From: Anne & Lynn Wheeler on 15 Dec 2006 15:06
Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > more in that same thread > http://www.garlic.com/~lynn/2000c.html#22 Cache coherence [was re: TF-1] re: http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism? http://www.garlic.com/~lynn/2000c.html#21 Cache coherenece [was re: TF-1] oh and Pfister's comment was in response to this posting earlier in the thread http://www.garlic.com/~lynn/2000c.html#12 Cache coherenece [was re: TF-1] from above post: Anne & Lynn Wheeler <lynn(a)garlic.com> writes: > part of the issue was that we could demonstrate 16-way and quick path > to 128-way (and above) using standard existing chips & motherboards > with interconnect fabric (even demonstrate interconnect fabric on > existing workstations in racks ... but some additional manufacturing > cost savings by packaging standard mother boards for high-density rack > mounting ... racks had to have some cooling characteristics to achieve > the high-density packaging of the mother boards). aka cluster-in-a-rack/medusa http://www.garlic.com/~lynn/2006w.html#13 IBM sues make of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006w.html#14 IBM sues make of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack and Greg's response from: http://www.garlic.com/~lynn/2000c.html#21 Cache coherence [as re: TF-1] Greg Pfister writes: > I never heard anybody say 128-way, and I was somewhat in the > middle of this. What I saw was that it was always intended as an > SMP replacement (yes, SMP, don't ask, some people's heads were in > a strange place then). The software bill, not the hardware, was > always the sticking point. Anyway, the SP became by definition > the "right" solution, and Live Oak was not resurrected again. for other drift ... in one of the recent postings referencing cluster-in-a-rack/medusa http://www.garlic.com/~lynn/2006w.html#14 IBM sues make of Intel-based Mainframe clones i also mentioned at having looked at doing (relatively) high density processor packaging in racks (for the times) in 1985 http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor |