4d8a187450
* New "op" MPI layer framework * Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2) = Op framework = Add new "op" framework in the ompi layer. This framework replaces the hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples for pre-defined MPI_Ops, allowing components and modules to provide the back-end functions. The intent is that components can be written to take advantage of hardware acceleration (GPU, FPGA, specialized CPU instructions, etc.). Similar to other frameworks, components are intended to be able to discover at run-time if they can be used, and if so, elect themselves to be selected (or disqualify themselves from selection if they cannot run). If specialized hardware is not available, there is a default set of functions that will automatically be used. This framework is ''not'' used for user-defined MPI_Ops. The new op framework is similar to the existing coll framework, in that the final set of function pointers that are used on any given intrinsic MPI_Op can be a mixed bag of function pointers, potentially coming from multiple different op modules. This allows for hardware that only supports some of the operations, not all of them (e.g., a GPU that only supports single-precision operations). All the hard-coded back-end MPI_Op functions for (MPI_Op, MPI_Datatype) tuples still exist, but unlike coll, they're in the framework base (vs. being in a separate "basic" component) and are automatically used if no component is found at runtime that provides a module with the necessary function pointers. There is an "example" op component that will hopefully be useful to those writing meaningful op components. It is currently .ompi_ignore'd so that it doesn't impinge on other developers (it's somewhat chatty in terms of opal_output() so that you can tell when its functions have been invoked). See the README file in the example op component directory. Developers of new op components are encouraged to look at the following wiki pages: https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework = MPI_REDUCE_LOCAL = Part of the MPI-2.2 proposal listed here: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24 is to add a new function named MPI_REDUCE_LOCAL. It is very easy to implement, so I added it (also because it makes testing the op framework pretty easy -- you can do it in serial rather than via parallel reductions). There's even a man page! This commit was SVN r20280.
82 строки
2.7 KiB
Makefile
82 строки
2.7 KiB
Makefile
#
|
|
# Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
# University Research and Technology
|
|
# Corporation. All rights reserved.
|
|
# Copyright (c) 2004-2005 The University of Tennessee and The University
|
|
# of Tennessee Research Foundation. All rights
|
|
# reserved.
|
|
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
# University of Stuttgart. All rights reserved.
|
|
# Copyright (c) 2004-2005 The Regents of the University of California.
|
|
# All rights reserved.
|
|
# Copyright (c) 2008-2009 Cisco Systems, Inc. All rights reserved.
|
|
# $COPYRIGHT$
|
|
#
|
|
# Additional copyrights may follow
|
|
#
|
|
# $HEADER$
|
|
#
|
|
|
|
# This is an example op component. This Makefile.am is a typical
|
|
# example of how to integrate into Open MPI's Automake-based build
|
|
# system.
|
|
#
|
|
# See https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent
|
|
# for more details on how to make Open MPI components.
|
|
|
|
# First, list all .h and .c sources. It is necessary to list all .h
|
|
# files so that they will be picked up in the distribution tarball.
|
|
|
|
sources = \
|
|
op_example.h \
|
|
op_example_component.c \
|
|
op_example_module_bxor.c \
|
|
op_example_module_max.c
|
|
|
|
# Open MPI components can be compiled two ways:
|
|
#
|
|
# 1. As a standalone dynamic shared object (DSO), sometimes called a
|
|
# dynamically loadable library (DLL).
|
|
#
|
|
# 2. As a static library that is slurped up into the upper-level
|
|
# libmpi library (regardless of whether libmpi is a static or dynamic
|
|
# library). This is called a "Libtool convenience library".
|
|
#
|
|
# The component needs to create an output library in this top-level
|
|
# component directory, and named either mca_<type>_<name>.la (for DSO
|
|
# builds) or libmca_<type>_<name>.la (for static builds). The OMPI
|
|
# build system will have set the
|
|
# OMPI_BUILD_<framework>_<component>_DSO AM_CONDITIONAL to indicate
|
|
# which way this component should be built.
|
|
|
|
if OMPI_BUILD_op_example_DSO
|
|
lib =
|
|
lib_sources =
|
|
component = mca_op_example.la
|
|
component_sources = $(sources)
|
|
else
|
|
lib = libmca_op_example.la
|
|
lib_sources = $(sources)
|
|
component =
|
|
component_sources =
|
|
endif
|
|
|
|
# Specific information for DSO builds.
|
|
#
|
|
# The DSO should install itself in $(pkglibdir) (by default,
|
|
# $prefix/lib/openmpi).
|
|
|
|
mcacomponentdir = $(pkglibdir)
|
|
mcacomponent_LTLIBRARIES = $(component)
|
|
mca_op_example_la_SOURCES = $(component_sources)
|
|
mca_op_example_la_LDFLAGS = -module -avoid-version
|
|
|
|
# Specific information for static builds.
|
|
#
|
|
# Note that we *must* "noinst"; the upper-layer Makefile.am's will
|
|
# slurp in the resulting .la library into libmpi.
|
|
|
|
noinst_LTLIBRARIES = $(lib)
|
|
libmca_op_example_la_SOURCES = $(lib_sources)
|
|
libmca_op_example_la_LDFLAGS = -module -avoid-version
|