Messages in this thread | | | Date | Mon, 15 Jun 1998 13:29:43 +0330 | From | mshar@vax ... | Subject | Re: Remote fork() and Parallel programming |
| |
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
| |