2004-01-15 09:08:25 +03:00
|
|
|
/*
|
2010-03-13 02:57:50 +03:00
|
|
|
* Copyright (c) 2004-2010 The Trustees of Indiana University and Indiana
|
2005-11-05 22:57:48 +03:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2011-06-24 00:38:02 +04:00
|
|
|
* Copyright (c) 2004-2011 The University of Tennessee and The University
|
2005-11-05 22:57:48 +03:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
2004-11-28 23:09:25 +03:00
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
* University of Stuttgart. All rights reserved.
|
2005-03-24 15:43:37 +03:00
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
* Copyright (c) 2006-2012 Cisco Systems, Inc. All rights reserved.
|
2013-03-28 01:17:31 +04:00
|
|
|
* Copyright (c) 2006-2013 Los Alamos National Security, LLC. All rights
|
2006-11-22 05:06:52 +03:00
|
|
|
* reserved.
|
2009-07-07 22:32:14 +04:00
|
|
|
* Copyright (c) 2006-2009 University of Houston. All rights reserved.
|
2009-02-24 20:17:33 +03:00
|
|
|
* Copyright (c) 2008-2009 Sun Microsystems, Inc. All rights reserved.
|
2012-02-06 21:35:21 +04:00
|
|
|
* Copyright (c) 2011 Sandia National Laboratories. All rights reserved.
|
2012-06-27 05:28:28 +04:00
|
|
|
*
|
2004-11-22 04:38:40 +03:00
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
2004-01-15 09:08:25 +03:00
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
#include "ompi_config.h"
|
2004-01-15 09:08:25 +03:00
|
|
|
|
2006-09-29 17:19:44 +04:00
|
|
|
#ifdef HAVE_SYS_TIME_H
|
|
|
|
#include <sys/time.h>
|
|
|
|
#endif /* HAVE_SYS_TIME_H */
|
2009-07-16 22:27:33 +04:00
|
|
|
#ifdef HAVE_PTHREAD_H
|
2008-08-06 18:22:03 +04:00
|
|
|
#include <pthread.h>
|
|
|
|
#endif
|
2008-11-05 22:41:16 +03:00
|
|
|
#ifdef HAVE_UNISTD_H
|
|
|
|
#include <unistd.h>
|
|
|
|
#endif
|
2006-09-29 17:19:44 +04:00
|
|
|
|
2004-01-15 09:08:25 +03:00
|
|
|
#include "mpi.h"
|
2007-12-07 16:09:07 +03:00
|
|
|
#include "opal/class/opal_list.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "opal/mca/base/base.h"
|
2011-10-20 00:18:14 +04:00
|
|
|
#include "opal/mca/hwloc/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "opal/runtime/opal_progress.h"
|
|
|
|
#include "opal/threads/threads.h"
|
2013-01-15 05:27:36 +04:00
|
|
|
#include "opal/util/arch.h"
|
2013-04-29 21:02:37 +04:00
|
|
|
#include "opal/util/argv.h"
|
2009-02-14 05:26:12 +03:00
|
|
|
#include "opal/util/output.h"
|
2008-06-19 17:48:26 +04:00
|
|
|
#include "opal/util/error.h"
|
2005-07-04 06:38:44 +04:00
|
|
|
#include "opal/util/stacktrace.h"
|
2008-05-20 01:57:54 +04:00
|
|
|
#include "opal/util/show_help.h"
|
2005-07-03 16:07:29 +04:00
|
|
|
#include "opal/runtime/opal.h"
|
Update libevent to the 2.0 series, currently at 2.0.7rc. We will update to their final release when it becomes available. Currently known errors exist in unused portions of the libevent code. This revision passes the IBM test suite on a Linux machine and on a standalone Mac.
This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects.
Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems.
Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct.
I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things:
1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new)
2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it.
There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do.
This commit was SVN r23925.
2010-10-24 22:35:54 +04:00
|
|
|
#include "opal/mca/event/event.h"
|
2004-01-15 09:08:25 +03:00
|
|
|
|
2006-02-12 04:33:29 +03:00
|
|
|
#include "ompi/constants.h"
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
#include "ompi/mpi/fortran/base/constants.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/runtime/mpiruntime.h"
|
|
|
|
#include "ompi/runtime/params.h"
|
2009-07-07 22:32:14 +04:00
|
|
|
#include "ompi/runtime/ompi_module_exchange.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/communicator/communicator.h"
|
|
|
|
#include "ompi/info/info.h"
|
|
|
|
#include "ompi/errhandler/errcode.h"
|
2011-06-24 00:38:02 +04:00
|
|
|
#include "ompi/errhandler/errhandler.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/request/request.h"
|
2012-02-06 21:35:21 +04:00
|
|
|
#include "ompi/message/message.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/op/op.h"
|
Two major things in this commit:
* 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.
2009-01-15 02:44:31 +03:00
|
|
|
#include "ompi/mca/op/op.h"
|
|
|
|
#include "ompi/mca/op/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/file/file.h"
|
|
|
|
#include "ompi/attribute/attribute.h"
|
|
|
|
#include "ompi/mca/allocator/base/base.h"
|
2005-09-13 02:28:23 +04:00
|
|
|
#include "ompi/mca/rcache/base/base.h"
|
|
|
|
#include "ompi/mca/rcache/rcache.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/mca/mpool/base/base.h"
|
|
|
|
#include "ompi/mca/pml/pml.h"
|
|
|
|
#include "ompi/mca/pml/base/base.h"
|
2006-01-28 18:38:37 +03:00
|
|
|
#include "ompi/mca/osc/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/mca/coll/base/base.h"
|
|
|
|
#include "ompi/mca/io/io.h"
|
|
|
|
#include "ompi/mca/io/base/base.h"
|
2013-01-28 03:25:10 +04:00
|
|
|
#include "ompi/mca/rte/rte.h"
|
2005-09-01 00:35:15 +04:00
|
|
|
#include "ompi/debuggers/debuggers.h"
|
2005-09-13 00:25:01 +04:00
|
|
|
#include "ompi/proc/proc.h"
|
2007-07-17 04:06:35 +04:00
|
|
|
#include "ompi/mca/pml/base/pml_base_bsend.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "ompi/mca/dpm/base/base.h"
|
|
|
|
#include "ompi/mca/pubsub/base/base.h"
|
2010-08-17 08:44:22 +04:00
|
|
|
#include "ompi/mpiext/mpiext.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
|
2010-03-13 02:57:50 +03:00
|
|
|
#if OPAL_ENABLE_FT_CR == 1
|
2007-03-17 02:11:45 +03:00
|
|
|
#include "ompi/mca/crcp/crcp.h"
|
|
|
|
#include "ompi/mca/crcp/base/base.h"
|
|
|
|
#endif
|
|
|
|
#include "ompi/runtime/ompi_cr.h"
|
|
|
|
|
2013-03-11 23:22:24 +04:00
|
|
|
#if defined(MEMORY_LINUX_PTMALLOC2) && MEMORY_LINUX_PTMALLOC2
|
|
|
|
#include "opal/mca/memory/linux/memory_linux.h"
|
|
|
|
/* So this sucks, but with OPAL in its own library that is brought in
|
|
|
|
implicity from libmpi, there are times when the malloc initialize
|
|
|
|
hook in the memory component doesn't work. So we have to do it
|
|
|
|
from here, since any MPI code is going to call MPI_Init... */
|
2013-03-22 03:05:54 +04:00
|
|
|
OPAL_DECLSPEC void (*__malloc_initialize_hook) (void) =
|
2013-03-11 23:22:24 +04:00
|
|
|
opal_memory_linux_malloc_init_hook;
|
|
|
|
#endif
|
|
|
|
|
Deal with the ticket #1239 and #712. This will upgrade the Open MPI support
for the F90 type create functions to the requirements of MPI 2.1 standard.
Advice to implementors. An application may often repeat a call to
MPI_TYPE_CREATE_F90_xxxx with the same combination of (xxxx,p,r).
The application is not allowed to free the returned predefined, unnamed
datatype handles. To prevent the creation of a potentially huge amount of
handles, the MPI implementation should return the same datatype handle for
the same (REAL/COMPLEX/INTEGER,p,r) combination. Checking for the
combination (p,r) in the preceding call to MPI_TYPE_CREATE_F90_xxxx and
using a hash-table to find formerly generated handles should limit the
overhead of finding a previously generated datatype with same combination
of (xxxx,p,r). (End of advice to implementors.)
This commit fixes trac:1239, and #712.
This commit was SVN r19458.
The following Trac tickets were found above:
Ticket 1239 --> https://svn.open-mpi.org/trac/ompi/ticket/1239
2008-08-31 22:36:32 +04:00
|
|
|
/* This is required for the boundaries of the hash tables used to store
|
|
|
|
* the F90 types returned by the MPI_Type_create_f90_XXX functions.
|
|
|
|
*/
|
|
|
|
#include <float.h>
|
|
|
|
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_CC_USE_PRAGMA_IDENT
|
2008-05-01 19:06:10 +04:00
|
|
|
#pragma ident OMPI_IDENT_STRING
|
2009-05-07 00:11:28 +04:00
|
|
|
#elif OPAL_CC_USE_IDENT
|
2008-05-01 19:06:10 +04:00
|
|
|
#ident OMPI_IDENT_STRING
|
|
|
|
#endif
|
|
|
|
const char ompi_version_string[] = OMPI_IDENT_STRING;
|
|
|
|
|
2004-02-05 04:52:56 +03:00
|
|
|
/*
|
|
|
|
* Global variables and symbols for the MPI layer
|
|
|
|
*/
|
|
|
|
|
2011-03-07 19:45:45 +03:00
|
|
|
bool ompi_mpi_init_started = false;
|
2004-06-07 19:33:53 +04:00
|
|
|
bool ompi_mpi_initialized = false;
|
|
|
|
bool ompi_mpi_finalized = false;
|
2004-08-12 20:56:24 +04:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
bool ompi_mpi_thread_multiple = false;
|
|
|
|
int ompi_mpi_thread_requested = MPI_THREAD_SINGLE;
|
|
|
|
int ompi_mpi_thread_provided = MPI_THREAD_SINGLE;
|
2004-02-05 04:52:56 +03:00
|
|
|
|
2005-07-04 02:45:48 +04:00
|
|
|
opal_thread_t *ompi_mpi_main_thread = NULL;
|
2004-11-15 23:03:14 +03:00
|
|
|
|
2008-08-06 21:29:41 +04:00
|
|
|
bool ompi_warn_on_fork;
|
2008-08-06 18:22:03 +04:00
|
|
|
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
/*
|
|
|
|
* These variables are for the MPI F08 bindings (F08 must bind Fortran
|
|
|
|
* varaiables to symbols; it cannot bind Fortran variables to the
|
|
|
|
* address of a C variable).
|
|
|
|
*/
|
|
|
|
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_character_addr = &ompi_mpi_character;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_logical_addr = &ompi_mpi_logical;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_logical1_addr = &ompi_mpi_logical1;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_logical2_addr = &ompi_mpi_logical2;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_logical4_addr = &ompi_mpi_logical4;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_logical8_addr = &ompi_mpi_logical8;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_integer_addr = &ompi_mpi_integer;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_integer1_addr = &ompi_mpi_integer1;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_integer2_addr = &ompi_mpi_integer2;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_integer4_addr = &ompi_mpi_integer4;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_integer8_addr = &ompi_mpi_integer8;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_integer16_addr = &ompi_mpi_integer16;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_real_addr = &ompi_mpi_real;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_real4_addr = &ompi_mpi_real4;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_real8_addr = &ompi_mpi_real8;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_real16_addr = &ompi_mpi_real16;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_dblprec_addr = &ompi_mpi_dblprec;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_cplex_addr = &ompi_mpi_cplex;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_complex8_addr = &ompi_mpi_complex8;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_complex16_addr = &ompi_mpi_complex16;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_complex32_addr = &ompi_mpi_complex32;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_dblcplex_addr = &ompi_mpi_dblcplex;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_2real_addr = &ompi_mpi_2real;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_2dblprec_addr = &ompi_mpi_2dblprec;
|
|
|
|
ompi_predefined_datatype_t *ompi_mpi_2integer_addr = &ompi_mpi_2integer;
|
|
|
|
|
|
|
|
struct ompi_status_public_t *ompi_mpi_status_ignore_addr =
|
|
|
|
(ompi_status_public_t *) 0;
|
|
|
|
struct ompi_status_public_t *ompi_mpi_statuses_ignore_addr =
|
|
|
|
(ompi_status_public_t *) 0;
|
|
|
|
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_HAVE_POSIX_THREADS
|
2008-08-06 18:22:03 +04:00
|
|
|
static bool fork_warning_issued = false;
|
2008-08-06 21:29:41 +04:00
|
|
|
static bool atfork_called = false;
|
2008-08-06 18:22:03 +04:00
|
|
|
|
2008-08-06 21:29:41 +04:00
|
|
|
static void warn_fork_cb(void)
|
2008-08-06 18:22:03 +04:00
|
|
|
{
|
|
|
|
if (ompi_mpi_initialized && !ompi_mpi_finalized && !fork_warning_issued) {
|
2013-02-13 01:10:11 +04:00
|
|
|
opal_show_help("help-mpi-runtime.txt", "mpi_init:warn-fork", true,
|
2013-01-28 03:25:10 +04:00
|
|
|
ompi_process_info.nodename, getpid(),
|
2012-06-27 05:28:28 +04:00
|
|
|
ompi_mpi_comm_world.comm.c_my_rank);
|
2008-08-06 18:22:03 +04:00
|
|
|
fork_warning_issued = true;
|
|
|
|
}
|
|
|
|
}
|
2008-08-06 21:29:41 +04:00
|
|
|
#endif
|
2008-08-06 18:22:03 +04:00
|
|
|
|
|
|
|
void ompi_warn_fork(void)
|
|
|
|
{
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_HAVE_POSIX_THREADS
|
2008-08-06 21:29:41 +04:00
|
|
|
if (ompi_warn_on_fork && !atfork_called) {
|
|
|
|
pthread_atfork(warn_fork_cb, NULL, NULL);
|
|
|
|
atfork_called = true;
|
2008-08-06 18:22:03 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2005-11-22 18:24:39 +03:00
|
|
|
/*
|
|
|
|
* These variables are here, rather than under ompi/mpi/c/foo.c
|
|
|
|
* because it is not sufficient to have a .c file that only contains
|
|
|
|
* variables -- you must have a function that is invoked from
|
|
|
|
* elsewhere in the code to guarantee that all linkers will pull in
|
|
|
|
* the .o file from the library. Hence, although these are MPI
|
|
|
|
* constants, we might as well just define them here (i.e., in a file
|
|
|
|
* that already has a function that is guaranteed to be linked in,
|
|
|
|
* rather than make a new .c file with the constants and a
|
|
|
|
* corresponding dummy function that is invoked from this function).
|
|
|
|
*
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
* Additionally, there can be/are strange linking paths such that
|
2006-09-19 11:55:41 +04:00
|
|
|
* ompi_info needs symbols such as ompi_fortran_status_ignore,
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
* which, if they weren't here with a collection of other global
|
|
|
|
* symbols that are initialized (which seems to force this .o file to
|
|
|
|
* be pulled into the resolution process, because ompi_info certainly
|
|
|
|
* does not call ompi_mpi_init()), would not be able to be found by
|
|
|
|
* the OSX linker.
|
|
|
|
*
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
* NOTE: See the big comment in ompi/mpi/fortran/base/constants.h
|
|
|
|
* about why we have four symbols for each of the common blocks (e.g.,
|
|
|
|
* the Fortran equivalent(s) of MPI_STATUS_IGNORE). Here, we can only
|
|
|
|
* have *one* value (not four). So the only thing we can do is make
|
|
|
|
* it equal to the fortran compiler convention that was selected at
|
|
|
|
* configure time. Note that this is also true for the value of
|
|
|
|
* .TRUE. from the Fortran compiler, so even though Open MPI supports
|
|
|
|
* all four Fortran symbol conventions, it can only support one
|
|
|
|
* convention for the two C constants (MPI_FORTRAN_STATUS[ES]_IGNORE)
|
|
|
|
* and only support one compiler for the value of .TRUE. Ugh!!
|
2005-11-22 18:24:39 +03:00
|
|
|
*
|
|
|
|
* Note that the casts here are ok -- we're *only* comparing pointer
|
|
|
|
* values (i.e., they'll never be de-referenced). The global symbols
|
|
|
|
* are actually of type (ompi_fortran_common_t) (for alignment
|
|
|
|
* issues), but MPI says that MPI_F_STATUS[ES]_IGNORE must be of type
|
|
|
|
* (MPI_Fint*). Hence, we have to cast to make compilers not
|
|
|
|
* complain.
|
|
|
|
*/
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
#if OMPI_BUILD_FORTRAN_BINDINGS
|
|
|
|
# if OMPI_FORTRAN_CAPS
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &MPI_FORTRAN_STATUS_IGNORE;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &MPI_FORTRAN_STATUSES_IGNORE;
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
# elif OMPI_FORTRAN_PLAIN
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &mpi_fortran_status_ignore;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &mpi_fortran_statuses_ignore;
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
# elif OMPI_FORTRAN_SINGLE_UNDERSCORE
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &mpi_fortran_status_ignore_;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &mpi_fortran_statuses_ignore_;
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
# elif OMPI_FORTRAN_DOUBLE_UNDERSCORE
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &mpi_fortran_status_ignore__;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &mpi_fortran_statuses_ignore__;
|
2005-11-23 00:52:14 +03:00
|
|
|
# else
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
# error Unrecognized Fortran name mangling scheme
|
2005-11-23 00:52:14 +03:00
|
|
|
# endif
|
2005-11-22 18:24:39 +03:00
|
|
|
#else
|
2005-11-23 00:52:14 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = NULL;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = NULL;
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
#endif /* OMPI_BUILD_FORTRAN_BINDINGS */
|
2005-11-22 18:24:39 +03:00
|
|
|
|
2005-08-26 14:56:39 +04:00
|
|
|
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
/* Constants for the Fortran layer. These values are referred to via
|
|
|
|
common blocks in the Fortran equivalents. See
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
ompi/mpi/fortran/base/constants.h for a more detailed explanation.
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
|
|
|
|
The values are *NOT* initialized. We do not use the values of
|
|
|
|
these constants; only their addresses (because they're always
|
|
|
|
passed by reference by Fortran).
|
|
|
|
|
|
|
|
Initializing upon instantiation these can reveal size and/or
|
|
|
|
alignment differences between Fortran and C (!) which can cause
|
|
|
|
warnings or errors upon linking (e.g., making static libraries with
|
|
|
|
the intel 9.0 compilers on 64 bit platforms shows alignment
|
|
|
|
differences between libmpi.a and the user's application, resulting
|
|
|
|
in a linker warning). FWIW, if you initialize these variables in
|
|
|
|
functions (i.e., not at the instantiation in the global scope), the
|
|
|
|
linker somehow "figures it all out" (w.r.t. different alignments
|
|
|
|
between fortan common blocks and the corresponding C variables) and
|
|
|
|
no linker warnings occur.
|
|
|
|
|
|
|
|
Note that the rationale for the types of each of these variables is
|
|
|
|
discussed in ompi/include/mpif-common.h. Do not change the types
|
== Highlights ==
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
|
|
|
without also modifying ompi/mpi/fortran/base/constants.h and
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
ompi/include/mpif-common.h.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define INST(type, upper_case, lower_case, single_u, double_u) \
|
|
|
|
type lower_case; \
|
|
|
|
type upper_case; \
|
|
|
|
type single_u; \
|
|
|
|
type double_u
|
|
|
|
|
|
|
|
INST(int, MPI_FORTRAN_BOTTOM, mpi_fortran_bottom,
|
|
|
|
mpi_fortran_bottom_, mpi_fortran_bottom__);
|
|
|
|
INST(int, MPI_FORTRAN_IN_PLACE, mpi_fortran_in_place,
|
|
|
|
mpi_fortran_in_place_, mpi_fortran_in_place__);
|
2013-07-01 16:40:08 +04:00
|
|
|
INST(int, MPI_FORTRAN_UNWEIGHTED, mpi_fortran_unweighted,
|
|
|
|
mpi_fortran_unweighted_, mpi_fortran_unweighted__);
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
INST(char *, MPI_FORTRAN_ARGV_NULL, mpi_fortran_argv_null,
|
|
|
|
mpi_fortran_argv_null_, mpi_fortran_argv_null__);
|
Many updates and bug fixes for the Fortran bindings. Sorry these
aren't separated out into individual commits; they represent a few
months of work in the Mercurial branch, and it seemed error-prone to
try to break them up into multiple SVN commits.
* Remove 2nd overloaded interfaces for MPI_TESTALL, MPI_TESTSOME,
MPI_WAITALL, and MPI_WAITSOME in the "mpi" module implementations
(because we're not allowed to have them, anyway -- it causes
complications in the profiling interface). This forced an MPI-2.2
errata in the MPI Forum; we applied the errata here (the array of
statuses parameter could not have a specific dimension specified in
the dummy argument). Fixes trac:3166.
* Similarly, fix type for MPI_ARGVS_NULL in Fortran
* Add MPI_3.0 function MPI_F_SYNC_REG (Fortran interfaces only).
* Add MPI-3.0 MPI_MESSAGE_NO_PROC in the mpi_f08 module.
* Added mpi_f08 handle comparison operators, per MPI-3.0 addendum to
the F08 proposal at the last Forum meeting.
* Added missing type(MPI_File) and type(Message) in mpi_f08 module.
* Fix --disable-mpi-io configure switch with all Fortran interfaces
* Re-factor the Fortran header files to be fundamentally simpler and
easier to maintain. Fortran constant values in the header files
are now generated by a script named mpif-values.pl during
autogen.pl (they were previously generated by mpif-common.pl, but
it was quite a bit more subtle/complex). A second commit will
follow this one to update svn:ignore values (just to ensure we
don't muck up the first commit with the SVN client getting confused
by the changed ignore values and new/changed files).
* Fix some dependencies for compile ordering in
ompi/mpi/fortran/use-mpi-ignore-tkr/Makefile.am.
* Fix bad wording in several places (.m4 file name, ompi_info output,
etc.): we previoulsy said "F08 assumed shape" when we really meant
"F08 assumed rank" (for Fortran gurus, those are very different
things).
* Removed the GREEK/SVN version string from mpif.h. It really had no
purpose being there.
Still to be done:
* Handling of 2D array of strings in MPI_COMM_SPAWN_MULTIPLE still
isn't right yet. Not sure how many people really care about this
:-), but it is still broken.
This commit was SVN r26997.
The following Trac tickets were found above:
Ticket 3166 --> https://svn.open-mpi.org/trac/ompi/ticket/3166
2012-08-11 01:19:47 +04:00
|
|
|
INST(char *, MPI_FORTRAN_ARGVS_NULL, mpi_fortran_argvs_null,
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
mpi_fortran_argvs_null_, mpi_fortran_argvs_null__);
|
|
|
|
INST(int *, MPI_FORTRAN_ERRCODES_IGNORE, mpi_fortran_errcodes_ignore,
|
|
|
|
mpi_fortran_errcodes_ignore_, mpi_fortran_errcodes_ignore__);
|
|
|
|
INST(int *, MPI_FORTRAN_STATUS_IGNORE, mpi_fortran_status_ignore,
|
|
|
|
mpi_fortran_status_ignore_, mpi_fortran_status_ignore__);
|
Many updates and bug fixes for the Fortran bindings. Sorry these
aren't separated out into individual commits; they represent a few
months of work in the Mercurial branch, and it seemed error-prone to
try to break them up into multiple SVN commits.
* Remove 2nd overloaded interfaces for MPI_TESTALL, MPI_TESTSOME,
MPI_WAITALL, and MPI_WAITSOME in the "mpi" module implementations
(because we're not allowed to have them, anyway -- it causes
complications in the profiling interface). This forced an MPI-2.2
errata in the MPI Forum; we applied the errata here (the array of
statuses parameter could not have a specific dimension specified in
the dummy argument). Fixes trac:3166.
* Similarly, fix type for MPI_ARGVS_NULL in Fortran
* Add MPI_3.0 function MPI_F_SYNC_REG (Fortran interfaces only).
* Add MPI-3.0 MPI_MESSAGE_NO_PROC in the mpi_f08 module.
* Added mpi_f08 handle comparison operators, per MPI-3.0 addendum to
the F08 proposal at the last Forum meeting.
* Added missing type(MPI_File) and type(Message) in mpi_f08 module.
* Fix --disable-mpi-io configure switch with all Fortran interfaces
* Re-factor the Fortran header files to be fundamentally simpler and
easier to maintain. Fortran constant values in the header files
are now generated by a script named mpif-values.pl during
autogen.pl (they were previously generated by mpif-common.pl, but
it was quite a bit more subtle/complex). A second commit will
follow this one to update svn:ignore values (just to ensure we
don't muck up the first commit with the SVN client getting confused
by the changed ignore values and new/changed files).
* Fix some dependencies for compile ordering in
ompi/mpi/fortran/use-mpi-ignore-tkr/Makefile.am.
* Fix bad wording in several places (.m4 file name, ompi_info output,
etc.): we previoulsy said "F08 assumed shape" when we really meant
"F08 assumed rank" (for Fortran gurus, those are very different
things).
* Removed the GREEK/SVN version string from mpif.h. It really had no
purpose being there.
Still to be done:
* Handling of 2D array of strings in MPI_COMM_SPAWN_MULTIPLE still
isn't right yet. Not sure how many people really care about this
:-), but it is still broken.
This commit was SVN r26997.
The following Trac tickets were found above:
Ticket 3166 --> https://svn.open-mpi.org/trac/ompi/ticket/3166
2012-08-11 01:19:47 +04:00
|
|
|
INST(int *, MPI_FORTRAN_STATUSES_IGNORE, mpi_fortran_statuses_ignore,
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
mpi_fortran_statuses_ignore_, mpi_fortran_statuses_ignore__);
|
|
|
|
|
2008-08-31 23:56:39 +04:00
|
|
|
/*
|
|
|
|
* Hash tables for MPI_Type_create_f90* functions
|
|
|
|
*/
|
|
|
|
opal_hash_table_t ompi_mpi_f90_integer_hashtable;
|
|
|
|
opal_hash_table_t ompi_mpi_f90_real_hashtable;
|
|
|
|
opal_hash_table_t ompi_mpi_f90_complex_hashtable;
|
|
|
|
|
2007-12-07 16:09:07 +03:00
|
|
|
/*
|
|
|
|
* Per MPI-2:9.5.3, MPI_REGISTER_DATAREP is a memory leak. There is
|
|
|
|
* no way to *de*register datareps once they've been registered. So
|
|
|
|
* we have to track all registrations here so that they can be
|
|
|
|
* de-registered during MPI_FINALIZE so that memory-tracking debuggers
|
|
|
|
* don't show Open MPI as leaking memory.
|
|
|
|
*/
|
|
|
|
opal_list_t ompi_registered_datareps;
|
|
|
|
|
2013-03-28 01:09:41 +04:00
|
|
|
bool ompi_enable_timing;
|
|
|
|
extern bool ompi_mpi_yield_when_idle;
|
|
|
|
extern int ompi_mpi_event_tick_rate;
|
|
|
|
|
2013-04-24 19:59:23 +04:00
|
|
|
|
|
|
|
void ompi_mpi_thread_level(int requested, int *provided)
|
|
|
|
{
|
|
|
|
/**
|
|
|
|
* These values are monotonic; MPI_THREAD_SINGLE < MPI_THREAD_FUNNELED
|
|
|
|
* < MPI_THREAD_SERIALIZED < MPI_THREAD_MULTIPLE.
|
|
|
|
* If possible, the call will return provided = required. Failing this,
|
|
|
|
* the call will return the least supported level such that
|
|
|
|
* provided > required. Finally, if the user requirement cannot be
|
|
|
|
* satisfied, then the call will return in provided the highest
|
|
|
|
* supported level.
|
|
|
|
*/
|
|
|
|
ompi_mpi_thread_requested = requested;
|
|
|
|
|
|
|
|
if (OMPI_ENABLE_THREAD_MULTIPLE == 1) {
|
|
|
|
ompi_mpi_thread_provided = *provided = requested;
|
|
|
|
ompi_mpi_main_thread = opal_thread_get_self();
|
|
|
|
} else {
|
|
|
|
if (MPI_THREAD_MULTIPLE == requested) {
|
|
|
|
ompi_mpi_thread_provided = *provided = MPI_THREAD_SERIALIZED;
|
|
|
|
} else {
|
|
|
|
ompi_mpi_thread_provided = *provided = requested;
|
|
|
|
}
|
|
|
|
ompi_mpi_main_thread = (OPAL_ENABLE_MULTI_THREADS ? opal_thread_get_self() : NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
ompi_mpi_thread_multiple = (ompi_mpi_thread_provided ==
|
|
|
|
MPI_THREAD_MULTIPLE);
|
|
|
|
}
|
|
|
|
|
2013-03-28 01:09:41 +04:00
|
|
|
static int ompi_register_mca_variables(void)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Register MPI variables */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_mpi_register_params())) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* check to see if we want timing information */
|
|
|
|
ompi_enable_timing = false;
|
|
|
|
(void) mca_base_var_register("ompi", "ompi", NULL, "timing",
|
|
|
|
"Request that critical timing loops be measured",
|
|
|
|
MCA_BASE_VAR_TYPE_BOOL, NULL, 0, 0,
|
|
|
|
OPAL_INFO_LVL_9,
|
|
|
|
MCA_BASE_VAR_SCOPE_READONLY,
|
|
|
|
&ompi_enable_timing);
|
|
|
|
|
|
|
|
return OMPI_SUCCESS;
|
|
|
|
}
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
int ompi_mpi_init(int argc, char **argv, int requested, int *provided)
|
2004-01-15 09:08:25 +03:00
|
|
|
{
|
2005-05-24 02:06:50 +04:00
|
|
|
int ret;
|
2004-06-07 19:33:53 +04:00
|
|
|
ompi_proc_t** procs;
|
2004-03-03 19:44:41 +03:00
|
|
|
size_t nprocs;
|
2004-11-17 05:30:07 +03:00
|
|
|
char *error = NULL;
|
2006-11-03 19:04:40 +03:00
|
|
|
struct timeval ompistart, ompistop;
|
2013-01-28 03:25:10 +04:00
|
|
|
bool rte_setup = false;
|
|
|
|
ompi_rte_collective_t *coll;
|
2012-09-12 01:12:06 +04:00
|
|
|
char *cmd=NULL, *av=NULL;
|
2005-03-25 06:06:06 +03:00
|
|
|
|
2009-07-07 22:32:14 +04:00
|
|
|
/* bitflag of the thread level support provided. To be used
|
|
|
|
* for the modex in order to work in heterogeneous environments. */
|
|
|
|
uint8_t threadlevel_bf;
|
|
|
|
|
2011-03-07 19:45:45 +03:00
|
|
|
/* Indicate that we have *started* MPI_INIT*. MPI_FINALIZE has
|
|
|
|
something sorta similar in a static local variable in
|
|
|
|
ompi_mpi_finalize(). */
|
|
|
|
ompi_mpi_init_started = true;
|
|
|
|
|
2008-03-25 20:18:17 +03:00
|
|
|
/* Setup enough to check get/set MCA params */
|
|
|
|
|
2011-10-04 18:50:31 +04:00
|
|
|
if (OPAL_SUCCESS != (ret = opal_init_util(&argc, &argv))) {
|
2008-03-25 20:18:17 +03:00
|
|
|
error = "ompi_mpi_init: opal_init_util failed";
|
2005-05-23 18:50:52 +04:00
|
|
|
goto error;
|
|
|
|
}
|
2005-08-16 20:17:52 +04:00
|
|
|
|
2013-03-28 01:09:41 +04:00
|
|
|
/* Register MCA variables */
|
|
|
|
if (OPAL_SUCCESS != (ret = ompi_register_mca_variables())) {
|
|
|
|
error = "ompi_mpi_init: ompi_register_mca_variables failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2013-01-15 05:27:36 +04:00
|
|
|
if (OPAL_SUCCESS != (ret = opal_arch_set_fortran_logical_size(sizeof(ompi_fortran_logical_t)))) {
|
|
|
|
error = "ompi_mpi_init: opal_arch_set_fortran_logical_size failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2008-03-25 20:18:17 +03:00
|
|
|
/* _After_ opal_init_util() but _before_ orte_init(), we need to
|
|
|
|
set an MCA param that tells libevent that it's ok to use any
|
2008-03-26 17:54:09 +03:00
|
|
|
mechanism in libevent that is available on this platform (e.g.,
|
2008-03-25 20:18:17 +03:00
|
|
|
epoll and friends). Per opal/event/event.s, we default to
|
|
|
|
select/poll -- but we know that MPI processes won't be using
|
|
|
|
pty's with the event engine, so it's ok to relax this
|
|
|
|
constraint and let any fd-monitoring mechanism be used. */
|
2013-03-28 01:17:53 +04:00
|
|
|
|
|
|
|
ret = mca_base_var_find("opal", "event", "*", "event_include");
|
2008-03-25 20:18:17 +03:00
|
|
|
if (ret >= 0) {
|
2013-03-28 01:17:53 +04:00
|
|
|
char *allvalue = "all";
|
2008-03-25 20:18:17 +03:00
|
|
|
/* We have to explicitly "set" the MCA param value here
|
|
|
|
because libevent initialization will re-register the MCA
|
|
|
|
param and therefore override the default. Setting the value
|
|
|
|
here puts the desired value ("all") in different storage
|
|
|
|
that is not overwritten if/when the MCA param is
|
2008-03-26 17:54:09 +03:00
|
|
|
re-registered. This is unless the user has specified a different
|
|
|
|
value for this MCA parameter. Make sure we check to see if the
|
|
|
|
default is specified before forcing "all" in case that is not what
|
|
|
|
the user desires. Note that we do *NOT* set this value as an
|
2008-03-25 20:18:17 +03:00
|
|
|
environment variable, just so that it won't be inherited by
|
|
|
|
any spawned processes and potentially cause unintented
|
2013-01-28 03:25:10 +04:00
|
|
|
side-effects with launching RTE tools... */
|
2013-03-28 01:17:53 +04:00
|
|
|
mca_base_var_set_value(ret, allvalue, 4, MCA_BASE_VAR_SOURCE_DEFAULT, NULL);
|
2008-03-26 17:54:09 +03:00
|
|
|
}
|
|
|
|
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_enable_timing && 0 == OMPI_PROC_MY_NAME->vpid) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistart, NULL);
|
2006-09-29 17:19:44 +04:00
|
|
|
}
|
2013-03-28 01:09:41 +04:00
|
|
|
|
2012-08-14 02:13:49 +04:00
|
|
|
/* if we were not externally started, then we need to setup
|
2012-09-11 21:03:49 +04:00
|
|
|
* some envars so the MPI_INFO_ENV can get the cmd name
|
|
|
|
* and argv (but only if the user supplied a non-NULL argv!), and
|
|
|
|
* the requested thread level
|
2012-08-14 02:13:49 +04:00
|
|
|
*/
|
2012-08-14 20:33:53 +04:00
|
|
|
if (NULL == getenv("OMPI_COMMAND") && NULL != argv && NULL != argv[0]) {
|
2012-08-14 02:13:49 +04:00
|
|
|
asprintf(&cmd, "OMPI_COMMAND=%s", argv[0]);
|
|
|
|
putenv(cmd);
|
|
|
|
}
|
|
|
|
if (NULL == getenv("OMPI_ARGV") && 1 < argc) {
|
|
|
|
char *tmp;
|
|
|
|
tmp = opal_argv_join(&argv[1], ' ');
|
|
|
|
asprintf(&av, "OMPI_ARGV=%s", tmp);
|
|
|
|
free(tmp);
|
|
|
|
putenv(av);
|
|
|
|
}
|
|
|
|
|
2013-01-28 03:25:10 +04:00
|
|
|
/* Setup RTE - note that we are an MPI process */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_rte_init(NULL, NULL))) {
|
|
|
|
error = "ompi_mpi_init: ompi_rte_init failed";
|
2005-08-16 20:17:52 +04:00
|
|
|
goto error;
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 07:59:06 +04:00
|
|
|
}
|
2013-01-28 03:25:10 +04:00
|
|
|
rte_setup = true;
|
2012-06-27 05:28:28 +04:00
|
|
|
|
2006-11-03 19:04:40 +03:00
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_enable_timing && 0 == OMPI_PROC_MY_NAME->vpid) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2013-01-28 03:25:10 +04:00
|
|
|
opal_output(0, "ompi_mpi_init [%ld]: time from start to completion of rte_init %ld usec",
|
|
|
|
(long)OMPI_PROC_MY_NAME->vpid,
|
2006-11-03 19:04:40 +03:00
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
2008-10-28 21:29:57 +03:00
|
|
|
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
#if OPAL_HAVE_HWLOC
|
|
|
|
/* if hwloc is available but didn't get setup for some
|
|
|
|
* reason, do so now
|
|
|
|
*/
|
|
|
|
if (NULL == opal_hwloc_topology) {
|
|
|
|
if (OPAL_SUCCESS != (ret = opal_hwloc_base_get_topology())) {
|
|
|
|
error = "Topology init";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
Per the RFC and discussion on the devel list, update the RTE-MPI error handling interface. There are a few differences in the code from the original RFC that came out of the discussion - I've captured those in the following writeup
George and I were talking about ORTE's error handling the other day in regards to the right way to deal with errors in the updated OOB. Specifically, it seemed a bad idea for a library such as ORTE to be aborting the job on its own prerogative. If we lose a connection or cannot send a message, then we really should just report it upwards and let the application and/or upper layers decide what to do about it.
The current code base only allows a single error callback to exist, which seemed unduly limiting. So, based on the conversation, I've modified the errmgr interface to provide a mechanism for registering any number of error handlers (this replaces the current "set_fault_callback" API). When an error occurs, these handlers will be called in order until one responds that the error has been "resolved" - i.e., no further action is required - by returning OMPI_SUCCESS. The default MPI layer error handler is specified to go "last" and calls mpi_abort, so the current "abort" behavior is preserved unless other error handlers are registered.
In the register_callback function, I provide an "order" param so you can specify "this callback must come first" or "this callback must come last". Seemed to me that we will probably have different code areas registering callbacks, and one might require it go first (the default "abort" will always require it go last). So you can append and prepend, or go first. Note that only one registration can declare itself "first" or "last", and since the default "abort" callback automatically takes "last", that one isn't available. :-)
The errhandler callback function passes an opal_pointer_array of structs, each of which contains the name of the proc involved (which can be yourself for internal errors) and the error code. This is a change from the current fault callback which returned an opal_pointer_array of just process names. Rationale is that you might need to see the cause of the error to decide what action to take. I realize that isn't a requirement for remote procs, but remember that we will use the SAME interface to report RTE errors internal to the proc itself. In those cases, you really do need to see the error code. It is legal to pass a NULL for the pointer array (e.g., when reporting an internal failure without error code), so handlers must be prepared for that possibility. If people find that too burdensome, we can remove it.
Should we ever decide to create a separate callback path for internal errors vs remote process failures, or if we decide to do something different based on experience, then we can adjust this API.
This commit was SVN r28852.
2013-07-19 05:08:53 +04:00
|
|
|
/* Register the default errhandler callback - RTE will ignore if it
|
2013-01-28 03:25:10 +04:00
|
|
|
* doesn't support this capability
|
|
|
|
*/
|
Per the RFC and discussion on the devel list, update the RTE-MPI error handling interface. There are a few differences in the code from the original RFC that came out of the discussion - I've captured those in the following writeup
George and I were talking about ORTE's error handling the other day in regards to the right way to deal with errors in the updated OOB. Specifically, it seemed a bad idea for a library such as ORTE to be aborting the job on its own prerogative. If we lose a connection or cannot send a message, then we really should just report it upwards and let the application and/or upper layers decide what to do about it.
The current code base only allows a single error callback to exist, which seemed unduly limiting. So, based on the conversation, I've modified the errmgr interface to provide a mechanism for registering any number of error handlers (this replaces the current "set_fault_callback" API). When an error occurs, these handlers will be called in order until one responds that the error has been "resolved" - i.e., no further action is required - by returning OMPI_SUCCESS. The default MPI layer error handler is specified to go "last" and calls mpi_abort, so the current "abort" behavior is preserved unless other error handlers are registered.
In the register_callback function, I provide an "order" param so you can specify "this callback must come first" or "this callback must come last". Seemed to me that we will probably have different code areas registering callbacks, and one might require it go first (the default "abort" will always require it go last). So you can append and prepend, or go first. Note that only one registration can declare itself "first" or "last", and since the default "abort" callback automatically takes "last", that one isn't available. :-)
The errhandler callback function passes an opal_pointer_array of structs, each of which contains the name of the proc involved (which can be yourself for internal errors) and the error code. This is a change from the current fault callback which returned an opal_pointer_array of just process names. Rationale is that you might need to see the cause of the error to decide what action to take. I realize that isn't a requirement for remote procs, but remember that we will use the SAME interface to report RTE errors internal to the proc itself. In those cases, you really do need to see the error code. It is legal to pass a NULL for the pointer array (e.g., when reporting an internal failure without error code), so handlers must be prepared for that possibility. If people find that too burdensome, we can remove it.
Should we ever decide to create a separate callback path for internal errors vs remote process failures, or if we decide to do something different based on experience, then we can adjust this API.
This commit was SVN r28852.
2013-07-19 05:08:53 +04:00
|
|
|
ompi_rte_register_errhandler(ompi_errhandler_runtime_callback,
|
|
|
|
OMPI_RTE_ERRHANDLER_LAST);
|
2011-06-24 00:38:02 +04:00
|
|
|
|
2008-10-28 21:29:57 +03:00
|
|
|
/* Figure out the final MPI thread levels. If we were not
|
|
|
|
compiled for support for MPI threads, then don't allow
|
|
|
|
MPI_THREAD_MULTIPLE. Set this stuff up here early in the
|
|
|
|
process so that other components can make decisions based on
|
|
|
|
this value. */
|
|
|
|
|
2013-04-24 19:59:23 +04:00
|
|
|
ompi_mpi_thread_level(requested, provided);
|
2008-10-28 21:29:57 +03:00
|
|
|
|
2009-07-07 22:32:14 +04:00
|
|
|
/* determine the bitflag belonging to the threadlevel_support provided */
|
|
|
|
memset ( &threadlevel_bf, 0, sizeof(uint8_t));
|
|
|
|
OMPI_THREADLEVEL_SET_BITFLAG ( ompi_mpi_thread_provided, threadlevel_bf );
|
|
|
|
|
|
|
|
/* add this bitflag to the modex */
|
|
|
|
if ( OMPI_SUCCESS != (ret = ompi_modex_send_string("MPI_THREAD_LEVEL", &threadlevel_bf, sizeof(uint8_t)))) {
|
2011-12-15 06:23:21 +04:00
|
|
|
error = "ompi_mpi_init: modex send thread level";
|
|
|
|
goto error;
|
2009-07-07 22:32:14 +04:00
|
|
|
}
|
|
|
|
|
2012-01-19 22:38:58 +04:00
|
|
|
/* initialize datatypes. This step should be done early as it will
|
|
|
|
* create the local convertor and local arch used in the proc
|
|
|
|
* init.
|
|
|
|
*/
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_datatype_init())) {
|
|
|
|
error = "ompi_datatype_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Initialize OMPI procs */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_proc_init())) {
|
|
|
|
error = "mca_proc_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Initialize the op framework. This has to be done *after*
|
|
|
|
ddt_init, but befor mca_coll_base_open, since some collective
|
|
|
|
modules (e.g., the hierarchical coll component) may need ops in
|
|
|
|
their query function. */
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_op_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "ompi_op_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = ompi_op_base_find_available(OMPI_ENABLE_PROGRESS_THREADS,
|
|
|
|
OMPI_ENABLE_THREAD_MULTIPLE))) {
|
|
|
|
error = "ompi_op_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_op_init())) {
|
|
|
|
error = "ompi_op_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Open up MPI-related MCA components */
|
|
|
|
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_allocator_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "mca_allocator_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_rcache_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "mca_rcache_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_mpool_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "mca_mpool_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_pml_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "mca_pml_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_coll_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "mca_coll_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_osc_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "ompi_osc_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
#if OPAL_ENABLE_FT_CR == 1
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_crcp_base_framework, 0))) {
|
2012-01-19 22:38:58 +04:00
|
|
|
error = "ompi_crcp_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* In order to reduce the common case for MPI apps (where they
|
|
|
|
don't use MPI-2 IO or MPI-1 topology functions), the io and
|
|
|
|
topo frameworks are initialized lazily, at the first use of
|
|
|
|
relevant functions (e.g., MPI_FILE_*, MPI_CART_*, MPI_GRAPH_*),
|
|
|
|
so they are not opened here. */
|
|
|
|
|
|
|
|
/* Select which MPI components to use */
|
|
|
|
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_mpool_base_init(OMPI_ENABLE_PROGRESS_THREADS,
|
|
|
|
OMPI_ENABLE_THREAD_MULTIPLE))) {
|
|
|
|
error = "mca_mpool_base_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_pml_base_select(OMPI_ENABLE_PROGRESS_THREADS,
|
|
|
|
OMPI_ENABLE_THREAD_MULTIPLE))) {
|
|
|
|
error = "mca_pml_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_enable_timing && 0 == OMPI_PROC_MY_NAME->vpid) {
|
2012-01-19 22:38:58 +04:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2013-01-28 03:25:10 +04:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from completion of rte_init to modex %ld usec",
|
|
|
|
(long)OMPI_PROC_MY_NAME->vpid,
|
2012-01-19 22:38:58 +04:00
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* exchange connection info - this function also acts as a barrier
|
|
|
|
* as it will not return until the exchange is complete
|
|
|
|
*/
|
2013-01-28 03:25:10 +04:00
|
|
|
coll = OBJ_NEW(ompi_rte_collective_t);
|
|
|
|
coll->id = ompi_process_info.peer_modex;
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_rte_modex(coll))) {
|
|
|
|
error = "rte_modex failed";
|
2012-01-19 22:38:58 +04:00
|
|
|
goto error;
|
|
|
|
}
|
2012-06-27 05:28:28 +04:00
|
|
|
/* wait for modex to complete - this may be moved anywhere in mpi_init
|
|
|
|
* so long as it occurs prior to calling a function that needs
|
|
|
|
* the modex info!
|
|
|
|
*/
|
|
|
|
while (coll->active) {
|
|
|
|
opal_progress(); /* block in progress pending events */
|
|
|
|
}
|
|
|
|
OBJ_RELEASE(coll);
|
2012-01-19 22:38:58 +04:00
|
|
|
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_enable_timing && 0 == OMPI_PROC_MY_NAME->vpid) {
|
2012-01-19 22:38:58 +04:00
|
|
|
gettimeofday(&ompistop, NULL);
|
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time to execute modex %ld usec",
|
2013-01-28 03:25:10 +04:00
|
|
|
(long)OMPI_PROC_MY_NAME->vpid,
|
2012-01-19 22:38:58 +04:00
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
|
2007-07-17 01:52:25 +04:00
|
|
|
/* select buffered send allocator component to be used */
|
2010-03-17 02:10:50 +03:00
|
|
|
ret=mca_pml_base_bsend_init(OMPI_ENABLE_THREAD_MULTIPLE);
|
2007-07-17 01:52:25 +04:00
|
|
|
if( OMPI_SUCCESS != ret ) {
|
|
|
|
error = "mca_pml_base_bsend_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
if (OMPI_SUCCESS !=
|
Update libevent to the 2.0 series, currently at 2.0.7rc. We will update to their final release when it becomes available. Currently known errors exist in unused portions of the libevent code. This revision passes the IBM test suite on a Linux machine and on a standalone Mac.
This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects.
Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems.
Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct.
I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things:
1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new)
2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it.
There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do.
This commit was SVN r23925.
2010-10-24 22:35:54 +04:00
|
|
|
(ret = mca_coll_base_find_available(OMPI_ENABLE_PROGRESS_THREADS,
|
2010-03-17 02:10:50 +03:00
|
|
|
OMPI_ENABLE_THREAD_MULTIPLE))) {
|
2005-03-27 17:05:23 +04:00
|
|
|
error = "mca_coll_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2006-01-28 18:38:37 +03:00
|
|
|
if (OMPI_SUCCESS !=
|
Update libevent to the 2.0 series, currently at 2.0.7rc. We will update to their final release when it becomes available. Currently known errors exist in unused portions of the libevent code. This revision passes the IBM test suite on a Linux machine and on a standalone Mac.
This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects.
Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems.
Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct.
I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things:
1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new)
2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it.
There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do.
This commit was SVN r23925.
2010-10-24 22:35:54 +04:00
|
|
|
(ret = ompi_osc_base_find_available(OMPI_ENABLE_PROGRESS_THREADS,
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
OMPI_ENABLE_THREAD_MULTIPLE))) {
|
2006-01-28 18:38:37 +03:00
|
|
|
error = "ompi_osc_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2010-03-13 02:57:50 +03:00
|
|
|
#if OPAL_ENABLE_FT_CR == 1
|
2007-03-17 02:11:45 +03:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_crcp_base_select() ) ) {
|
|
|
|
error = "ompi_crcp_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* io and topo components are not selected here -- see comment
|
|
|
|
above about the io and topo frameworks being loaded lazily */
|
|
|
|
|
|
|
|
/* Initialize each MPI handle subsystem */
|
2004-10-08 21:12:36 +04:00
|
|
|
/* initialize requests */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_request_init())) {
|
|
|
|
error = "ompi_request_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2012-02-06 21:35:21 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_message_init())) {
|
|
|
|
error = "ompi_message_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize info */
|
2012-08-14 02:13:49 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_info_init())) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "ompi_info_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2004-10-08 21:12:36 +04:00
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize error handlers */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_errhandler_init())) {
|
|
|
|
error = "ompi_errhandler_init() failed";
|
|
|
|
goto error;
|
2004-02-13 16:56:55 +03:00
|
|
|
}
|
2004-01-30 06:59:39 +03:00
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize error codes */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_mpi_errcode_init())) {
|
|
|
|
error = "ompi_mpi_errcode_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize internal error codes */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_errcode_intern_init())) {
|
|
|
|
error = "ompi_errcode_intern_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2004-05-08 03:23:03 +04:00
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize groups */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_group_init())) {
|
|
|
|
error = "ompi_group_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize communicators */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_comm_init())) {
|
|
|
|
error = "ompi_comm_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize file handles */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_file_init())) {
|
|
|
|
error = "ompi_file_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2006-01-28 18:38:37 +03:00
|
|
|
/* initialize windows */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_win_init())) {
|
|
|
|
error = "ompi_win_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2004-09-16 04:00:09 +04:00
|
|
|
/* initialize attribute meta-data structure for comm/win/dtype */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_attr_init())) {
|
|
|
|
error = "ompi_attr_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2004-11-20 22:12:43 +03:00
|
|
|
|
2008-06-19 02:17:53 +04:00
|
|
|
/* identify the architectures of remote procs and setup
|
|
|
|
* their datatype convertors, if required
|
|
|
|
*/
|
2011-10-18 06:54:38 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_proc_complete_init())) {
|
|
|
|
error = "ompi_proc_complete_init failed";
|
2008-06-19 02:17:53 +04:00
|
|
|
goto error;
|
|
|
|
}
|
2005-03-27 17:05:23 +04:00
|
|
|
|
2008-10-28 21:29:57 +03:00
|
|
|
/* If thread support was enabled, then setup OPAL to allow for
|
|
|
|
them. */
|
Update libevent to the 2.0 series, currently at 2.0.7rc. We will update to their final release when it becomes available. Currently known errors exist in unused portions of the libevent code. This revision passes the IBM test suite on a Linux machine and on a standalone Mac.
This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects.
Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems.
Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct.
I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things:
1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new)
2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it.
There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do.
This commit was SVN r23925.
2010-10-24 22:35:54 +04:00
|
|
|
if ((OMPI_ENABLE_PROGRESS_THREADS == 1) ||
|
2006-08-15 19:55:53 +04:00
|
|
|
(*provided != MPI_THREAD_SINGLE)) {
|
2005-07-04 02:45:48 +04:00
|
|
|
opal_set_using_threads(true);
|
2005-03-27 17:05:23 +04:00
|
|
|
}
|
2004-02-05 04:52:56 +03:00
|
|
|
|
2007-08-04 04:37:52 +04:00
|
|
|
/* start PML/BTL's */
|
2007-04-07 09:06:47 +04:00
|
|
|
ret = MCA_PML_CALL(enable(true));
|
|
|
|
if( OMPI_SUCCESS != ret ) {
|
|
|
|
error = "PML control failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* add all ompi_proc_t's to PML */
|
|
|
|
if (NULL == (procs = ompi_proc_world(&nprocs))) {
|
|
|
|
error = "ompi_proc_world() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
ret = MCA_PML_CALL(add_procs(procs, nprocs));
|
|
|
|
free(procs);
|
2010-03-14 03:09:55 +03:00
|
|
|
/* If we got "unreachable", then print a specific error message.
|
|
|
|
Otherwise, if we got some other failure, fall through to print
|
|
|
|
a generic message. */
|
2012-04-06 18:23:13 +04:00
|
|
|
if (OMPI_ERR_UNREACH == ret) {
|
2013-02-13 01:10:11 +04:00
|
|
|
opal_show_help("help-mpi-runtime",
|
2010-03-14 03:09:55 +03:00
|
|
|
"mpi_init:startup:pml-add-procs-fail", true);
|
|
|
|
error = NULL;
|
|
|
|
goto error;
|
|
|
|
} else if (OMPI_SUCCESS != ret) {
|
2007-04-07 09:06:47 +04:00
|
|
|
error = "PML add procs failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2009-02-24 20:17:33 +03:00
|
|
|
MCA_PML_CALL(add_comm(&ompi_mpi_comm_world.comm));
|
|
|
|
MCA_PML_CALL(add_comm(&ompi_mpi_comm_self.comm));
|
2007-04-07 09:06:47 +04:00
|
|
|
|
2005-07-09 01:01:37 +04:00
|
|
|
/*
|
|
|
|
* Dump all MCA parameters if requested
|
|
|
|
*/
|
|
|
|
if (ompi_mpi_show_mca_params) {
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
ompi_show_all_mca_params(ompi_mpi_comm_world.comm.c_my_rank,
|
|
|
|
nprocs,
|
2013-01-28 03:25:10 +04:00
|
|
|
ompi_process_info.nodename);
|
2005-07-09 01:01:37 +04:00
|
|
|
}
|
|
|
|
|
2008-06-18 19:28:46 +04:00
|
|
|
/* Do we need to wait for a debugger? */
|
2013-01-28 03:25:10 +04:00
|
|
|
ompi_rte_wait_for_debugger();
|
|
|
|
|
2008-06-18 19:28:46 +04:00
|
|
|
/* check for timing request - get stop time and report elapsed
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
time if so, then start the clock again */
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_enable_timing && 0 == OMPI_PROC_MY_NAME->vpid) {
|
2008-06-18 19:28:46 +04:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2009-01-07 00:30:12 +03:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from modex to first barrier %ld usec",
|
2013-01-28 03:25:10 +04:00
|
|
|
(long)OMPI_PROC_MY_NAME->vpid,
|
2008-06-18 19:28:46 +04:00
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
2013-01-28 03:25:10 +04:00
|
|
|
|
2008-06-18 19:28:46 +04:00
|
|
|
/* wait for everyone to reach this point */
|
2013-01-28 03:25:10 +04:00
|
|
|
coll = OBJ_NEW(ompi_rte_collective_t);
|
|
|
|
coll->id = ompi_process_info.peer_init_barrier;
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_rte_barrier(coll))) {
|
|
|
|
error = "rte_barrier failed";
|
2008-06-18 19:28:46 +04:00
|
|
|
goto error;
|
|
|
|
}
|
2012-06-27 05:28:28 +04:00
|
|
|
/* wait for barrier to complete */
|
|
|
|
while (coll->active) {
|
|
|
|
opal_progress(); /* block in progress pending events */
|
|
|
|
}
|
|
|
|
OBJ_RELEASE(coll);
|
2012-04-06 18:23:13 +04:00
|
|
|
|
2007-02-09 23:17:37 +03:00
|
|
|
/* check for timing request - get stop time and report elapsed
|
|
|
|
time if so, then start the clock again */
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_enable_timing && 0 == OMPI_PROC_MY_NAME->vpid) {
|
2007-02-09 23:17:37 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2008-06-18 19:28:46 +04:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time to execute barrier %ld usec",
|
2013-01-28 03:25:10 +04:00
|
|
|
(long)OMPI_PROC_MY_NAME->vpid,
|
2007-02-09 23:17:37 +03:00
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
|
|
|
|
Update libevent to the 2.0 series, currently at 2.0.7rc. We will update to their final release when it becomes available. Currently known errors exist in unused portions of the libevent code. This revision passes the IBM test suite on a Linux machine and on a standalone Mac.
This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects.
Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems.
Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct.
I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things:
1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new)
2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it.
There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do.
This commit was SVN r23925.
2010-10-24 22:35:54 +04:00
|
|
|
#if OMPI_ENABLE_PROGRESS_THREADS == 0
|
2007-02-01 21:47:43 +03:00
|
|
|
/* Start setting up the event engine for MPI operations. Don't
|
|
|
|
block in the event library, so that communications don't take
|
|
|
|
forever between procs in the dynamic code. This will increase
|
|
|
|
CPU utilization for the remainder of MPI_INIT when we are
|
2013-01-28 03:25:10 +04:00
|
|
|
blocking on RTE-level events, but may greatly reduce non-TCP
|
2007-02-01 21:47:43 +03:00
|
|
|
latency. */
|
|
|
|
opal_progress_set_event_flag(OPAL_EVLOOP_NONBLOCK);
|
|
|
|
#endif
|
2007-05-01 08:49:36 +04:00
|
|
|
|
|
|
|
/* wire up the mpi interface, if requested. Do this after the
|
|
|
|
non-block switch for non-TCP performance. Do before the
|
|
|
|
polling change as anyone with a complex wire-up is going to be
|
|
|
|
using the oob. */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_init_preconnect_mpi())) {
|
|
|
|
error = "ompi_mpi_do_preconnect_all() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2007-02-01 21:47:43 +03:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* Setup the publish/subscribe (PUBSUB) framework */
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_pubsub_base_framework, 0))) {
|
|
|
|
error = "mca_pubsub_base_open() failed";
|
2008-02-28 04:57:57 +03:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_pubsub_base_select())) {
|
|
|
|
error = "ompi_pubsub_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Setup the dynamic process management (DPM) framework */
|
2013-03-28 01:17:31 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_base_framework_open(&ompi_dpm_base_framework, 0))) {
|
2008-02-28 04:57:57 +03:00
|
|
|
error = "ompi_dpm_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_dpm_base_select())) {
|
|
|
|
error = "ompi_dpm_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2008-03-31 23:37:37 +04:00
|
|
|
|
2009-07-07 22:32:14 +04:00
|
|
|
/* Determine the overall threadlevel support of all processes
|
|
|
|
in MPI_COMM_WORLD. This has to be done before calling
|
|
|
|
coll_base_comm_select, since some of the collective components
|
|
|
|
e.g. hierarch, might create subcommunicators. The threadlevel
|
|
|
|
requested by all processes is required in order to know
|
|
|
|
which cid allocation algorithm can be used. */
|
|
|
|
if ( OMPI_SUCCESS !=
|
|
|
|
( ret = ompi_comm_cid_init ())) {
|
|
|
|
error = "ompi_mpi_init: ompi_comm_cid_init failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2008-03-31 23:37:37 +04:00
|
|
|
/* Init coll for the comms. This has to be after dpm_base_select,
|
|
|
|
(since dpm.mark_dyncomm is not set in the communicator creation
|
|
|
|
function else), but before dpm.dyncom_init, since this function
|
|
|
|
might require collective for the CID allocation. */
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_coll_base_comm_select(MPI_COMM_WORLD))) {
|
|
|
|
error = "mca_coll_base_comm_select(MPI_COMM_WORLD) failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_coll_base_comm_select(MPI_COMM_SELF))) {
|
|
|
|
error = "mca_coll_base_comm_select(MPI_COMM_SELF) failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2007-02-01 21:47:43 +03:00
|
|
|
/* Check whether we have been spawned or not. We introduce that
|
|
|
|
at the very end, since we need collectives, datatypes, ptls
|
|
|
|
etc. up and running here.... */
|
2008-02-28 04:57:57 +03:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_dpm.dyn_init())) {
|
2004-09-29 16:41:55 +04:00
|
|
|
error = "ompi_comm_dyn_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
/*
|
|
|
|
* Startup the Checkpoint/Restart Mech.
|
|
|
|
* Note: Always do this so tools don't hang when
|
|
|
|
* in a non-checkpointable build
|
|
|
|
*/
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_cr_init())) {
|
|
|
|
error = "ompi_cr_init";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2010-11-30 20:15:08 +03:00
|
|
|
/* Undo OPAL calling opal_progress_event_users_increment() during
|
|
|
|
opal_init, to get better latency when not using TCP. Do
|
2013-01-28 03:25:10 +04:00
|
|
|
this *after* dyn_init, as dyn init uses lots of RTE
|
2010-11-30 20:15:08 +03:00
|
|
|
communication and we don't want to hinder the performance of
|
|
|
|
that code. */
|
|
|
|
opal_progress_event_users_decrement();
|
|
|
|
|
2008-07-23 07:43:31 +04:00
|
|
|
/* see if yield_when_idle was specified - if so, use it */
|
2013-03-28 01:09:41 +04:00
|
|
|
opal_progress_set_yield_when_idle(ompi_mpi_yield_when_idle);
|
2008-07-23 07:43:31 +04:00
|
|
|
|
2006-11-22 05:06:52 +03:00
|
|
|
/* negative value means use default - just don't do anything */
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_mpi_event_tick_rate >= 0) {
|
|
|
|
opal_progress_set_event_poll_rate(ompi_mpi_event_tick_rate);
|
2006-11-22 05:06:52 +03:00
|
|
|
}
|
2007-05-01 08:49:36 +04:00
|
|
|
|
2007-02-01 21:47:43 +03:00
|
|
|
/* At this point, we are fully configured and in MPI mode. Any
|
|
|
|
communication calls here will work exactly like they would in
|
|
|
|
the user's code. Setup the connections between procs and warm
|
2007-02-09 23:17:37 +03:00
|
|
|
them up with simple sends, if requested */
|
2005-03-30 05:40:26 +04:00
|
|
|
|
2011-05-05 22:31:07 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_mpiext_init())) {
|
2010-08-17 08:44:22 +04:00
|
|
|
error = "ompi_mpiext_init";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2011-03-07 19:45:45 +03:00
|
|
|
/* Fall through */
|
2007-02-01 21:47:43 +03:00
|
|
|
error:
|
|
|
|
if (ret != OMPI_SUCCESS) {
|
2010-03-14 03:09:55 +03:00
|
|
|
/* Only print a message if one was not already printed */
|
|
|
|
if (NULL != error) {
|
|
|
|
const char *err_msg = opal_strerror(ret);
|
2013-02-13 01:10:11 +04:00
|
|
|
/* If RTE was not setup yet, don't use opal_show_help */
|
2013-01-28 03:25:10 +04:00
|
|
|
if (rte_setup) {
|
2013-02-13 01:10:11 +04:00
|
|
|
opal_show_help("help-mpi-runtime",
|
2010-03-14 03:09:55 +03:00
|
|
|
"mpi_init:startup:internal-failure", true,
|
|
|
|
"MPI_INIT", "MPI_INIT", error, err_msg, ret);
|
|
|
|
} else {
|
|
|
|
opal_show_help("help-mpi-runtime",
|
|
|
|
"mpi_init:startup:internal-failure", true,
|
|
|
|
"MPI_INIT", "MPI_INIT", error, err_msg, ret);
|
|
|
|
}
|
2008-05-20 01:57:54 +04:00
|
|
|
}
|
2007-02-01 21:47:43 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-12-07 16:09:07 +03:00
|
|
|
/* Initialize the registered datarep list to be empty */
|
|
|
|
OBJ_CONSTRUCT(&ompi_registered_datareps, opal_list_t);
|
|
|
|
|
Deal with the ticket #1239 and #712. This will upgrade the Open MPI support
for the F90 type create functions to the requirements of MPI 2.1 standard.
Advice to implementors. An application may often repeat a call to
MPI_TYPE_CREATE_F90_xxxx with the same combination of (xxxx,p,r).
The application is not allowed to free the returned predefined, unnamed
datatype handles. To prevent the creation of a potentially huge amount of
handles, the MPI implementation should return the same datatype handle for
the same (REAL/COMPLEX/INTEGER,p,r) combination. Checking for the
combination (p,r) in the preceding call to MPI_TYPE_CREATE_F90_xxxx and
using a hash-table to find formerly generated handles should limit the
overhead of finding a previously generated datatype with same combination
of (xxxx,p,r). (End of advice to implementors.)
This commit fixes trac:1239, and #712.
This commit was SVN r19458.
The following Trac tickets were found above:
Ticket 1239 --> https://svn.open-mpi.org/trac/ompi/ticket/1239
2008-08-31 22:36:32 +04:00
|
|
|
/* Initialize the arrays used to store the F90 types returned by the
|
|
|
|
* MPI_Type_create_f90_XXX functions.
|
|
|
|
*/
|
|
|
|
OBJ_CONSTRUCT( &ompi_mpi_f90_integer_hashtable, opal_hash_table_t);
|
|
|
|
opal_hash_table_init(&ompi_mpi_f90_integer_hashtable, 16 /* why not? */);
|
|
|
|
|
|
|
|
OBJ_CONSTRUCT( &ompi_mpi_f90_real_hashtable, opal_hash_table_t);
|
|
|
|
opal_hash_table_init(&ompi_mpi_f90_real_hashtable, FLT_MAX_10_EXP);
|
|
|
|
|
|
|
|
OBJ_CONSTRUCT( &ompi_mpi_f90_complex_hashtable, opal_hash_table_t);
|
|
|
|
opal_hash_table_init(&ompi_mpi_f90_complex_hashtable, FLT_MAX_10_EXP);
|
2010-08-17 08:44:22 +04:00
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* All done. Wasn't that simple? */
|
2004-02-05 04:52:56 +03:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
ompi_mpi_initialized = true;
|
2004-11-20 22:12:43 +03:00
|
|
|
|
Bring the timing instrumentation to the trunk.
If you want to look at our launch and MPI process startup times, you can do so with two MCA params:
OMPI_MCA_orte_timing: set it to anything non-zero and you will get the launch time for different steps in the job launch procedure. The degree of detail depends on the launch environment. rsh will provide you with the average, min, and max launch time for the daemons. SLURM block launches the daemon, so you only get the time to launch the daemons and the total time to launch the job. Ditto for bproc. TM looks more like rsh. Only those four environments are currently supported - anyone interested in extending this capability to other environs is welcome to do so. In all cases, you also get the time to setup the job for launch.
OMPI_MCA_ompi_timing: set it to anything non-zero and you will get the time for mpi_init to reach the compound registry command, the time to execute that command, the time to go from our stage1 barrier to the stage2 barrier, and the time to go from the stage2 barrier to the end of mpi_init. This will be output for each process, so you'll have to compile any statistics on your own. Note: if someone develops a nice parser to do so, it would be really appreciated if you could/would share!
This commit was SVN r12302.
2006-10-25 19:27:47 +04:00
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
2013-03-28 01:09:41 +04:00
|
|
|
if (ompi_enable_timing && 0 == OMPI_PROC_MY_NAME->vpid) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2009-01-07 00:30:12 +03:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from barrier to complete mpi_init %ld usec",
|
2013-01-28 03:25:10 +04:00
|
|
|
(long)OMPI_PROC_MY_NAME->vpid,
|
2006-11-03 19:04:40 +03:00
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
Bring the timing instrumentation to the trunk.
If you want to look at our launch and MPI process startup times, you can do so with two MCA params:
OMPI_MCA_orte_timing: set it to anything non-zero and you will get the launch time for different steps in the job launch procedure. The degree of detail depends on the launch environment. rsh will provide you with the average, min, and max launch time for the daemons. SLURM block launches the daemon, so you only get the time to launch the daemons and the total time to launch the job. Ditto for bproc. TM looks more like rsh. Only those four environments are currently supported - anyone interested in extending this capability to other environs is welcome to do so. In all cases, you also get the time to setup the job for launch.
OMPI_MCA_ompi_timing: set it to anything non-zero and you will get the time for mpi_init to reach the compound registry command, the time to execute that command, the time to go from our stage1 barrier to the stage2 barrier, and the time to go from the stage2 barrier to the end of mpi_init. This will be output for each process, so you'll have to compile any statistics on your own. Note: if someone develops a nice parser to do so, it would be really appreciated if you could/would share!
This commit was SVN r12302.
2006-10-25 19:27:47 +04:00
|
|
|
}
|
2006-11-03 19:04:40 +03:00
|
|
|
|
2004-02-13 16:56:55 +03:00
|
|
|
return MPI_SUCCESS;
|
2004-01-15 09:08:25 +03:00
|
|
|
}
|