patrick@convex.COM (Patrick F. McGehearty) (06/27/91)
In article <1991Jun26.140913.1238@Arco.COM> dprcxm@marais.ARCO.COM (Chuck Mosher) writes: >The panel discussion featuring top executives from Cray, Convex, Intel, >and NCube was especially illuminating. Everybody's talking MPP. >Good news for us users. Talk and action are two different things. It took 10 years to go from talk of small scale multiprocessors (early 70's) to commercial availability at the high end (say Cray XMP for example). Of course, time to market pressures are greater today, and there are several examples currently on the market (i.e. Connection Machine and Touchstone). However, these appear (from what I have heard, no direct experience) to require substantial code/algorithm revisions to get anywhere near the potential of the machine. What is the opinion of the super community? Will most super applications be rewritten to make them more adaptable to massive parallelism? or Will special hand crafting for each target architecture continue to be needed to any kind of reasonable performance from MPP systems? If the applications will be rewritten, how long will it be before the revised versions are available? [Chicken and egg problem here: without machines and language features, where is the motivation to rewrite? Without applications, where is the motivation to provide the machines and language features?] A minor example of massive parallelism requirements concerns pseudo-random number generation. Many random number generators are sequential by design. (r(i) = a* r(i-1) + b) However, the desired mathematical properties can be obtained by having N parallel random streams: (r(i,j) = a*r(i-1,j) + b) for j = 1,..,N Then each of N threads of execution can generate repeatable pseudo-random numbers.
dprcxm@inetg1.ARCO.COM (Chuck Mosher) (06/27/91)
Massive parallelism is a difficult transition for us. We run IBM and Cray mainframes for a wide range of applications. Hundreds of users run database applications during the day, a few large number-crunching routines run at night. The large applications are targets for parallel processing. They are few enough in number that we can consider re-writing the codes from scratch for a particular architecture. So far, we have found that a different parallel decomposition and different language constructs are necessary for each architecture out there, so we have to go through a complete re-write for every machine we look at. We clearly need some standards. So, we re-write our codes, they run faster and cheaper on the XYZ box. But the XYZ box can't support our hundreds of users during the day, so we have to keep our IBM and Cray systems going. As a result, we can't afford the big XYZ box that will let us tackle the problems we can't solve today. We end up being able to utilize small parallel systems, but only on a departmental level. We need true multi-user support and good parallelizing compilers before we will be able to replace our big mainframes and get on to the grand challenges. -- ----+----1----+----2----+----3----+----4----+----5----+----6----+----7-- | Chuck Mosher | Internet : ccm@arco.com | Who needs an editor | | ARCO, Plano, TX | Telephone: (214)754-6468 | when you have ISPF? | ************************************************************************
eugene@nas.nasa.gov (Eugene N. Miya) (06/27/91)
In article <1991Jun26.184744.16948@convex.com> patrick@convex.COM (Patrick F. McGehearty) writes: >Will most super applications be rewritten to make them more adaptable >to massive parallelism? >or >Will special hand crafting for each target architecture continue to be >needed to any kind of reasonable performance from MPP systems? > >If the applications will be rewritten, how long will it be before >the revised versions are available? [Chicken and egg problem here: >without machines and language features, where is the motivation to >rewrite? Without applications, where is the motivation to provide >the machines and language features?] It is interesting that you did not get much response. You should get 60% of your responses in 24 hours. I think a lot of sites reel when they change machines. I am porting two codes right now for which the -cfc option isn't helping. Subtle semantic problems. Will apps. be re-written? Probably, but only enough to adapt them to one more architecture (at a time). The purpose (as you know) is to run the code, not to adapt it to every conceiveable computer. Special hand crafting? That's the tension. The attraction is speed. If you are not using it, then by some people's definition, "that's not efficient." You have the chicken-egg analogy down pat. A CM code won't run on a hypercube nor a shared-memory machine without modification. Frequently extensive mods. I think what will drive this will be academic competitiveness. A prof some where will go assign a grad student some CM or cube time, then come up with some new algorithm, for solving saying a problem. Colleagues will rush in and use it. THEY will have to make decisions what existing codes to drop. Some codes, very large, will be declared National resources, say like NASTRAN, and big efforts will be made to port those codes. The rest will fad away, perhaps to run on older, little-used machines sitting in corners, single CPU killer micros to older Crays I don't think you can put a technology based time frame on it. It will happen when a new advance in a field takes place. It will probably rendered graphically (we can guess this). We will see hype articles on events which will motivate colleagues to rush and get similar machines, maybe a vendor will get a brief burst of orders. Meanwhile we have to get vendors together and achieve consensus on language features. We may literally have to get vendors running each other's codes to get consistent language features. We also have to encourage applications users to come up with more small benchmarks, consensus again, which vendors can use as test cases. We teeth with toys. We must. In the time it takes some vendors to port a test application, a company may go out of business. That scares a lot of people because that is time wasted. Notables missing from the Trade Show: IBM Thinking Machines Others --eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov Resident Cynic, Rock of Ages Home for Retired Hackers {uunet,mailrus,other gateways}!ames!eugene