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 -- Patrick Geoffray Myricom, Inc. http://www.myri.com _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
