dwc@hou2b.UUCP (D.CHEN) (05/16/85)
i would like to throw in my two cents about this multiprocessor vs. uniprocessor business. my qualifications are: i have no experience with multiprocessors. my observation is that uniprocessors are not really uniprocessors at all (at least the fast ones). they are really made up of multiple functional units. these units might be rather specialized in function: multiplication, division, vector ops, instruction fetch, instruction decode, etc. each of these functional units can be considered a special purpose processor. and what makes these uniprocessors work well is that the functional units can be made to work at high utilization with some amount of synchronization (usually thru pipelining) for a large class of problems. one of the goals of risc architectures are that the compiler has an easier time to set up the pipelines so that these functional units are indeed kept busy with useful work. it seems that multiprocessors can be viewed as composed of functional units that can do more general functions. this being the case, the synchronization mechanisms must be more general and probably more expensive. shared memory multiprocessors incur the extra expense of coordinating access to the common memory and loosely coupled machines suffer from higher communications costs (in terms of time) but there ought to be a (perhaps large) class of problems that can be solved on multiprocessors where the synchronization overhead is low compared to the computation and the processors (functional units) are highly utilized. as far as programming the beasts, i think that this group is not a fair place to sample opinions. we have all been taught to think sequentially to solve problems because of the programming languages that we were taught early on. i think that its more natural to solve some problems non-sequentially (albeit fuzzily). danny chen ihnp4!hou2b!dwc