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.
71 строка
3.1 KiB
Bash
71 строка
3.1 KiB
Bash
# -*- shell-script -*-
|
|
#
|
|
# 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$
|
|
#
|
|
|
|
# Example op component configure.m4 file. This file is slurped in by
|
|
# Open MPI's autogen.sh to be part of the top-level configure script.
|
|
# This script must define (via AC_DEFUN) an m4 macro named
|
|
# MCA_<framework>_<component>_CONFIG that executes either $1 if the
|
|
# component wants to build itself, or $2 if the component does not
|
|
# want to build itself.
|
|
|
|
# Do *NOT* invoke AC_MSG_ERROR, or any other macro that will abort
|
|
# configure, except upon catastrophic error. For example, it *is* a
|
|
# catastropic error if the user specifically requested your component
|
|
# but it cannot be built. If it *not* a catastropic error if your
|
|
# component cannot be built (but was not specifically requested).
|
|
|
|
# See https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent
|
|
# for more details on how to make Open MPI components.
|
|
|
|
# MCA_op_example_CONFIG([action-if-found], [action-if-not-found])
|
|
# -----------------------------------------------------------
|
|
AC_DEFUN([MCA_op_example_CONFIG],[
|
|
|
|
# Add checks here for any necessary header files and/or libraries
|
|
# that must be present to compile your component.
|
|
|
|
# This example performs a fairly simple test (checking for the
|
|
# "struct sockaddr_in" C type), just for the sake of showing you
|
|
# one test and executing either $1 or $2, depending on the output
|
|
# of the test.
|
|
|
|
# check for sockaddr_in (a good sign we have TCP)
|
|
AC_CHECK_TYPES([struct sockaddr_in],
|
|
[$1],
|
|
[$2],
|
|
[AC_INCLUDES_DEFAULT
|
|
#ifdef HAVE_NETINET_IN_H
|
|
#include <netinet/in.h>
|
|
#endif])
|
|
|
|
# Let's pretend that we found version A.B.C of the "libfoo"
|
|
# support library that is necessary to compile/link this
|
|
# component. We'll AC_DEFINE the A, B, and C values so that they
|
|
# can be printed as information MCA parameters via ompi_info. See
|
|
# op_example_component.c to see how these values are used.
|
|
|
|
AC_DEFINE_UNQUOTED(OP_EXAMPLE_LIBFOO_VERSION_MAJOR, ["17"],
|
|
[Major version number of the "libfoo" library])
|
|
AC_DEFINE_UNQUOTED(OP_EXAMPLE_LIBFOO_VERSION_MINOR, ["38"],
|
|
[Minor version number of the "libfoo" library])
|
|
AC_DEFINE_UNQUOTED(OP_EXAMPLE_LIBFOO_VERSION_RELEASE, ["4"],
|
|
[Release version number of the "libfoo" library])
|
|
])dnl
|