Re: Remote fork() and Parallel Programming

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Sat, 13 Jun 1998 22:55:43 +0200 (MET DST)


On Sat, 13 Jun 1998 mshar@vax.ipm.ac.ir wrote:
> lm@bitmover.com (Larry McVoy) wrote:
>
> >: As I see things, distributed programming should not be (very) different from
> >: programming a single computer. [etc].
> >
> The most important thing is to see that I have no special category of
> applications as my target. ___ANY___ application can benefit from a
> remote fork and process migration.

Nope. For a process to benefit from process migration, it
will need to do a relatively large amount of computation
and a small amount of I/O. Otherwise the overhead for moving
the stuff around will be larger than the gain made.

This is one of the reasons why properly written distributed
applications do the absolute minimum amount of I/O.
With today's processor cores and disproportionately slower
cache and memory, the motto for single node program optimization
is already something like "Avoid I/O at all cost". This I/O
also includes cache misses and memory accesses!

You can imagine that, even with gigabit ethernet, the network
latency will just kill a lot of applications that still work
reasonably well on a single node. For a multinode environment
things will get even worse...

That's why good distributed apps look nothing like your
desktop app (which still has algorithms from the i386
days, when table lookups still _were_ faster than some
calculation).

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

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