[OMPI devel] heterogeneous support
I just noticed that heterogeneous MPI support is enabled by default. Do we really want this? Doesn't it add a little overhead (probably noticeable on shared memory)? I'd be comfortable with users specifically having to enable heterogeneous support via configure and having [slightly] better out- of-the-box performance for the common (homogeneous) case. -- Jeff Squyres Cisco Systems
Re: [OMPI devel] heterogeneous support
On Thu, 5 Jun 2008, Jeff Squyres wrote: I just noticed that heterogeneous MPI support is enabled by default. Do we really want this? Doesn't it add a little overhead (probably noticeable on shared memory)? I'd be comfortable with users specifically having to enable heterogeneous support via configure and having [slightly] better out- of-the-box performance for the common (homogeneous) case. I think it was initially on by default because we didn't have a good way of detecting that the job was heterogeneous when that was setup. I believe we do now, so it probably makes sense to change the default. Brian
Re: [OMPI devel] heterogeneous support
Good call -- I just checked ompi/proc/proc.c and we *do* check. If you start a heterogeneous job and we don't have support for it, we show_help and barf. I'll change the default tonight. On Jun 5, 2008, at 4:53 PM, Brian W. Barrett wrote: On Thu, 5 Jun 2008, Jeff Squyres wrote: I just noticed that heterogeneous MPI support is enabled by default. Do we really want this? Doesn't it add a little overhead (probably noticeable on shared memory)? I'd be comfortable with users specifically having to enable heterogeneous support via configure and having [slightly] better out- of-the-box performance for the common (homogeneous) case. I think it was initially on by default because we didn't have a good way of detecting that the job was heterogeneous when that was setup. I believe we do now, so it probably makes sense to change the default. Brian ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] some Makefile.am questions
On Jun 4, 2008, at 5:15 PM, Ralf Wildenhues wrote: 1) This is from test/Makefile.am: --- snip --- # This should be libsupport.a, not libsupport.la. Automake doesn't # support check_LTLIBRARIES, as technically you have to install a # shared library before you can use it. # check_LIBRARIES = libsupport.a libsupport_a_SOURCES = \ --- snip --- The statement in the comment is not true; Automake supports check_LTLIBRARIES, and they don't have to be installed before use either. What may be confusing is that, by default, check_LTLIBRARIES will be convenience archives rather than shared libraries. If you want to have an uninstalled shared library for testing, then you can use check_LTLIBRARIES = libsupport.la # induce libtool to create a shared library: libsupport_la_LDFLAGS = -rpath /nowhere libsupport_la_SOURCES = \ ... Ah, good to know. Other than the comment being wrong, is this a problem? 2) test/dss/ has only a Makefile with 'CC = mpicc' hardcoded. That looks like it won't use the correct (uninstalled) mpicc but requires a prior 'make install'. Not sure whether that's intentional. It is actually; these tests are always manually created by a developer. Our "make check" framework is not very complete. Maybe someday... 3) in opal/mca/paffinity/linux/plpa/src/plpa-taskset/Makefile.am, there are some manual dependencies listed that should not be necessary, as Automake should treat bison/yacc generated files correctly. IOW, the patch below, which simplifies things slightly, should still generate a functional Makefile. If it doesn't, I'd like to hear about it (because that could be an Automake bug). Thanks -- fixed! (I'm not sure why there were there to begin with) -- Jeff Squyres Cisco Systems
