Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!ogicse!emory!hubcap!bbc From: bbc@rice.edu (Benjamin Chase) Newsgroups: comp.parallel Subject: Re: terminology (again) 8) <- see I do wear glasses Message-ID: <9246@hubcap.clemson.edu> Date: 7 Jun 90 17:18:52 GMT Sender: fpst@hubcap.clemson.edu Lines: 26 Approved: parallel@hubcap.clemson.edu In article <9238@hubcap.clemson.edu> art@cs.bu.edu (Al Thompson) writes: >I do, which is why I cited the Stone definition. He doesn't refer to >synchronization at all. He defines the grain as a ratio of a run-time >quantum to a communication cost. Now I'll admit it doesn't take a huge >leap to imply synch from that, but he does avoid explicitly mentioning it. The problem I have with this definition is that "grain size" then becomes architecture dependent. If communication (eg. synchronization) is poorly implemented (or cannot be implemented efficiently on a particular architecture) and hence has a high cost, then a grain in the "fine grain" world contains more instructions on this system. If we're voting on the meaning for this particular collection of terms, I would rather that the size of the grain be keyed on something like the number of instructions within a grain. I feel that this definition will prove more timeless than the other, as hardware and software evolve. In years to come, we won't find the need for ultra-hyper-micro-fine grain, because an obvious lower limit for instructions/syncronization is 1. Also, with this choice of definition, we find that some architectures (eg. loosely-coupled) are inappropriate for fine-grain concurrency. With the other definition, we instead find that the fine grains on some architectures are in fact quite coarse... -- Ben Chase , Rice University, Houston, Texas