Re: [OMPI devel] Changes to classes in OMPI
My concern is that increasing the number of interfaces will not make the code thread safe, as in most cases thread safety is not only a matter of using a _mt version of the basic class object but a matter of a careful manipulation of higher level concepts. We can hardly use the lack of the _MT function as a reason for not having thread safety in the code. We did have the thread safety a while back without the support of _MT version of all the basic classes. So I really wonder what is the rationale behind such an intrusive change of the codebase? George. On Oct 8, 2013, at 18:14 , Ralph Castain wrote: > Hi folks > > This was one item from the last devel meeting that can be done independent of > other things: > > • resolution: all opal and orte (and possibly ompi) classes > need to have a thread safe and thread-free interface > • _st suffix: single thread (i.e., not thread safe > variant) > • _mt suffix: multi thread (i.e., thread safe variant) > • for functions that have both st/mt, they will > *both* have suffixes > • other functions (that do not have st/mt > versions) will be naked names > • need to rename all classes that have locking enabled > already (e.g., opal_free_list) > • so today, we go rename all the functions (e.g., > opal_free_list functions get _mt suffix) throughout the code base > • as someone needs the _st version, they go create it > and use it as they want to > • Ralph will do the orte classes > • Aurelien will do this for the ompi classes > > I believe some of these have been done - I will take care of the ORTE classes > this week, so consider this a "heads up" for that change. > Ralph > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] 32 bit build breakage in oshmem
Hi Jeff, I`m unable to reproduce this fail with gcc and -m32 flags. I added same command line to jenkins (and in jenkins we trust) - and it passed on RHEL 6.4 with stock gcc. Please check that you run it on latest trunk and please provide a gcc version if it is not a stock one. Thanks M On Tue, Oct 8, 2013 at 4:52 PM, Jeff Squyres (jsquyres) wrote: > On RHEL6.4 with: > > "CFLAGS=-g -pipe -m32" CXXFLAGS=-m32 FFLAGS=-m32 FCFLAGS=-m32 > --with-wrapper-cflags=-m32 --with-wrapper-cxxflags=-m32 > --with-wrapper-fflags=-m32 --with-wrapper-fcflags=-m32 > --enable-mpirun-prefix-by-default --disable-dlopen --enable-mpi-cxx > > I get a ton of compile errors in oshmem/op/op.c, like this one: > > - > op/op.c:194:1: note: in expansion of macro 'FUNC_OP_CREATE' > FUNC_OP_CREATE(max, freal16, ompi_fortran_real16_t, __max_op); > op/op.c:135:15: error: 'b' undeclared (first use in this function) > type *b = (type *) out; > \ >^ > - > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] More oshmem compile errors
Hi, We have icc test in jenkins and it passes. What icc version do you use and exact command line to configure? Is it latest trunk? Thanks M On Tue, Oct 8, 2013 at 5:37 PM, Jeff Squyres (jsquyres) wrote: > With icc, getting errors about pointer math with (void*) types. See > attached. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] Changes to classes in OMPI
IIRC, the concern was with where the thread safety should reside. Some classes (e.g., opal_list) were littered with thread locks for every operation. So if someone implemented thread protection at a higher level (e.g., protecting the list while cycling thru it), then all these lower-level lock/unlock operations were just a waste of cycles. However, some people felt that there were places where it helped to have the locking down below. So this was the compromise - use the version that fits your situation. Personally, I'm not wild about it, but I can live with it. I'd prefer to see no lock/unlock calls in the classes themselves as they are too atomistic, and would have opted for providing a macro version of the function that included the appropriate lock/unlocks around the function. Anyway, that was the thinking at the meeting last June. On Oct 9, 2013, at 1:40 AM, George Bosilca wrote: > My concern is that increasing the number of interfaces will not make the code > thread safe, as in most cases thread safety is not only a matter of using a > _mt version of the basic class object but a matter of a careful manipulation > of higher level concepts. > > We can hardly use the lack of the _MT function as a reason for not having > thread safety in the code. We did have the thread safety a while back without > the support of _MT version of all the basic classes. > > So I really wonder what is the rationale behind such an intrusive change of > the codebase? > > George. > > On Oct 8, 2013, at 18:14 , Ralph Castain wrote: > >> Hi folks >> >> This was one item from the last devel meeting that can be done independent >> of other things: >> >> • resolution: all opal and orte (and possibly ompi) classes >> need to have a thread safe and thread-free interface >> • _st suffix: single thread (i.e., not thread safe >> variant) >> • _mt suffix: multi thread (i.e., thread safe variant) >> • for functions that have both st/mt, they will >> *both* have suffixes >> • other functions (that do not have st/mt >> versions) will be naked names >> • need to rename all classes that have locking enabled >> already (e.g., opal_free_list) >> • so today, we go rename all the functions (e.g., >> opal_free_list functions get _mt suffix) throughout the code base >> • as someone needs the _st version, they go create it >> and use it as they want to >> • Ralph will do the orte classes >> • Aurelien will do this for the ompi classes >> >> I believe some of these have been done - I will take care of the ORTE >> classes this week, so consider this a "heads up" for that change. >> Ralph >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] More oshmem compile errors
Doing pointer math with (void*) is not defined. For example: http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html says that gcc allows it, but this is in the "C Extensions" part of the manual. I suspect that the latest icc allows it by the same rationale, but it's still technically wrong. I'm just doing a simple build like this: ./configure CC=icc CXX=icpc FC=ifort ... I note that it passes with icc 14.0, but fails with 12.x. I think (void*) pointer math should be avoided, even if modern compilers allow it. On Oct 9, 2013, at 8:01 AM, Mike Dubman wrote: > Hi, > We have icc test in jenkins and it passes. > What icc version do you use and exact command line to configure? > Is it latest trunk? > > Thanks > M > > > On Tue, Oct 8, 2013 at 5:37 PM, Jeff Squyres (jsquyres) > wrote: > With icc, getting errors about pointer math with (void*) types. See attached. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] Automake/m4 issue: r29407 - trunk/oshmem/mca/atomic/mxm
This commit results in several warnings in recent versions of Automake (e.g.,
1.13.3). Please see the Automake docs for how you're supposed to use
AC_COMPILE_IFELSE with AC_LANG_SOURCE.
-
configure.ac:1089: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected
in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
config/ompi_check_mxm.m4:16: OMPI_CHECK_MXM is expanded from...
oshmem/mca/atomic/mxm/configure.m4:14: MCA_oshmem_atomic_mxm_CONFIG is expanded
from...
config/ompi_mca.m4:570: MCA_CONFIGURE_M4_CONFIG_COMPONENT is expanded from...
config/ompi_mca.m4:351: MCA_CONFIGURE_FRAMEWORK is expanded from...
config/ompi_mca.m4:251: MCA_CONFIGURE_PROJECT is expanded from...
config/ompi_mca.m4:38: OMPI_MCA is expanded from...
configure.ac:1089: the top level
-
On Oct 9, 2013, at 7:52 AM, svn-commit-mai...@open-mpi.org wrote:
> Author: amikheev (Alex Mikheev)
> Date: 2013-10-09 07:52:04 EDT (Wed, 09 Oct 2013)
> New Revision: 29407
> URL: https://svn.open-mpi.org/trac/ompi/changeset/29407
>
> Log:
> fixed check availability of mxm atomics. No need to run the code. succesful
> compilation is enough to detect availability.
> reviewed by miked
>
> Text files modified:
> trunk/oshmem/mca/atomic/mxm/configure.m4 | 2 +-
>
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Modified: trunk/oshmem/mca/atomic/mxm/configure.m4
> ==
> --- trunk/oshmem/mca/atomic/mxm/configure.m4 Wed Oct 9 06:06:39 2013
> (r29406)
> +++ trunk/oshmem/mca/atomic/mxm/configure.m4 2013-10-09 07:52:04 EDT (Wed,
> 09 Oct 2013) (r29407)
> @@ -21,7 +21,7 @@
>CPPFLAGS="$CPPFLAGS -I$ompi_check_mxm_dir/include"
>LDFLAGS="$LDFLAGS -L$ompi_check_mxm_dir/lib"
>LIBS="$LIBS -lmxm"
> - AC_TRY_RUN([
> + AC_COMPILE_IFELSE([
> #include
> int main() {
> if (mxm_get_version() < MXM_VERSION(1,5) )
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] 32 bit build breakage in oshmem
See https://svn.open-mpi.org/trac/ompi/changeset/29408. On Oct 9, 2013, at 8:00 AM, Mike Dubman wrote: > Hi Jeff, > > I`m unable to reproduce this fail with gcc and -m32 flags. > I added same command line to jenkins (and in jenkins we trust) - and it > passed on RHEL 6.4 with stock gcc. > > Please check that you run it on latest trunk and please provide a gcc version > if it is not a stock one. > > Thanks > M > > > > > > On Tue, Oct 8, 2013 at 4:52 PM, Jeff Squyres (jsquyres) > wrote: > On RHEL6.4 with: > > "CFLAGS=-g -pipe -m32" CXXFLAGS=-m32 FFLAGS=-m32 FCFLAGS=-m32 > --with-wrapper-cflags=-m32 --with-wrapper-cxxflags=-m32 > --with-wrapper-fflags=-m32 --with-wrapper-fcflags=-m32 > --enable-mpirun-prefix-by-default --disable-dlopen --enable-mpi-cxx > > I get a ton of compile errors in oshmem/op/op.c, like this one: > > - > op/op.c:194:1: note: in expansion of macro 'FUNC_OP_CREATE' > FUNC_OP_CREATE(max, freal16, ompi_fortran_real16_t, __max_op); > op/op.c:135:15: error: 'b' undeclared (first use in this function) > type *b = (type *) out; \ >^ > - > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] oshmem configure options
Mellanox -- Is anyone working on the oshmem issue that I identified in https://svn.open-mpi.org/trac/ompi/changeset/29165? See https://svn.open-mpi.org/trac/ompi/browser/trunk/config/oshmem_configure_options.m4?rev=29165#L82 for details. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] Java bindings
First, what is going on with the mpi forum? The site seems to be down. Anyway, has there been any activity in using MPI codes with Map-Reduce jobs, which was the original justification for bringing in the java bindings? I'm just curious. Thanks in advance!
Re: [OMPI devel] Java bindings
Yes, I am curious too regarding the architecture of the applications. Will it be Map-Reduce functionality implemented using Java but for communications MPI will be used? Or Will the Hadoop be integrated with MPI (using the Java-Bindings)? Bibrak On Wed, Oct 9, 2013 at 9:49 PM, Tom Vacek wrote: > First, what is going on with the mpi forum? The site seems to be down. > Anyway, has there been any activity in using MPI codes with Map-Reduce > jobs, which was the original justification for bringing in the java > bindings? I'm just curious. Thanks in advance! > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] Java bindings
Right. I was suspecting that MPI would be used like an external interface to bridge parts of algorithms that can't be efficiently expressed in MR. MR at present has some limitations, but it is great for some bread-and-butter tasks. On Wed, Oct 9, 2013 at 11:54 AM, Bibrak Qamar wrote: > Yes, I am curious too regarding the architecture of the applications. > > Will it be Map-Reduce functionality implemented using Java but for > communications MPI will be used? > > Or Will the Hadoop be integrated with MPI (using the Java-Bindings)? > > Bibrak > > > > On Wed, Oct 9, 2013 at 9:49 PM, Tom Vacek wrote: > >> First, what is going on with the mpi forum? The site seems to be down. >> Anyway, has there been any activity in using MPI codes with Map-Reduce >> jobs, which was the original justification for bringing in the java >> bindings? I'm just curious. Thanks in advance! >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] Java bindings
Actually, yes! Now that the bindings have been updated, we have several projects getting underway - just had a conference call about one of them this morning :-) On Oct 9, 2013, at 9:49 AM, Tom Vacek wrote: > First, what is going on with the mpi forum? The site seems to be down. > Anyway, has there been any activity in using MPI codes with Map-Reduce jobs, > which was the original justification for bringing in the java bindings? I'm > just curious. Thanks in advance! > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Java bindings
Just curious, are these projects open ? Bibrak Qamar On Wed, Oct 9, 2013 at 10:30 PM, Ralph Castain wrote: > Actually, yes! Now that the bindings have been updated, we have several > projects getting underway - just had a conference call about one of them > this morning :-) > > > On Oct 9, 2013, at 9:49 AM, Tom Vacek wrote: > > > First, what is going on with the mpi forum? The site seems to be down. > Anyway, has there been any activity in using MPI codes with Map-Reduce > jobs, which was the original justification for bringing in the java > bindings? I'm just curious. Thanks in advance! > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] Java bindings
One use-case is in an open source code base, another I'm not sure about but may be. I expect both of those will surface (in one way or another) by end of the year. The other one is proprietary for now - don't know their long-term plans. On Oct 9, 2013, at 10:33 AM, Bibrak Qamar wrote: > Just curious, are these projects open ? > > Bibrak Qamar > > > > On Wed, Oct 9, 2013 at 10:30 PM, Ralph Castain wrote: > Actually, yes! Now that the bindings have been updated, we have several > projects getting underway - just had a conference call about one of them this > morning :-) > > > On Oct 9, 2013, at 9:49 AM, Tom Vacek wrote: > > > First, what is going on with the mpi forum? The site seems to be down. > > Anyway, has there been any activity in using MPI codes with Map-Reduce > > jobs, which was the original justification for bringing in the java > > bindings? I'm just curious. Thanks in advance! > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
