[Beowulf] cluster softwares supporting parallel CFD computing

Patrick Geoffray patrick at myri.com
Fri Sep 8 22:19:43 PDT 2006

Hi Eric,

Eric W. Biederman wrote:
> On the other hand it is my distinction impression the reason there is no
> opportunity cost from polling is that the applications have not been
> tuned as well as they could be.  In all other domains of programming
> synchronous receives are serious looked down upon.  I don't know why
> that should not apply to MPI codes as well.

In MPI, things are a bit different than the Sockets world or in the 
kernel: you usually don't oversubscribe your processors, so a process 
can be a pig and not feel bad about it.

Overlapping communication and computation does not make your code more 
complex. There is nothing complex into splitting each send or receive 
into an initiation and a completion steps, and everything in between 
could be overlapped. Alas, people use blocking calls in general because 
they are lazy (50%), they don't know (40%) or they don't care (10%). 
There is also the chicken and egg problem: nobody really tried to 
overlap, so MPI implementations didn't bother to support it, so you 
could not really overlap, so nobody really tried. However, some MPI 
implementations can overlap today and some applications can leverage it.

The best and only way to have MPI applications do the right thing would 
be to remove all blocking calls in MPI :-)

> My basic problem with the original statement was that it said
> interrupts kill latency when in fact I don't believe they make a
> high performance interconnect anywhere near as bad as ethernet,

What's bad with Ethernet ? 10-Gigabit Ethernet is an high performance 
interconnect. You don't have to use interrupts with Ethernet, you don't 
have to use TCP.

> and if used judiciously I believe interrupts could be used to improve
> system throughput, and to not confuse everything else in the system
> that assumes I/O bound applications sleep.

I totally agree, and interrupt coalescing is a wonderful thing.

Patrick Geoffray
Myricom, Inc.

More information about the Beowulf mailing list