Path: utzoo!attcan!uunet!husc6!rutgers!iuvax!pur-ee!hankd From: hankd@pur-ee.UUCP (Hank Dietz) Newsgroups: comp.arch Subject: Re: Today's dumb question... Summary: Shared memory isn't a software issue to be solved Message-ID: <8104@pur-ee.UUCP> Date: 11 May 88 17:06:47 GMT References: <503@xios.XIOS.UUCP> <2676@pdn.UUCP> <674@cernvax.UUCP> Organization: Purdue University Engineering Computer Network Lines: 32 In article <674@cernvax.UUCP>, hjm@cernvax.UUCP (hjm) writes: > - shared-memory is not necessary; it's a software issue that shouldn't > be solved in hardware. Shared memory's full name is "shared memory address space" -- it means simply that some portion of the memory is addressible by more than one processor. In other words, it says that although memory may be physically distributed, and may have access times which depend on the physical structure as well as on bus/network traffic conditions, the WAY in which it is referenced appears as a conventional load/store on an address. The alternative is to create a MESSAGE which REQUESTS THAT SOMETHING ELSE REFERENCE the desired memory location. How do you create a message? Well, maybe a GET/PUT instruction or somesuch, but the key idea is that you're sending the message TO SOME ACTIVE ELEMENT, not to a memory address. As for which is better, because most message-passing systems only use messages to access non-local memory, one must distinguish between local and non-local references at compile-time to generate efficient code -- unfortunately, this is not always possible, and since the shared-memory model doesn't require this distinction be made at compile time, it is in some sense more powerful. The implementation difficulty usually depends on how you connect to memory: for word transfers, shared-memory is easier; for longer block transfers, messages are easier... for the obvious reasons. Shared memory DOES NOT MEAN CONSTANT ACCESS TIME independent of memory cell addressed -- if that's your "software" definition of shared-memory, forget it, because no highly-parallel machine will *ever* support that. Ok, maybe your software would still run if you wrote it with that assumption, but it ain't gonna run fast, and that is what parallel processing is all about. -hankd