Re: [OMPI devel] RFC: warn if running a debug build
Let me rephrase that. i will set the parameter in the etc/openmpi-mca-params.conf of my install directory, and i will very likely forget about it (etc/openmpi-mca-params.conf is not overwritten by make install, right ?) if one day, i decide to configure without --enable-debug and run a performance benchmark, then i will not get the warning i need (and yes, i will be the only one to blame ... but isn't it something we want to avoid here ?) Cheers, Gilles On 3/2/2016 1:43 PM, George Bosilca wrote: On Mar 1, 2016, at 22:27 , Gilles Gouaillardet wrote: be "me-friendly" :-) i explicitly configure with --enable-debug --enable-picky from git, so i (hopefully) know what i am doing and do not want any warning. iirc, cisco mtt does that too, and i am not sure you would want a warning and/or update your mtt config. this is not a strong opinion, and i am fine with setting a parameter (i will likely soon forget i set that) in a config file. And you will be painfully reminded about that ;) The emitted message was supposed to contain the MCA parameter that need to be set to silence the warning. George. Cheers, Gilles On 3/2/2016 1:21 PM, Jeff Squyres (jsquyres) wrote: On Mar 1, 2016, at 10:17 PM, Gilles Gouaillardet wrote: In this case, should we only display the warning if debug build was implicit ? for example, ./configure from git would display the warning (implicit debug), but ./configure --enable-debug would not (explicit debug), regardless we built from git or a tarball We don't currently distinguish between these two cases. What is the rationale for only warning on implicit debug builds? ___ devel mailing list de...@open-mpi.org Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post: http://www.open-mpi.org/community/lists/devel/2016/03/18656.php ___ devel mailing list de...@open-mpi.org Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post: http://www.open-mpi.org/community/lists/devel/2016/03/18658.php
Re: [OMPI devel] RFC: warn if running a debug build
> On Mar 1, 2016, at 22:27 , Gilles Gouaillardet wrote: > > be "me-friendly" :-) > i explicitly configure with --enable-debug --enable-picky from git, so i > (hopefully) know what i am doing and do not want any warning. > > iirc, cisco mtt does that too, and i am not sure you would want a warning > and/or update your mtt config. > > this is not a strong opinion, and i am fine with setting a parameter (i will > likely soon forget i set that) in a config file. And you will be painfully reminded about that ;) The emitted message was supposed to contain the MCA parameter that need to be set to silence the warning. George. > > Cheers, > > Gilles > > On 3/2/2016 1:21 PM, Jeff Squyres (jsquyres) wrote: >> On Mar 1, 2016, at 10:17 PM, Gilles Gouaillardet wrote: >>> In this case, should we only display the warning if debug build was >>> implicit ? >>> for example, ./configure from git would display the warning (implicit >>> debug), >>> but ./configure --enable-debug would not (explicit debug), regardless we >>> built from git or a tarball >> We don't currently distinguish between these two cases. >> >> What is the rationale for only warning on implicit debug builds? >> > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/03/18656.php
Re: [OMPI devel] RFC: warn if running a debug build
I’ll bet we get a rash of complaints about this behavior…at the very least, let’s not do it if somebody deliberately asks for a debug build. I think people generally hate getting annoying warnings just because a few people do something wrong. > On Mar 1, 2016, at 8:27 PM, Gilles Gouaillardet wrote: > > be "me-friendly" :-) > i explicitly configure with --enable-debug --enable-picky from git, so i > (hopefully) know what i am doing and do not want any warning. > > iirc, cisco mtt does that too, and i am not sure you would want a warning > and/or update your mtt config. > > this is not a strong opinion, and i am fine with setting a parameter (i will > likely soon forget i set that) in a config file. > > Cheers, > > Gilles > > On 3/2/2016 1:21 PM, Jeff Squyres (jsquyres) wrote: >> On Mar 1, 2016, at 10:17 PM, Gilles Gouaillardet wrote: >>> In this case, should we only display the warning if debug build was >>> implicit ? >>> for example, ./configure from git would display the warning (implicit >>> debug), >>> but ./configure --enable-debug would not (explicit debug), regardless we >>> built from git or a tarball >> We don't currently distinguish between these two cases. >> >> What is the rationale for only warning on implicit debug builds? >> > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/03/18656.php
Re: [OMPI devel] RFC: warn if running a debug build
be "me-friendly" :-) i explicitly configure with --enable-debug --enable-picky from git, so i (hopefully) know what i am doing and do not want any warning. iirc, cisco mtt does that too, and i am not sure you would want a warning and/or update your mtt config. this is not a strong opinion, and i am fine with setting a parameter (i will likely soon forget i set that) in a config file. Cheers, Gilles On 3/2/2016 1:21 PM, Jeff Squyres (jsquyres) wrote: On Mar 1, 2016, at 10:17 PM, Gilles Gouaillardet wrote: In this case, should we only display the warning if debug build was implicit ? for example, ./configure from git would display the warning (implicit debug), but ./configure --enable-debug would not (explicit debug), regardless we built from git or a tarball We don't currently distinguish between these two cases. What is the rationale for only warning on implicit debug builds?
Re: [OMPI devel] RFC: warn if running a debug build
On Mar 1, 2016, at 10:17 PM, Gilles Gouaillardet wrote: > > In this case, should we only display the warning if debug build was implicit ? > for example, ./configure from git would display the warning (implicit debug), > but ./configure --enable-debug would not (explicit debug), regardless we > built from git or a tarball We don't currently distinguish between these two cases. What is the rationale for only warning on implicit debug builds? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: warn if running a debug build
In this case, should we only display the warning if debug build was implicit ? for example, ./configure from git would display the warning (implicit debug), but ./configure --enable-debug would not (explicit debug), regardless we built from git or a tarball On 3/2/2016 1:13 PM, Jeff Squyres (jsquyres) wrote: On Mar 1, 2016, at 10:06 PM, Gilles Gouaillardet wrote: what about *not* issuing this warning if OpenMPI is built from git ? that would be friendlier for OMPI developers, and should basically *not* affect endusers, since they would rather build OMPI from a tarball. We're actually specifically trying to catch this case: someone builds from git, doesn't know (or care) that it's a debug build, and runs some performance tests with Open MPI. We figured that it would be sufficient for OMPI devs to set the env variable in their shell startup files to avoid the message.
Re: [OMPI devel] RFC: warn if running a debug build
On Mar 1, 2016, at 10:06 PM, Gilles Gouaillardet wrote: > > what about *not* issuing this warning if OpenMPI is built from git ? > that would be friendlier for OMPI developers, > and should basically *not* affect endusers, since they would rather build > OMPI from a tarball. We're actually specifically trying to catch this case: someone builds from git, doesn't know (or care) that it's a debug build, and runs some performance tests with Open MPI. We figured that it would be sufficient for OMPI devs to set the env variable in their shell startup files to avoid the message. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: warn if running a debug build
Jeff, what about *not* issuing this warning if OpenMPI is built from git ? that would be friendlier for OMPI developers, and should basically *not* affect endusers, since they would rather build OMPI from a tarball. Cheers, Gilles On 3/2/2016 1:00 PM, Jeff Squyres (jsquyres) wrote: WHAT: Have orterun emit a brief warning when using a debug build. WHY: So people stop trying to use a debug build for performance results. WHERE: Mostly in orterun, but a little in orte/runtime WHEN: No rush on this; the idea came up today at the MPI Forum. We can discuss next Tuesday on the Webex. MORE DETAIL: https://github.com/open-mpi/ompi/pull/1417
[OMPI devel] RFC: warn if running a debug build
WHAT: Have orterun emit a brief warning when using a debug build. WHY: So people stop trying to use a debug build for performance results. WHERE: Mostly in orterun, but a little in orte/runtime WHEN: No rush on this; the idea came up today at the MPI Forum. We can discuss next Tuesday on the Webex. MORE DETAIL: https://github.com/open-mpi/ompi/pull/1417 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] component progress function optional?
Durga, You need a progress function if your BTL require explicit progress to drain the network events. As you noticed, the TCP BTL lacks a progress function because it has it's fd registered in the main eventbase and does not require a specific progress call to send/recv data. Moreover, if your BTL has the possibility to make asynchronous progress you will also not need a progress function. If your BTL provides such a progress function, it will be called once per opal_progress call. Otherwise, your BTL is responsible for its own progress. George. On Tue, Mar 1, 2016 at 6:27 PM, dpchoudh . wrote: > Hello all > > (As you might know), I am working on implementing a new BTL for a > proprietary fabric, and, taking the path of least effort, copying and > pasting code from various pre-implemented BTL as is appropriate for our > hardware. My question is: are there any guidance on which of the functions > must be implemented and which are optional (i.e. depends on the underlying > hardware)? > > As a specific example, I see that mca_btl_tcp_component_progress() is > never implemented although similar functions in other BTLs are. > > Thanks in advance > Durga > > Life is complex. It has real and imaginary parts. > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/03/18648.php >
Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)
fwiw
in a previous thread, Jeff Hammond explained this is why mpich is
relying on C89 instead of C99,
since C89 appears to be a subset of C++11.
Cheers,
Gilles
On 3/2/2016 1:02 AM, Nathan Hjelm wrote:
I will add to how crazy this is. The C standard has been very careful
to not break existing code. For example the C99 boolean is _Bool not
bool because C reserves _[A-Z]* for its own use. This means a valid C89
program is a valid C99 and C11 program. It Look like this is not true in
C++.
-Nathan
On Thu, Feb 25, 2016 at 09:52:49PM +, Jeff Squyres (jsquyres) wrote:
On Feb 25, 2016, at 3:39 PM, Paul Hargrove wrote:
A "bare" function name (without parens) is the address of the function, which
can be converted to an int, long, etc.
So the "rank" identifier can validly refer to the function in this context.
I understand that there's logic behind this. But it's still crazy to me that:
-
int foo(void) {
int rank;
printf("Value: %d", rank);
}
-
is ambiguous.
--
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
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post:
http://www.open-mpi.org/community/lists/devel/2016/02/18624.php
___
devel mailing list
de...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post:
http://www.open-mpi.org/community/lists/devel/2016/03/18647.php
[OMPI devel] component progress function optional?
Hello all (As you might know), I am working on implementing a new BTL for a proprietary fabric, and, taking the path of least effort, copying and pasting code from various pre-implemented BTL as is appropriate for our hardware. My question is: are there any guidance on which of the functions must be implemented and which are optional (i.e. depends on the underlying hardware)? As a specific example, I see that mca_btl_tcp_component_progress() is never implemented although similar functions in other BTLs are. Thanks in advance Durga Life is complex. It has real and imaginary parts.
Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)
I will add to how crazy this is. The C standard has been very careful
to not break existing code. For example the C99 boolean is _Bool not
bool because C reserves _[A-Z]* for its own use. This means a valid C89
program is a valid C99 and C11 program. It Look like this is not true in
C++.
-Nathan
On Thu, Feb 25, 2016 at 09:52:49PM +, Jeff Squyres (jsquyres) wrote:
> > On Feb 25, 2016, at 3:39 PM, Paul Hargrove wrote:
> >
> > A "bare" function name (without parens) is the address of the function,
> > which can be converted to an int, long, etc.
> > So the "rank" identifier can validly refer to the function in this context.
>
> I understand that there's logic behind this. But it's still crazy to me that:
>
> -
> int foo(void) {
> int rank;
> printf("Value: %d", rank);
> }
> -
>
> is ambiguous.
>
> --
> 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
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2016/02/18624.php
pgpF_pXyKjjlg.pgp
Description: PGP signature
Re: [OMPI devel] Segmentation fault in opal_fifo (MTT)
Adrian, About bitness, it is correctly set when MPI install successes See https://mtt.open-mpi.org/index.php?do_redir or even your successful install on x86_64 I suspect it is queried once the installation is successful, and I ll try to have a look at it. Cheers, Gilles On Tuesday, March 1, 2016, Adrian Reber wrote: > I have seen it before but it was not reproducible. I have now two > segfaults in opal_fifo in today's MTT run on master and 2.x: > > > https://mtt.open-mpi.org/index.php?do_redir=2270 > https://mtt.open-mpi.org/index.php?do_redir=2271 > > The thing that is strange about the MTT output is that MTT does not detect > the endianess and bitness correctly. It says on a x86_64 (Fedora 23) > system: > > Endian: unknown > Bitness: 32 > > Endianess is not mentioned in mtt configuration file and bitness is > commented out like this: > > #CN: bitness = 32 > > which is probably something I copied from another mtt configuration file > when initially creating mine. > > Adrian > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Searchable archives: > http://www.open-mpi.org/community/lists/devel/2016/03/18645.php >
[OMPI devel] Segmentation fault in opal_fifo (MTT)
I have seen it before but it was not reproducible. I have now two segfaults in opal_fifo in today's MTT run on master and 2.x: https://mtt.open-mpi.org/index.php?do_redir=2270 https://mtt.open-mpi.org/index.php?do_redir=2271 The thing that is strange about the MTT output is that MTT does not detect the endianess and bitness correctly. It says on a x86_64 (Fedora 23) system: Endian: unknown Bitness: 32 Endianess is not mentioned in mtt configuration file and bitness is commented out like this: #CN: bitness = 32 which is probably something I copied from another mtt configuration file when initially creating mine. Adrian
