openmpi/ompi/mca/coll/sync/.windows

#
# Copyright (c) 2008-2010 High Performance Computing Center Stuttgart, 
#                         University of Stuttgart.  All rights reserved.
# $COPYRIGHT$
# 
# Additional copyrights may follow
# 
# $HEADER$
#

# Specific to this module
mca_link_libraries=libmpi libopen-rte
Add "sync" collective component. This component is totally deactivated by default. It is activated by setting either of the following two MCA parameters to values greater than 0: * coll_sync_barrier_before * coll_sync_barrier_after If !_before is >0, then the sync coll collective will insert itself before the underlying collective operations and invoke a barrier before every Nth barrier (N == coll_sync_barrier_before). Similar for !_after. Note that N is a _per communicator_ value; not global to the MPI process. If both are 0 (which is the default), this component returns NULL for the comm query, meaning that it is not insertted into the coll module stack. The intent of this component is to provide a a workaround for applications with large numbers of collectives of short messages that can cause unbounded unexpected messages. Specifically, it is possible for some iterative collective communication patterns to cause unbounded unexpected messages. Forcing a barrier before or after every Nth collective operation would prevent that behavior by forcing applications to synchronize (and thereby consume any outstanding unexpected messages caused by collectives on the same communicator). Open MPI still needs to bound unexpected messages resource consumption at the receiver, but this is a viable workaround for at least some symptoms of the problem. Additionally, there has been anecdotal evidence of some applications that "perfom better" when they put barriers after other collective operations. This could be due to many factors -- including shortening the unexpected message queue. Putting this component in Open MPI allows people to try this with their own applications and give real world feedback on this kind of behavior. This commit was SVN r20584. 2009-02-19 02:32:44 +03:00			`#`
Fix the bug that caused by ADD_DEPENDENCIES() from different version of CMake. In CMake 2.6 and earlier, this function add dependencies for targets and also link the target libraries automatically, but in CMake 2.8,this behavior has been changed, i.e. it will only add the dependencies but no link, which will cause linking errors at compilation time. This commit was SVN r22405. 2010-01-14 21:10:20 +03:00			`# Copyright (c) 2008-2010 High Performance Computing Center Stuttgart,`
Add "sync" collective component. This component is totally deactivated by default. It is activated by setting either of the following two MCA parameters to values greater than 0: * coll_sync_barrier_before * coll_sync_barrier_after If !_before is >0, then the sync coll collective will insert itself before the underlying collective operations and invoke a barrier before every Nth barrier (N == coll_sync_barrier_before). Similar for !_after. Note that N is a _per communicator_ value; not global to the MPI process. If both are 0 (which is the default), this component returns NULL for the comm query, meaning that it is not insertted into the coll module stack. The intent of this component is to provide a a workaround for applications with large numbers of collectives of short messages that can cause unbounded unexpected messages. Specifically, it is possible for some iterative collective communication patterns to cause unbounded unexpected messages. Forcing a barrier before or after every Nth collective operation would prevent that behavior by forcing applications to synchronize (and thereby consume any outstanding unexpected messages caused by collectives on the same communicator). Open MPI still needs to bound unexpected messages resource consumption at the receiver, but this is a viable workaround for at least some symptoms of the problem. Additionally, there has been anecdotal evidence of some applications that "perfom better" when they put barriers after other collective operations. This could be due to many factors -- including shortening the unexpected message queue. Putting this component in Open MPI allows people to try this with their own applications and give real world feedback on this kind of behavior. This commit was SVN r20584. 2009-02-19 02:32:44 +03:00			`# University of Stuttgart. All rights reserved.`
			`# $COPYRIGHT$`
			`#`
			`# Additional copyrights may follow`
			`#`
			`# $HEADER$`
			`#`

			`# Specific to this module`
Restore several linked libraries that were deleted by mistake in r22405. This commit was SVN r22415. The following SVN revision numbers were found above: r22405 --> open-mpi/ompi@872a4047ba0532c0ea45d7b2137918e8dc640aa5 2010-01-15 00:50:42 +03:00			`mca_link_libraries=libmpi libopen-rte`