[mvapich-discuss] (no subject)

Jonathan Perkins perkinjo at cse.ohio-state.edu
Mon Jan 18 19:51:51 EST 2016 

Hello Damian.  I believe that your observations are correct and that this
is something that we can correct in our upcoming releases.  Thank you for
bringing this issue to our attention.

On Mon, Jan 18, 2016 at 6:22 PM Damian Alvarez <d.alvarez at fz-juelich.de>
wrote:

> --===============3697023473979613875==
> Content-Type: multipart/alternative;
>         boundary="----=_NextPart_000_00B0_01D15219.36778E80"
> Content-Language: en-us
>
> ------=_NextPart_000_00B0_01D15219.36778E80
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> Dear mailing list,
>
> I think we've found a "feature" inhered from MPICH2, which might lead to
> un=
> desired behaviour.
>
> MPICH2 makes a distinction between xFLAGS, MPICH2LIB_xFLAGS,
> MPICH2_MAKE_xF=
> LAGS, and MPICH2_MPIX_FLAGS. This can be seen in section 3 of their README
> =
> (http://www.mpich.org/static/downloads/3.2/mpich-3.2-README.txt) which
> has =
> been there for a long time.
>
> It seems like MVAPICH2 inhered that behaviour. I am unsure if this is in
> th=
> e MVAPICH2 documentation. I couldn't find it but I didn't look too deeply.
>
> The issue is the following: using xFLAGS (like CFLAGS, CXXFLAGS, etc) is a
> =
> fairly common way to compile software. Due to this "feature", the flags
> use=
> d to compile the compiler/runtime will be transparently and [maybe]
> inadver=
> tently added to the mpixxx wrappers. That means that applications compiled
> =
> with MPI will pass the same set of flags used to compile MPI itself, and
> an=
> y additional flag that the user might provide. That can be conflictive and
> =
> can lead to incompatible compiler flags and/or underperforming options.
>
> The distinction between CFLAGS and MPICH2LIB_xFLAGS, etc,  has been
> mention=
> ed in the mailing list a couple of times before, but I didn't find any
> disc=
> ussion where this issue is highlighted. That's why I am writing to the
> mail=
> ing list. Maybe it is worth a discussion and be mentioned in the
> documentat=
> ion in a more prominent position.
>
> I guess that due to this obscure "feature", the RPMs provided for
> MVAPICH2-=
> GDR have something that I guess was not intended. The MPI wrappers pass
> thi=
> s set of flags to the underlying compiler: -O2 -g -pipe -Wall
> -Wp,-D_FORTIF=
> Y_SOURCE=3D2 -fexceptions -fstack-protector --param=3Dssp-buffer-size=3D4
> -=
> m64 -mtune=3Dgeneric. I doubt flags like -O2 -g -mtune=3Dgeneric are
> suppos=
> ed to be passed to the compiler regardless of what the user specifies.
>
> Am I totally off, or this set of flags shouldn't be included in the
> wrapper=
> s shipped on the RPMs?
>
> Damian
>
> --
> Dr. Damian Alvarez
> Juelich Supercomputing Centre (JSC)
> Institute for Advanced Simulation
> Forschungszentrum Juelich GmbH
> 52425 Juelich, Germany
> Phone: +49 2461 61 9336
> WWW: http://www.fz-juelich.de/jsc/
> JSC is member of the
> Gauss Centre for Supercomputing
>
>
>
>
> ---------------------------------------------------------------------------=
> ---------------------
>
> ---------------------------------------------------------------------------=
> ---------------------
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
> Prof. Dr. Sebastian M. Schmidt
>
> ---------------------------------------------------------------------------=
> ---------------------
>
> ---------------------------------------------------------------------------=
> ---------------------
>
>
> ------=_NextPart_000_00B0_01D15219.36778E80
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml"
> xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word"
> =
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"
> xmlns=3D"http:=
> //www.w3.org/TR/REC-html40">
> <head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html;
> charset=3Dus-ascii"=
> >
> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
> <style><!--
> /* Font Definitions */
> @font-face
>         {font-family:Calibri;
>         panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
>         {font-family:Tahoma;
>         panose-1:2 11 6 4 3 5 4 4 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
>         {margin:0cm;
>         margin-bottom:.0001pt;
>         font-size:11.0pt;
>         font-family:"Calibri","sans-serif";
>         mso-fareast-language:EN-US;}
> a:link, span.MsoHyperlink
>         {mso-style-priority:99;
>         color:blue;
>         text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
>         {mso-style-priority:99;
>         color:purple;
>         text-decoration:underline;}
> span.EmailStyle17
>         {mso-style-type:personal-compose;
>         font-family:"Calibri","sans-serif";
>         color:windowtext;}
> .MsoChpDefault
>         {mso-style-type:export-only;
>         font-family:"Calibri","sans-serif";
>         mso-fareast-language:EN-US;}
> @page WordSection1
>         {size:612.0pt 792.0pt;
>         margin:72.0pt 72.0pt 72.0pt 72.0pt;}
> div.WordSection1
>         {page:WordSection1;}
> --></style><!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
> <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]-->
> </head>
> <body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
> <div class=3D"WordSection1">
> <p class=3D"MsoNormal">Dear mailing list,<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal">I think we’ve found a “feature”
> in=
> hered from MPICH2, which might lead to undesired behaviour.<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal">MPICH2 makes a distinction between xFLAGS,
> MPICH2LIB=
> _xFLAGS, MPICH2_MAKE_xFLAGS, and MPICH2_MPIX_FLAGS. This can be seen in
> sec=
> tion 3 of their README (<a href=3D"
> http://www.mpich.org/static/downloads/3.=
> 2/mpich-3.2-README.txt
> <http://www.mpich.org/static/downloads/3.=2/mpich-3.2-README.txt>">
> http://www.mpich.org/static/downloads/3.2/mpich-3.2=
> -README.txt
> <http://www.mpich.org/static/downloads/3.2/mpich-3.2=-README.txt></a>)
>  which has been there for a long time.<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal">It seems like MVAPICH2 inhered that behaviour. I am
> =
> unsure if this is in the MVAPICH2 documentation. I couldn’t find it
> b=
> ut I didn’t look too deeply.<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal">The issue is the following: using xFLAGS (like
> CFLAG=
> S, CXXFLAGS, etc) is a fairly common way to compile software. Due to this
> &=
> #8220;feature”, the flags used to compile the compiler/runtime will
> b=
> e transparently and [maybe] inadvertently added
>  to the mpixxx wrappers. That means that applications compiled with MPI
> wil=
> l pass the same set of flags used to compile MPI itself, and any
> additional=
>  flag that the user might provide. That can be conflictive and can lead to
> =
> incompatible compiler flags and/or
>  underperforming options.<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal">The distinction between CFLAGS and
> MPICH2LIB_xFLAGS,=
>  etc,  has been mentioned in the mailing list a couple of times
> before=
> , but I didn’t find any discussion where this issue is highlighted.
> T=
> hat’s why I am writing to the mailing list. Maybe
>  it is worth a discussion and be mentioned in the documentation in a more
> p=
> rominent position.<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal">I guess that due to this obscure
> “feature&#822=
> 1;, the RPMs provided for MVAPICH2-GDR have something that I guess was not
> =
> intended. The MPI wrappers pass this set of flags to the underlying
> compile=
> r:
> <span style=3D"color:#333333;background:white">-O2 -g -pipe -Wall
> -Wp,-D_FO=
> RTIFY_SOURCE=3D2 -fexceptions -fstack-protector --param=3Dssp-buffer-size=
> =3D4 -m64 -mtune=3Dgeneric. I doubt flags like -O2 -g -mtune=3Dgeneric are
> =
> supposed to be passed to the compiler regardless
>  of what the user specifies.<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span
> style=3D"color:#333333;background:white"><o:p>=
>  </o:p></span></p>
> <p class=3D"MsoNormal">Am I totally off, or this set of flags
> shouldn&#8217=
> ;t be included in the wrappers shipped on the RPMs?<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal">Damian<o:p></o:p></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> <p class=3D"MsoNormal"><span lang=3D"EN-US"
> style=3D"font-size:10.0pt;font-=
>
> family:"Tahoma","sans-serif";color:black;mso-fareast-la=
> nguage:EN-GB">--
> <br>
> Dr. Damian Alvarez <br>
> Juelich Supercomputing Centre (JSC)<br>
> Institute for Advanced Simulation<br>
> Forschungszentrum Juelich GmbH<br>
> 52425 Juelich, Germany<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span lang=3D"EN-US"
> style=3D"font-size:10.0pt;font-=
>
> family:"Tahoma","sans-serif";color:black;mso-fareast-la=
> nguage:EN-GB">Phone: +49 2461 61 9336<br>
> WWW: http://www.fz-juelich.de/jsc/<br>
> JSC is member of the<br>
> Gauss Centre for Supercomputing<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><o:p> </o:p></p>
> </div>
> <br>
> <font face=3D"Arial" color=3D"Black" size=3D"1"><br>
>
> ---------------------------------------------------------------------------=
> ---------------------<br>
>
> ---------------------------------------------------------------------------=
> ---------------------<br>
> Forschungszentrum Juelich GmbH<br>
> 52425 Juelich<br>
> Sitz der Gesellschaft: Juelich<br>
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498<br>
> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher<br>
> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),<br>
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,<br>
> Prof. Dr. Sebastian M. Schmidt<br>
>
> ---------------------------------------------------------------------------=
> ---------------------<br>
>
> ---------------------------------------------------------------------------=
> ---------------------<br>
> <br>
> </font>
> </body>
> </html>
>
> ------=_NextPart_000_00B0_01D15219.36778E80--
>
> --===============3697023473979613875==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> mvapich-discuss mailing list
> mvapich-discuss at cse.ohio-state.edu
> http://mailman.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss
>
> --===============3697023473979613875==--
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20160119/8c9fae96/attachment-0001.html>

More information about the mvapich-discuss mailing list