curtiss@mimsy.umd.edu (Phil Curtiss) (12/18/89)
One of the projects going on at the Institute is the design of a parallel benchmarking suite that, [1] is portable to many different types of parallel processing machines of different architectures, [2] is easily configurable to make use of some of the more exotic parallel constructs employed in many of the programming environments that try and make efficient use of the hardware of these machine. As a first step, I would like to know if there exists any benchmarking software that already exists for any kind of machine that could be construed as processing in parallel. If you know of any package and where I could get a hold of either, [1] the software package itself, [2] some papers on the package or some theory papers, [3] or all of the above, that would be most helpful and I would be most appreciative. If there is enough interest I would be more than willing to post a summary. Also, if anyone wants to know what kind of information I get just let me know and I shall keep you informed as I get responses. Thanks in advance to all those that respond. Tah. Phil! -- Domain: curtiss@umiacs.umd.edu Phillip Curtiss UUCP: uunet!mimsy!curtiss UMIACS - Univ. of Maryland Phone: +1-301-454-7687 College Park, Md 20742
grunwald@ncar.UCAR.EDU (Dirk Grunwald) (12/19/89)
I'd think that the ``Perfect Club'' benchmark has already done this; I'm not certain who to contact, perhaps someone at Argonne or CSRD? Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu) (grunwald@boulder.colorado.edu)
cline@cheetah.ece.clarkson.edu (Marshall Cline) (12/20/89)
In article <7481@hubcap.clemson.edu> curtiss@mimsy.umd.edu (Phil Curtiss) writes: > One of the projects going on at the Institute is the design of a > parallel benchmarking suite that, > [1] is portable to many different types of parallel processing > machines of different architectures, > [2] is easily configurable to make use of some of the more > exotic parallel constructs employed in many of the > programming environments that try and make efficient use of > the hardware of these machine. ... > Phil! I know you're interested in this from a benchmark/speed-analysis perspective. The software engineering/portability aspect of this problem is most facinating to me. There's an *inherent* problem here -- our parallel programs are almost always machine *dependent*, using constructs and operations where are specific to a particular vendor. Unfortunately, machine language isn't usually hailed as the ideal language for sound software engineering :-). There are other aspects (such as the number of operators per line and other psychological aspects of programming), but non-portability is certainly *one* of the reasons ASM is no good for programming in-the-large. So what do we do? Practioners use parallel machines for essentially one and only one reason: raw unadulterated speed. Practioners don't use parallel machines because they make programming *easier* or less error prone -- indeed these things are sacrificed in measure! They want *POWER*! Can we have our cake and eat it too? Classical SE has basically said, "No, but we don't care, because your payroll is far more expensive than your CPU cycles." Generally they're (we're) right -- reducing the *human* cost of the maintenance phase is generally a big win. But what do we do with parallel machines? We go back to square one. Solutions anyone? Finding bottlenecks and tuning them with assembly language is common practice. Is there anything analogous in parallelism? To me, the problem is that the classical "bottleneck" is usually a small piece of code (what's the rule? 80% of the time in 20% of the code? Something like that). Anyway the parallelism is usually expressed in a *big* piece of the code -- it's often the problem as a *whole*... Another problem: parallel algorithms are almost always tunable to particular machine architectures. Ex: you want 2 PEs which often chat with each other ("friends"?) to be *physically* close on a hypercube arch, etc ad nauseum (sp?). Thus the very idea of benchmarking with portable parallel programs inherits the full brunt of the above mentioned tension. If you want portability, it appears that you *need* to sacrifice a certain degree of what the parallelism could buy you. It seems to me that this is an open research question which I for one am very interested in. Ex: economists have a graph which shows how unemployment and inflation are tradeoffs -- you can't make them both really small simultaneously. It would be fun to try to come up with the same sort of graph for our field. Ie: can we *quantify* portability? Ex: can we assign it a numeric value from 0 to 1? Can we do the same with speed, perhaps using "the percentage of what the parallel machine is capable of"? If we could, then we'd have a law that says the product of the two is always less than 0.7 or whatever. Sound like fun anyone? Linda appears to be a solution for MIMD and distributed environments (which is a substantial accomplishment, I might add, since that represents a *big* chunk of the parallel/distrib world). But what about something even more general? There was an article last May's IEEE-Software-Eng on "Molecule: A Language Construct for Layered Development of Parallel Programs". I really ate it up, and I suggested "we-all" dialog on the subject, but there were very few takers. May be someone is interested in the subject now? Molecule, you'll perhaps recall, is a language construct pretty much analogous to a "procedure". However you can specify properties of a molecule which let the compiler know how to parallelize it. The end result is that a molecule-izer compiler can translate a source module of molecules into *any* parallel environment. The list the authors gave was very broad, encompassing both SIMD arrays and MIMD's, in all configurations (shared vs distrib memory, coarse vs fine grained parallelism, etc). Marshall -- ___________________________________________________________________ Marshall Cline/ECE Dept/Clarkson Univ/Potsdam NY 13676/315-268-3868 Internet: cline@sun.soe.clarkson.edu -or- bh0w@clutx.clarkson.edu BitNet: bh0w@clutx Usenet: uunet!sun.soe.clarkson.edu!cline