Hi Jeff I am using OMPI on a MacBook Pro (for the moment).
What's "extremely slowly", and what does your test program do?
For example, test programs of Zoltan (load balancing library from sandia) never finish, while normally
they take a fraction of second to finish.
By "asynchronous progress", do you mean that you used the --enable- progress-threads option to OMPI's configure, or that you are using non-blocking MPI function calls?
I meant using --enable-progress-threads. When disabled - doesn't it mean that block and non-blocking communication are basically same (and blocking)? (at least on a gigabit ethernet TCPIP based network)
I'd say that the progress threads stuff in OMPI is immature at best. At worst, it may crash. It's likely very untested.
Yes, I could see that myself.
The non-blocking function calls should work just as well as the blocking function calls -- depending on your application, hardware, communication patterns, etc., you can get significant speedup by using the non-blocking communication calls.
I am not very knowledgeable in terms of networking, but is gigabit ethernet/TCPIP capable of asynchronous comm?
FWIW, some types of networks effectively have asynchronous progress anyway (which is one of the reasons we haven't done too much on the OMPI software side of enabling async. progress). If your network has hardware (or software) offload of message passing, then you might be getting it "for free" by OMPI's normal operating modes anyway. Note that asynchronous progress is typically most useful when sending large messages.
Will need to learn more and see on which from the available clusters should I be able to have good support for asynch. which is needed in my application.
