<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Help With Very Slow Intel MPI Performance in Intel® MPI Library</title>
    <link>https://community.intel.com/t5/Intel-MPI-Library/Help-With-Very-Slow-Intel-MPI-Performance/m-p/1165246#M6435</link>
    <description>&lt;P&gt;All,&lt;/P&gt;

&lt;P&gt;I'm hoping the Intel MPI gurus can help with this. Recently I've tried transitioning some code I help maintain (GEOS, a climate model) from using HPE MPT (2.17, in this case) to Intel MPI (18.0.1; 18.0.2 I'll test soon).&amp;nbsp; In both cases, the compiler (Intel 18.0.1) is the same, both running on the same set of Haswell nodes on an SGI/HPE cluster. The only difference is the MPI stack.&lt;/P&gt;

&lt;P&gt;Now one part of the code (AGCM, the physics/dynamics part) is actually a little bit faster with Intel MPI than MPT, even on an SGI machine. That is nice. It's maybe 5-10% faster in some cases. Huzzah!&lt;/P&gt;

&lt;P&gt;But, another code (GSI, analysis of observation data) really, really, &lt;EM&gt;&lt;STRONG&gt;really&lt;/STRONG&gt;&lt;/EM&gt; does not like Intel MPI. This code displays two issues. First, after the code starts (both launch very fast) it eventually hits a point at which, we believe, the first collective occurs at which point the whole code stalls as it...initializes buffers? Something with Infiniband maybe? We don't know. MPT slows a bit too, but doesn't show this issue nearly as badly as IMPI. We had another place like this in the AGCM where moving from a collective to an Isend/Recv/Wait type paradigm really helped. This "stall" is annoying and, worse, it gets longer and longer as the number of cores increase. (We might have a reproducer for this one.)&lt;/P&gt;

&lt;P&gt;But, that is minor really. A minute or so, compared to the overall performance. On 240 cores, MPT 2.17 runs this code in 15:03 (minutes:seconds), Intel MPI 18.0.1, 28:12. On 672 cores, MPT 2.17 runs the code in 12:02 and Intel MPI 18.0.2 in 21:47; doesn't scale well overall for either.&lt;/P&gt;

&lt;P&gt;Using I_MPI_STATS, the code is seen to be ~60% MPI in Alltoallv (20% of wall) at 240 cores; at 672, Barrier starts to win, but Alltoallv is still 40% MPI, 23% walltime. I've tried running by setting both I_MPI_ADJUST_ALLTOALLV options (1 and 2) and it does little at all (28:44 and 28:25 at 240).&lt;/P&gt;

&lt;P&gt;I'm going to try and see if I can request/reserve a set of nodes for a long time to do an mpitune run, but since each run is ~30 minutes...mpitune will not be fun as it'd be 90 minutes for each option test.&lt;/P&gt;

&lt;P&gt;Any ideas on what might be happening? Any advice for flags/environment variables to try? I understand that HPE MPT might/should work best on an SGI/HPE machine (like how Intel compilers seem to do best with Intel chips), but this seems a bit beyond the usual difference. I've requested MVAPICH2 be installed as well for another comparison.&lt;/P&gt;

&lt;P&gt;Matt&lt;/P&gt;</description>
    <pubDate>Fri, 06 Apr 2018 00:38:05 GMT</pubDate>
    <dc:creator>Matt_Thompson</dc:creator>
    <dc:date>2018-04-06T00:38:05Z</dc:date>
    <item>
      <title>Help With Very Slow Intel MPI Performance</title>
      <link>https://community.intel.com/t5/Intel-MPI-Library/Help-With-Very-Slow-Intel-MPI-Performance/m-p/1165246#M6435</link>
      <description>&lt;P&gt;All,&lt;/P&gt;

&lt;P&gt;I'm hoping the Intel MPI gurus can help with this. Recently I've tried transitioning some code I help maintain (GEOS, a climate model) from using HPE MPT (2.17, in this case) to Intel MPI (18.0.1; 18.0.2 I'll test soon).&amp;nbsp; In both cases, the compiler (Intel 18.0.1) is the same, both running on the same set of Haswell nodes on an SGI/HPE cluster. The only difference is the MPI stack.&lt;/P&gt;

&lt;P&gt;Now one part of the code (AGCM, the physics/dynamics part) is actually a little bit faster with Intel MPI than MPT, even on an SGI machine. That is nice. It's maybe 5-10% faster in some cases. Huzzah!&lt;/P&gt;

&lt;P&gt;But, another code (GSI, analysis of observation data) really, really, &lt;EM&gt;&lt;STRONG&gt;really&lt;/STRONG&gt;&lt;/EM&gt; does not like Intel MPI. This code displays two issues. First, after the code starts (both launch very fast) it eventually hits a point at which, we believe, the first collective occurs at which point the whole code stalls as it...initializes buffers? Something with Infiniband maybe? We don't know. MPT slows a bit too, but doesn't show this issue nearly as badly as IMPI. We had another place like this in the AGCM where moving from a collective to an Isend/Recv/Wait type paradigm really helped. This "stall" is annoying and, worse, it gets longer and longer as the number of cores increase. (We might have a reproducer for this one.)&lt;/P&gt;

&lt;P&gt;But, that is minor really. A minute or so, compared to the overall performance. On 240 cores, MPT 2.17 runs this code in 15:03 (minutes:seconds), Intel MPI 18.0.1, 28:12. On 672 cores, MPT 2.17 runs the code in 12:02 and Intel MPI 18.0.2 in 21:47; doesn't scale well overall for either.&lt;/P&gt;

&lt;P&gt;Using I_MPI_STATS, the code is seen to be ~60% MPI in Alltoallv (20% of wall) at 240 cores; at 672, Barrier starts to win, but Alltoallv is still 40% MPI, 23% walltime. I've tried running by setting both I_MPI_ADJUST_ALLTOALLV options (1 and 2) and it does little at all (28:44 and 28:25 at 240).&lt;/P&gt;

&lt;P&gt;I'm going to try and see if I can request/reserve a set of nodes for a long time to do an mpitune run, but since each run is ~30 minutes...mpitune will not be fun as it'd be 90 minutes for each option test.&lt;/P&gt;

&lt;P&gt;Any ideas on what might be happening? Any advice for flags/environment variables to try? I understand that HPE MPT might/should work best on an SGI/HPE machine (like how Intel compilers seem to do best with Intel chips), but this seems a bit beyond the usual difference. I've requested MVAPICH2 be installed as well for another comparison.&lt;/P&gt;

&lt;P&gt;Matt&lt;/P&gt;</description>
      <pubDate>Fri, 06 Apr 2018 00:38:05 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-MPI-Library/Help-With-Very-Slow-Intel-MPI-Performance/m-p/1165246#M6435</guid>
      <dc:creator>Matt_Thompson</dc:creator>
      <dc:date>2018-04-06T00:38:05Z</dc:date>
    </item>
    <item>
      <title>Bit of an update: I was able</title>
      <link>https://community.intel.com/t5/Intel-MPI-Library/Help-With-Very-Slow-Intel-MPI-Performance/m-p/1165247#M6436</link>
      <description>&lt;P&gt;Bit of an update: I was able to run with Open MPI, and it took about 30 minutes as well (about the same as Intel MPI, our disks seem to be having a day which slowed some initializing). I tried MVAPICH2 too but it just exploded, so I'm guessing some low-level interaction between Infiniband and me doing something wrong in calling/compiling.&lt;/P&gt;

&lt;P&gt;Perhaps HPE just has a really well-optimized Alltoallv for an HPE machine? I believe we are getting an Omni-Path cluster soon, so perhaps Intel MPI will come into its own on it?&lt;/P&gt;</description>
      <pubDate>Fri, 06 Apr 2018 14:39:17 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-MPI-Library/Help-With-Very-Slow-Intel-MPI-Performance/m-p/1165247#M6436</guid>
      <dc:creator>Matt_Thompson</dc:creator>
      <dc:date>2018-04-06T14:39:17Z</dc:date>
    </item>
  </channel>
</rss>

