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.
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}