1
1
Граф коммитов

41 Коммитов

Автор SHA1 Сообщение Дата
Jeff Squyres
4d8a187450 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-14 23:44:31 +00:00
Jeff Squyres
5ac6a4387c Fix MPI_CART_GET to take an array of logicals for the periods argument
(not integers)

This commit was SVN r19099.
2008-07-30 20:29:23 +00:00
Jeff Squyres
213679488a Fix F90 interface for MPI_CART_CREATE. Thanks to Michal Charemza for
reporting the problem.

This commit was SVN r17395.
2008-02-07 12:46:32 +00:00
Rainer Keller
43ce11d578 - Fortran 90 standard requires no name at:
end interface
   (ifort complains, pgf90 chokes on it).

This commit was SVN r14785.
2007-05-29 15:37:44 +00:00
Jeff Squyres
86f48bf0d7 Fix ordering of dimensions for status arrays. Thanks to Randy Bramley
for noticing the problem.

This commit was SVN r14591.
2007-05-05 05:02:02 +00:00
Jeff Squyres
53c4bcccd5 Fix a problem noted by Tim Campbell: the type of the first parameter
to the F90 binding for MPI_INITIALIZED was wrong (should have been
logical, not integer).

Fixes trac:782.

This commit was SVN r13170.

The following Trac tickets were found above:
  Ticket 782 --> https://svn.open-mpi.org/trac/ompi/ticket/782
2007-01-17 22:44:47 +00:00
Jeff Squyres
bc93583184 Fix the SIZEOF implementation for complex's. We want to output the
size of the complex type as determined by configure; not the size of
the next larger complex type (i.e., a complex*N is 2 real*(N/2)'s, not
2 real*N's).

This commit was SVN r12421.
2006-11-03 15:52:46 +00:00
Jeff Squyres
520147f209 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 15:07:09 +00:00
Jeff Squyres
9a679644c2 Arf. Don't output the body of the WTICK or WTIME functions in the
module header if we're not doing small.

This commit was SVN r10475.
2006-06-22 13:20:01 +00:00
Jeff Squyres
723b6e50a9 George suggested a better way to make WTICK and WTIME -- be consistent
with the other methodology even if there are no choice buffers and no
special constants.  But it keeps the Makefile.am simple and the
methodology consistent.

This commit was SVN r10462.
2006-06-21 19:07:09 +00:00
Jeff Squyres
720f38efc5 Fix for MPI_WTICK / MPI_WTIME F90 bindings issue. The previous hope
was that declaring the type of MPI_WTICK and MPI_TIME in mpif-common.h
would allow the F90 bindings to call through to the back end f77
function and have the right return type.  But upon reflection, that's
silly -- we were just declaring the variables MPI_WTICK and MPI_WTIME
that were of type double precision.  Duh.

So add some fixed (non-generated) wrapper F90 functions to call the
back-end *C* MPI_WTICK and MPI_TIME functions (vs. the back end *F77*
functions).  We have to call the back-end C functions because there's
a name conflict if we try to call the back-end F77 functions -- for
the same reasons that we can't "implicitly" define MPI_WTIME and
MPI_WTICK in the f90 module, we can't call such an implicitly-defined
function.  So we had to add new back-end C functions that are directly
callable from Fortran, the easiest implementation of which was to
provide 4 one-line functions for each (rather than muck around with
weak symbols).

This commit was SVN r10448.
2006-06-21 13:44:20 +00:00
Jeff Squyres
8b8bf363c4 Add missing svn:executable property
This commit was SVN r10283.
2006-06-10 10:59:01 +00:00
Jeff Squyres
02d8a46d5f Fix for ticket #89.
* Change the type of Fortan's MPI_STATUSES_IGNORE to double complex
so that it will never possibly be mistaken for a real status (i.e.,
integer(MPI_STATUS_SIZE)), particularly in the F90 bindings.  See
comment in mpif-common.h explaining this (analogous argument to
MPI_ARGVS_NULL for MPI_COMM_SPAWN_MULTIPLE).
 * Add second interfaces for the following functions that take a double
complex (i.e., MPI_STATUSES_IGNORE).  This required adding the second
interface in mpi-f90-interfaces.h[.sh] and then generating new wrapper
functions to call the back-end F77 function for each of these four, so
we added 4 new files in ompi/mpi/f90/scripts/ and updated the various
Makefile.am's to match:
   * MPI_TESTALL
   * MPI_TESTSOME
   * MPI_WAITALL
   * MPI_WAITSOME

The XSL is now not in sync with the scripts.  Although I suppose that
that is becoming less and less important (because it does not impact
the end user at all -- to be 100% explicit, no release should ever be
held up because the XSL is out of sync), but it will probably be
important when we go to fix the "large" interface; so it's still worth
fixing... for now...

This commit was SVN r10281.
2006-06-09 23:40:20 +00:00
Craig E Rasmussen
4cd13f07c4 Changed to use procedure alias (when names too long).
This commit was SVN r10144.
2006-05-31 15:04:38 +00:00
Jeff Squyres
5f356edb64 Bring over changes from the /tmp/fortran-stuff series:
- Make the F90 bindings compile and link properly with gfortran 4.0,
  4.1, Intel 9.0, PGI 6.1, Sun (don't know version offhand -- the most
  current as of this writing, I think), and NAG 5.2, although some
  have limitations (e.g., NAG can't seem to handle the medium and
  large sizes)
- Building the F90 "small" module size is now the default, even for
  developers
- Split up mpif.h into multiple files because parts of it were toxic
  to the F90 bindings
- Properly specify unsized/unshaped arrays to make the bindings work
  on all known compilers
- Make ompi_info show Fortran 90 bindings size
- XML somewhat lags the generated scripts as of this commit, but
  functionality was my main goal -- the XML can be updated later (if
  at all).

This commit was SVN r10118.
2006-05-30 14:37:41 +00:00
Jeff Squyres
faf63c68f8 Merge over from the /tmp/fortran-stuff branch
- split mpif.h into mpif.h and mpif-common.h[.in]
- mpif-common.h is included by various f90 things and contains output
  from configure
- mpif.h defines some f77-specific stuff and then includes
  mpif-common.h 

This commit was SVN r9997.
2006-05-20 02:15:49 +00:00
Jeff Squyres
95c1f12b97 Missed this one yesterday
This commit was SVN r9958.
2006-05-17 16:31:25 +00:00
Jeff Squyres
d3ff507bc2 Add explicit path to mpi-f90-interfaces.h.sh. Blast; I could have
sworn that I committed this yesterday.

This commit was SVN r9935.
2006-05-16 15:00:23 +00:00
Jeff Squyres
171585ff34 Ensure to put implicit none *before* the header file includes
This commit was SVN r9923.
2006-05-15 19:31:01 +00:00
Craig E Rasmussen
13c113b39c Changed INOUT to IN in MPI_*_SET_ATTR functions.
This commit was SVN r9922.
2006-05-15 17:13:20 +00:00
Craig E Rasmussen
0c584d783e Changes MPI_Intercomm_merge high variable from integer to logical
This commit was SVN r9782.
2006-05-01 18:58:05 +00:00
Jeff Squyres
22dbda116e Add in oodles of missing files
This commit was SVN r9767.
2006-04-28 02:22:19 +00:00
Craig E Rasmussen
9333a2628b Added counter to output name and changed bool Fortran type to logical
This commit was SVN r9764.
2006-04-27 22:46:48 +00:00
Jeff Squyres
0556c129df Fix MPI_*_GET_ATTR flag parameter to be of type logical. Thanks to
Michael Kluskens for pointing this out.

This commit was SVN r9676.
2006-04-21 04:31:49 +00:00
Craig E Rasmussen
8646604497 Fixed to match Jeff S's changes to mpi-f90-interfaces.h.sh
This commit was SVN r9674.
2006-04-20 21:18:04 +00:00
Jeff Squyres
f8e634d6ca Bring over /tmp/f90-stuff branch to the trunk.
svn merge -r 9453:9609 https://svn.open-mpi.org/svn/ompi/tmp/f90-stuff .

Several improvements over the current F90 MPI bindings:

- The capability to make 4 sizes of the F90 bindings:
  - trivial: only the F90-specific MPI functions (sizeof and a few
    others)
  - small: (this is the default) all MPI functions that do not take
    choice buffers
  - medium: small + all MPI functions that take one choice buffer
    (e.g., MPI_SEND)
  - large: all MPI functions, but those that take 2 choice buffers
    (e.g., MPI_GATHER) only allow both buffers to be of the same type
- Remove all non-standard MPI types (LOGICAL*x, CHARACTER*x)
- Remove use of selected_*_kind() and only use MPI-defined types
  (INTEGER*x, etc.)
- Decrease complexity of the F90 configure and build system

This commit was SVN r9610.
2006-04-11 03:33:38 +00:00
Jeff Squyres
2cceba7230 Fix to George's and my bugs. :-) A comedy of errors made the test
case still compile properly, even though these bindings were wrong.  :-(

- Both interface functions are necessary.
- I accidentally had a subroutine interface named the same thing as the
  back-end F77 function -- a definite no-no.  Ensure that all F90
  interface functions have a suffix to make them different than the
  back-end F77 function names.
- Also parameterize the output() subroutine on the type of the argvs
  parameter to switch between the character arrays and the integer.

This commit was SVN r9202.
2006-03-04 19:36:13 +00:00
George Bosilca
a649ebc7c6 MPI_Comm_spawn_multiple does not need to have 2 definitions. Moreover,
this function is not allowed to call itself recursively.

This commit was SVN r9201.
2006-03-04 19:22:55 +00:00
Jeff Squyres
9d119109b6 Change the types of some of the "special" constants in mpif.h so that
they will match the prototypes in the [styictly-typed] MPI F90
bindings.  Specifically, fix up MPI_COMM_SPAWN and
MPI_COMM_SPAWN_MULTIPLE so that the constants MPI_ARGV_NULL,
MPI_ERRCODES_IGNORE, and MPI_ARGVS_NULL can be used in the F90
bindings.  Thanks to Michael Kluskens for pointing this out to us.

Some work still remains in the F90 bindings -- we are missing all
places where choice buffers can be of type CHARACTER.

This commit was SVN r9198.
2006-03-04 14:24:44 +00:00
Jeff Squyres
780154469b Prettyprint
This commit was SVN r9046.
2006-02-15 13:19:42 +00:00
Jeff Squyres
c4cc1528a7 Output this information during the build to help with user and
developer debugging.

This commit was SVN r9032.
2006-02-14 13:29:18 +00:00
Rainer Keller
bf0892bb32 - Implement correct Fortran Logical-handling in f77/f90 interface in
case of:
    sizeof(MPI_Flogical) != sizeof (int)
  and
    Fortran value of .TRUE. != 1
  as is often the case.
- Check in configure the value of .TRUE., the C-type coresponding to
  logical and check, that fortran compiler does not do something strange
  with arrays of logicals
- Convert all occurrences of logicals in the fortran wrappers, only
  in case it is needed.
  *Please note* Implementation of MPI_Cart_sub needed special treatment.
- Output these value in ompi_info -a
- Clean up the prototypes_mpi.h to just have a single definition and
  thereby deleting the necessity for prototypes_pmpi.h

- configured, compiled and tested with F90-program, which uses
  MPI_Cart_create and MPI_Cart_get:
  linux ia32, gcc (no testing, as no f90)
  linux ia32, gcc --disable-mpi-f77 --disable-mpi-f90 (had a bug there)
  linux ia32, icc-8.1
  linux opteron, gcc-3.3.5, pgcc, pathccx/pathf90 (tested just
pgi-compiler)
  linux em64t, gcc, icc-8.1 (tested just icc)

This commit was SVN r8254.
2005-11-24 16:52:35 +00:00
Jeff Squyres
24b9de292c Fix for [righteous] compiler warnings from xlf90 compiler on OSX
10.3.  Specifically define what the parameter type is, and mark its
intent. 

This commit was SVN r8124.
2005-11-11 23:18:59 +00:00
Jeff Squyres
bacfb4fa2b Remove the generated F90 interfaces for all the "2 buffer" MPI API
functions (e.g., MPI_REDUCE).  We don't generate the back-end
subroutines for them (because it makes an expontential number of
subroutines, and compilers literally will segv), so we shouldn't
generate the f90 interfaces for them, either.  This allows user's MPI
F90 apps to automaitcally fall through to the F77 bindings for these
functions.

This commit was SVN r8094.
2005-11-10 16:04:39 +00:00
Jeff Squyres
6e08072113 Fix for the interface name for MPI_File_write_ordered_begin -- the
name was changed to shorten it too early (and then not restored), so
the "interface" name was not output correctly into
mpi-f90-interfaces.h.  Change to make it like the other long functions
-- temporarily change it to a shorter name while outputing the
subroutines, and then revert it when outputting the end interface.

This commit was SVN r8086.
2005-11-10 14:10:20 +00:00
Jeff Squyres
42ec26e640 Update the copyright notices for IU and UTK.
This commit was SVN r7999.
2005-11-05 19:57:48 +00:00
Jeff Squyres
f47c272986 Fix for the max-31-F90-symbol-limit problem: keep the interface names
the same (since those are both mandated by MPI and <31 characters),
but change some of the back-end subroutine names so that they are <31
characters and therefore obey the F90 standard.  Remove an outdated /
useless (and confusing) script.

This commit was SVN r7764.
2005-10-14 19:50:30 +00:00
Brian Barrett
ed56e743b7 * update configure.ac to use the modern version of AC_INIT and
AM_INIT_AUTOMAKE, instead of the deprecated version.
* Work around dumbness in modern AC_INIT that requires the version
  number to be set at autoconf time (instead of at configure time, as
  it was before).  Set the version number, minus the subversion r number,
  at autoconf time.  Override the internal variables to include the r
  number (if needed) at configure time.  Basically, the right thing
  should always happen.  The only place it might not is the version
  reported as part of configure --help will not have an r number.
* Since AM_INIT_AUTOMAKE taks a list of options, no need to specify
  them in all the Makefile.am files.
* Addes support for subdir-objects, meaning that object files are put
  in the directory containing source files, even if the Makefile.am is
  in another directory.  This should start making it feasible to
  reduce the number of Makefile.am files we have in the tree, which
  will greatly reduce the time to run autogen and configure.

This commit was SVN r7211.
2005-09-07 05:54:53 +00:00
Brian Barrett
d75bde8b35 * make sure proceedure names are not longer than 31 characters
This commit was SVN r7037.
2005-08-25 16:42:38 +00:00
Jeff Squyres
4eba48b430 Bunches of fixes for the f90 bindings
- fix the --with-f90-max-array-dim configure switch
- fix configure test to find the supported f90 linker switch to find
  fortran modules
- Unbelievably, some versions of sh (cough cough Solaris 9 cough
  cough) actually seem to internally perform a "cd" into a
  subdirectory when you run "./foo/bar", such that if you try to
  source a script in the top-level directory in the bar script (i.e.,
  ". some_script" in the bar script), it will try to run it in the
  "foo" subdirectory, rather than the top-level directory!  #$@#$%#$%
  So we have to pass in the pwd to the scripts so that they know where
  some_script is.
- Reworked much of ompi/mpi/f90/Makefile.am for lots of reasons.  See
  the internal comments (mostly having to do with dependency stuff --
  Libtool does not apparently support F90, so we can only build the
  F90 library statically.

This commit was SVN r6993.
2005-08-24 02:11:02 +00:00
Jeff Squyres
4ab17f019b Rename src -> ompi
This commit was SVN r6269.
2005-07-02 13:43:57 +00:00