<?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 &amp;gt;&amp;gt;...I basically want my in Software Archive</title>
    <link>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073267#M58927</link>
    <description>&amp;gt;&amp;gt;...I basically want my program to be able to access only a total of 2GB of memory space from the Phis total space of &lt;STRONG&gt;16GB&lt;/STRONG&gt;...

Could you clarify... Are you going to use MCDRAM or RAM ( DDR4 ) in your experiments?</description>
    <pubDate>Thu, 06 Apr 2017 17:28:01 GMT</pubDate>
    <dc:creator>SergeyKostrov</dc:creator>
    <dc:date>2017-04-06T17:28:01Z</dc:date>
    <item>
      <title>Limiting access on MIC memory size and bandwidth.</title>
      <link>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073265#M58925</link>
      <description>&lt;P&gt;Hi all,&lt;BR /&gt;
	&lt;BR /&gt;
	I am running workloads on a Xeon Phi 7120P, and had some questions regarding how to disable address interleaving on memory controllers.&amp;nbsp;&lt;BR /&gt;
	&lt;BR /&gt;
	Each memory controller on the Phi has two memory channels, and each channel is connected to 1GB of memory (please correct me if i'm wrong). I basically want my program to be able to access only a total of 2GB of memory space from the Phis total space of 16GB. This reduces the memory size and the bandwidth my program will exploit, which is a part of my experiment.&lt;BR /&gt;
	&lt;BR /&gt;
	Now one way I was thinking of doing this was to disable address interleaving and keeping my workload working set within 2GB, which would mainly keep it accessing a single memory controller. Another way could be to add dummy data/mapping in between interleaving so all off-chip accesses go to a single memory controller.&amp;nbsp;&lt;BR /&gt;
	&lt;BR /&gt;
	Can anyone help me with this?&lt;BR /&gt;
	&lt;BR /&gt;
	Thanks!&lt;BR /&gt;
	Masab&lt;/P&gt;</description>
      <pubDate>Mon, 03 Apr 2017 22:10:44 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073265#M58925</guid>
      <dc:creator>Masab_A_</dc:creator>
      <dc:date>2017-04-03T22:10:44Z</dc:date>
    </item>
    <item>
      <title>The memory interleaving on</title>
      <link>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073266#M58926</link>
      <description>&lt;P&gt;The memory interleaving on the first generation Xeon Phi is extraordinarily complex when ECC is enabled, due to the need to "skip over" 2 out of every 64 cache lines (which are then used to hold the error correcting data).&lt;/P&gt;

&lt;P&gt;I have never checked to see what the interleaving looks like with ECC disabled, but I am not aware of any documentation that would provide any help in changing the configuration (if that is even possible).&lt;/P&gt;

&lt;P&gt;Reducing bandwidth is much easier in a system with DIMM-based memory, since you can just pull DIMMs to eliminate those sources of bandwidth.&lt;BR /&gt;
	&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 04 Apr 2017 22:55:02 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073266#M58926</guid>
      <dc:creator>McCalpinJohn</dc:creator>
      <dc:date>2017-04-04T22:55:02Z</dc:date>
    </item>
    <item>
      <title>&gt;&gt;...I basically want my</title>
      <link>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073267#M58927</link>
      <description>&amp;gt;&amp;gt;...I basically want my program to be able to access only a total of 2GB of memory space from the Phis total space of &lt;STRONG&gt;16GB&lt;/STRONG&gt;...

Could you clarify... Are you going to use MCDRAM or RAM ( DDR4 ) in your experiments?</description>
      <pubDate>Thu, 06 Apr 2017 17:28:01 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073267#M58927</guid>
      <dc:creator>SergeyKostrov</dc:creator>
      <dc:date>2017-04-06T17:28:01Z</dc:date>
    </item>
    <item>
      <title>@John</title>
      <link>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073268#M58928</link>
      <description>&lt;P&gt;@John&lt;BR /&gt;
	Thank you very much for your answer. I guess I'll have to play around with compiler based prefetching to somehow approximately control bandwidth.&lt;BR /&gt;
	I was trying to recreate results from this paper:&amp;nbsp;http://delaat.net/awards/2014-03-26-paper.pdf&lt;BR /&gt;
	They claim to disable hardware prefetching, as shown in results from Fig 6 of the paper. They apparently explain how they disable/enable prefetching in Section 3.3, however its all blurry on how they disabled HW prefetching.&lt;BR /&gt;
	&lt;BR /&gt;
	@Sergey&lt;BR /&gt;
	I am using a Xeon Phi 7120P, which has an older systems architecture. There is no MCDRAM, and the only memory space available is the 16GB GDDR5.&lt;/P&gt;</description>
      <pubDate>Thu, 06 Apr 2017 17:32:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073268#M58928</guid>
      <dc:creator>Masab_A_</dc:creator>
      <dc:date>2017-04-06T17:32:00Z</dc:date>
    </item>
    <item>
      <title>In the machines I use,</title>
      <link>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073269#M58929</link>
      <description>&lt;P&gt;In the machines I use, turning off hardware prefetch is done using one of the advanced options in the BIOS when you boot the machine...assuming your BIOS vendor decided to make that option available.&amp;nbsp; The Intel version of the syscfg tool can also read BIOS settings and change them as well (if you have root privileges) on Linux (&lt;A href="https://downloadcenter.intel.com/download/26365/Save-and-Restore-System-Configuration-Utility-syscfg"&gt;https://downloadcenter.intel.com/download/26365/Save-and-Restore-System-Configuration-Utility-syscfg&lt;/A&gt;-)&lt;/P&gt;

&lt;P&gt;Charles&lt;/P&gt;</description>
      <pubDate>Tue, 11 Apr 2017 20:22:27 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073269#M58929</guid>
      <dc:creator>Charles_C_Intel1</dc:creator>
      <dc:date>2017-04-11T20:22:27Z</dc:date>
    </item>
    <item>
      <title>&gt;&gt;...I was trying to recreate</title>
      <link>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073270#M58930</link>
      <description>&amp;gt;&amp;gt;...I was trying to recreate results from this paper: &lt;A href="http://delaat.net/awards/2014-03-26-paper.pdf" target="_blank"&gt;http://delaat.net/awards/2014-03-26-paper.pdf&lt;/A&gt;.

On a page &lt;STRONG&gt;6&lt;/STRONG&gt; authors claimed:

&amp;gt;&amp;gt;...
&amp;gt;&amp;gt;Moreover, both the read and write memory bandwidth increases over the number of threads - which happens because when
&amp;gt;&amp;gt;using more threads, we can generate more requests to memory controllers, thus making the interconnect and memory channels busier.
&amp;gt;&amp;gt;...

Some my tests for older &lt;STRONG&gt;Intel&lt;/STRONG&gt; architectures showed that for a 100% memory bound processing a peak of performance is achieved when number of threads used in OpenMP processing &lt;STRONG&gt;does not exceed&lt;/STRONG&gt; number of hardware threads for a CPU, or &lt;STRONG&gt;equals&lt;/STRONG&gt; to a number of memory channels. Heavy oversubscription of OpenMP threads only &lt;STRONG&gt;degrades&lt;/STRONG&gt; processing.

For example, for &lt;STRONG&gt;Ivy Bridge Intel&lt;/STRONG&gt; architecture ( &lt;A href="http://ark.intel.com/Product.aspx?id=70846" target="_blank"&gt;http://ark.intel.com/Product.aspx?id=70846&lt;/A&gt; ) performance numbers were almost the same for &lt;STRONG&gt;2&lt;/STRONG&gt; OpenMP threads ( equals to number of memory channels ), and for &lt;STRONG&gt;4&lt;/STRONG&gt; OpenMP threads ( equals to number of hardware threads ).</description>
      <pubDate>Wed, 12 Apr 2017 19:17:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Limiting-access-on-MIC-memory-size-and-bandwidth/m-p/1073270#M58930</guid>
      <dc:creator>SergeyKostrov</dc:creator>
      <dc:date>2017-04-12T19:17:00Z</dc:date>
    </item>
  </channel>
</rss>

