Re: Remote fork() and Parallel programming

mshar@vax.ipm.ac.ir
Mon, 15 Jun 1998 13:29:43 +0330


Hi,

lm@bitmover.com (Larry McVoy) wrote:

>It's not the bandwidth that's the issue, it's the latency. Bandwidth is
>easy. Latency is hard. DSM systems /all/ die because of latency issues.

The main argument of anti-DSM people has always been the band-width (that
message passing can better use the bandwidth because the programmer has
total control over the transfers and can tune the program's behaviour), but
fortunately that is no longer important.

>It is my claim that 100% of the DSM systems cn be proven to be a bad idea
>if the designers had sat down and measured the local versus remote memory
>latency. Numbers talk. And DSM numbers just show you that it isn't a
>very useful idea.

Wrong argument. One encounters the latency problem _each_ time one transfers
data over a network, no matter what the programmer does to initiate this
transfer. The DSM and message passing argument is more about programming
interfaces. The latency will not decrease if the programmer uses messages (or
_any_ other method) to transfer 4KB of data to another computer.

The only solution is to refrain from transfering data over a network, but
some people don't think this is a good idea. Now the main problem is the
programming interface: Message passing is no where comparable to DSM in
ease of use.


-Kamran Karimi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu