Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!sun-barr!lll-winken!vette!brooks
From: brooks@vette.llnl.gov (Eugene Brooks)
Newsgroups: comp.arch
Subject: Re: parallel systems
Message-ID: <36597@lll-winken.LLNL.GOV>
Date: 23 Oct 89 17:01:04 GMT
References: <35825@lll-winken.LLNL.GOV> <20336@princeton.Princeton.EDU> <7651@bunny.GTE.COM> <1989Oct23.152120.25967@cs.rochester.edu>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: brooks@maddog.llnl.gov (Eugene Brooks)
Organization: Lawrence Livermore National Laboratory
Lines: 18

In article <1989Oct23.152120.25967@cs.rochester.edu> crowl@snipe.cs.rochester.edu (Lawrence Crowl) writes:
>SHARED MEMORY IS DESIREABLE.  The latency on remote memory access is typically
>two orders of magnitured faster than message passing on distributed memory.
Given equivalent performance interconnect, which rarely occurs because the
message passing machines tend to get short changed on the communication hardware,
I have found the "shared memory" systems to have much better communication
performance.  This is because the communication between processors is
directly supported in the memory management hardware.  In the message passing
machines sending a message invokes a "kernel call" on both the sending and
recieving ends.  This system call overhead is much greater than the hardware
latency itself, ammounting to a factor 5 or more.  One could try for complex
hardware support of messaging, but a better solution is to just memory map it...

Please note:  I am not talking about the really horrible interrupt handling
of message forwarding here.  This only compounds a bad situation for kernel
overhead.

brooks@maddog.llnl.gov, brooks@maddog.uucp