<?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 Re: The maximum value of the MEM_UOPS_RETIRED: ALL_LOADS/STORE event per second. Haswell Xeon E5 269 in Software Tuning, Performance Optimization &amp; Platform Monitoring</title>
    <link>https://community.intel.com/t5/Software-Tuning-Performance/The-maximum-value-of-the-MEM-UOPS-RETIRED-ALL-LOADS-STORE-event/m-p/1273654#M7864</link>
    <description>&lt;P&gt;Plenty of people have been able to reproduce the two loads per cycle on Haswell, so the hardware is certainly capable if the user sets everything up correctly.&lt;/P&gt;
&lt;P&gt;Problems can arise in many areas -- some of which are reasonably well-known, but others can be more obscure.&lt;/P&gt;
&lt;P&gt;At a minimum, I would recommend reviewing:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;process pinning&lt;/LI&gt;
&lt;LI&gt;measured time vs timer overhead&amp;nbsp;
&lt;UL&gt;
&lt;LI&gt;PAPI's overhead may be much higher than you expect -- I see an average of almost 2000 cycles on an Intel Cascade Lake system.&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;LI&gt;Load alignment
&lt;UL&gt;
&lt;LI&gt;My experiments on Xeon E5 v3 show that the core can perform two loads per cycle of any size or alignment as long as neither crosses a cache line boundary. &amp;nbsp;If any load crosses a cache line boundary, throughput drops to 1 load per cycle (from the L1).&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Some notes at&amp;nbsp;&lt;A href="https://sites.utexas.edu/jdm4372/2018/07/23/comments-on-timing-short-code-sections-on-intel-processors/" target="_blank"&gt;https://sites.utexas.edu/jdm4372/2018/07/23/comments-on-timing-short-code-sections-on-intel-processors/&lt;/A&gt;&amp;nbsp;may be helpful.&lt;/P&gt;</description>
    <pubDate>Wed, 14 Apr 2021 22:00:49 GMT</pubDate>
    <dc:creator>McCalpinJohn</dc:creator>
    <dc:date>2021-04-14T22:00:49Z</dc:date>
    <item>
      <title>The maximum value of the MEM_UOPS_RETIRED: ALL_LOADS/STORE event per second. Haswell Xeon E5 2697 v3</title>
      <link>https://community.intel.com/t5/Software-Tuning-Performance/The-maximum-value-of-the-MEM-UOPS-RETIRED-ALL-LOADS-STORE-event/m-p/1272144#M7862</link>
      <description>&lt;P&gt;In one of the topics (&lt;A href="https://community.intel.com/t5/Software-Tuning-Performance/The-maximum-value-of-the-MEM-UOPS-RETIRED-ALL-LOADS-event-per/m-p/1236536#M7751" target="_blank"&gt;https://community.intel.com/t5/Software-Tuning-Performance/The-maximum-value-of-the-MEM-UOPS-RETIRED-ALL-LOADS-event-per/mp/1236536 # M7751&lt;/A&gt;) I asked about the theoretically achievable values ​​of MEM_UOPS_RETIRED: ALL_LOADS / STORE events per second.&lt;/P&gt;
&lt;P&gt;After running synthetic tests with sequential and random access to memory, we got the maximum results on 12 threads (cores) with sequential access: for the LOAD operation - 42.95&amp;nbsp;&lt;SPAN&gt;billion&lt;/SPAN&gt; per second, STORE - 26.2&amp;nbsp;&lt;SPAN&gt;billion&amp;nbsp;&lt;/SPAN&gt;per second. These values ​​are almost 50% of the theoretical maximum. Also, for 1 core, the values ​​are 2 times less than the theoretical ones. Vector instructions are not used, the processor frequency is 3.1 GHz on all cores, each core has its own data vector and all data is placed in L1 cache. PAPI is used to measure the values ​​of the counters.&lt;/P&gt;
&lt;P&gt;Why do we get exactly 2 times less values? In the assembler code that the compiler produces, the movq and movl operations are used for different data types. Are there any other restrictions on the theoretical limit?&lt;/P&gt;</description>
      <pubDate>Thu, 08 Apr 2021 19:56:39 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Tuning-Performance/The-maximum-value-of-the-MEM-UOPS-RETIRED-ALL-LOADS-STORE-event/m-p/1272144#M7862</guid>
      <dc:creator>gadel_zakirov</dc:creator>
      <dc:date>2021-04-08T19:56:39Z</dc:date>
    </item>
    <item>
      <title>Re: The maximum value of the MEM_UOPS_RETIRED: ALL_LOADS/STORE event per second. Haswell Xeon E5 269</title>
      <link>https://community.intel.com/t5/Software-Tuning-Performance/The-maximum-value-of-the-MEM-UOPS-RETIRED-ALL-LOADS-STORE-event/m-p/1273654#M7864</link>
      <description>&lt;P&gt;Plenty of people have been able to reproduce the two loads per cycle on Haswell, so the hardware is certainly capable if the user sets everything up correctly.&lt;/P&gt;
&lt;P&gt;Problems can arise in many areas -- some of which are reasonably well-known, but others can be more obscure.&lt;/P&gt;
&lt;P&gt;At a minimum, I would recommend reviewing:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;process pinning&lt;/LI&gt;
&lt;LI&gt;measured time vs timer overhead&amp;nbsp;
&lt;UL&gt;
&lt;LI&gt;PAPI's overhead may be much higher than you expect -- I see an average of almost 2000 cycles on an Intel Cascade Lake system.&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;LI&gt;Load alignment
&lt;UL&gt;
&lt;LI&gt;My experiments on Xeon E5 v3 show that the core can perform two loads per cycle of any size or alignment as long as neither crosses a cache line boundary. &amp;nbsp;If any load crosses a cache line boundary, throughput drops to 1 load per cycle (from the L1).&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Some notes at&amp;nbsp;&lt;A href="https://sites.utexas.edu/jdm4372/2018/07/23/comments-on-timing-short-code-sections-on-intel-processors/" target="_blank"&gt;https://sites.utexas.edu/jdm4372/2018/07/23/comments-on-timing-short-code-sections-on-intel-processors/&lt;/A&gt;&amp;nbsp;may be helpful.&lt;/P&gt;</description>
      <pubDate>Wed, 14 Apr 2021 22:00:49 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Tuning-Performance/The-maximum-value-of-the-MEM-UOPS-RETIRED-ALL-LOADS-STORE-event/m-p/1273654#M7864</guid>
      <dc:creator>McCalpinJohn</dc:creator>
      <dc:date>2021-04-14T22:00:49Z</dc:date>
    </item>
  </channel>
</rss>

