<?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 There are quite a few events in Intel® Moderncode for Parallel Architectures</title>
    <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/profiling-for-false-sharing-on-sandy-bridge/m-p/1072231#M7012</link>
    <description>&lt;P&gt;There are quite a few events on Sandy Bridge processors that can be used to obtain similar information.&lt;/P&gt;

&lt;P&gt;The main thing that you are looking for is a rapid increase in cache misses that hit modified data in another cache.&amp;nbsp; These often have names that include "HitM".&lt;/P&gt;

&lt;P&gt;From Section 19.6 of Volume 3 of the Intel Architectures Software Developer's Manual, a number of events whose name or description includes "HitM":&lt;/P&gt;

&lt;UL&gt;
	&lt;LI&gt;L1D.ALL_M_REPLACEMENT (Event 0x51, Umask 0x08) counts dirty lines that are evicted from the L1 Data Cache either by "Snoop HitM" or by victim eviction of modified lines.&lt;/LI&gt;
	&lt;LI&gt;MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM (Event 0xD2, Umask 0x04) counts load uops whose data source was a dirty line in another core in the same package.&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Many of the events using the OFFCORE_RESPONSE performance counter events are slightly different between the "client" and "server" Sandy Bridge processors, as described in Tables 19-14 and 19-15 of Volume 3 of the SW Developer's Manual.&amp;nbsp;&amp;nbsp; For the "client" Sandy Bridge parts, it looks like the event OFFCORE_RESPONSE.ALL_RFO.LLC_HIT.HITM_OTHER_CORE_[01] is exactly what you want -- it counts every time a store misses in a core's cache and the cache line is found modified in another core's cache.&amp;nbsp; (These are always "local", since the "client" parts only support a single package per system.)&amp;nbsp;&amp;nbsp; I have not tested this event, but if it works correctly, it should be exactly what you want.&lt;/P&gt;

&lt;P&gt;The "client" parts also have some relevant uncore counters described in Table 19-16, but these are a little harder to use.&lt;/P&gt;

&lt;P&gt;For the "server" Sandy Bridge parts, the preface to Table19-15 notes that a bypass needs to be disabled for the MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM&amp;nbsp; event to be accurate.&amp;nbsp; I think that this should be done automatically by VTune if this event is selected.&amp;nbsp;&amp;nbsp; Intel only lists a subset of the possible OFFCORE_RESPONSE events in Tables 19-14 and 19-15.&amp;nbsp; The ones that are listed are quite likely to work, but other sub-events might also work.&amp;nbsp;&amp;nbsp; The events are described in Section 18.8.5, which should be read in conjunction with the examples in Table 19-15, but this is not easy reading....&lt;/P&gt;</description>
    <pubDate>Mon, 04 Jan 2016 19:13:56 GMT</pubDate>
    <dc:creator>McCalpinJohn</dc:creator>
    <dc:date>2016-01-04T19:13:56Z</dc:date>
    <item>
      <title>profiling for false-sharing on sandy bridge</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/profiling-for-false-sharing-on-sandy-bridge/m-p/1072230#M7011</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;

&lt;P&gt;I am trying to find out if my application has some instances of false-sharing that i can improve. I read this awesome article:&amp;nbsp;https://software.intel.com/en-us/articles/avoiding-and-identifying-false-sharing-among-threads&lt;/P&gt;

&lt;P&gt;but the referred performance counters are not available in my Sandy Bridge machine. Does someone know the corresponding performance counters i should use to detect false-sharing?&amp;nbsp;&lt;/P&gt;

&lt;P&gt;Thank you&lt;/P&gt;</description>
      <pubDate>Mon, 04 Jan 2016 18:49:48 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/profiling-for-false-sharing-on-sandy-bridge/m-p/1072230#M7011</guid>
      <dc:creator>Ricardo_F_1</dc:creator>
      <dc:date>2016-01-04T18:49:48Z</dc:date>
    </item>
    <item>
      <title>There are quite a few events</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/profiling-for-false-sharing-on-sandy-bridge/m-p/1072231#M7012</link>
      <description>&lt;P&gt;There are quite a few events on Sandy Bridge processors that can be used to obtain similar information.&lt;/P&gt;

&lt;P&gt;The main thing that you are looking for is a rapid increase in cache misses that hit modified data in another cache.&amp;nbsp; These often have names that include "HitM".&lt;/P&gt;

&lt;P&gt;From Section 19.6 of Volume 3 of the Intel Architectures Software Developer's Manual, a number of events whose name or description includes "HitM":&lt;/P&gt;

&lt;UL&gt;
	&lt;LI&gt;L1D.ALL_M_REPLACEMENT (Event 0x51, Umask 0x08) counts dirty lines that are evicted from the L1 Data Cache either by "Snoop HitM" or by victim eviction of modified lines.&lt;/LI&gt;
	&lt;LI&gt;MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM (Event 0xD2, Umask 0x04) counts load uops whose data source was a dirty line in another core in the same package.&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Many of the events using the OFFCORE_RESPONSE performance counter events are slightly different between the "client" and "server" Sandy Bridge processors, as described in Tables 19-14 and 19-15 of Volume 3 of the SW Developer's Manual.&amp;nbsp;&amp;nbsp; For the "client" Sandy Bridge parts, it looks like the event OFFCORE_RESPONSE.ALL_RFO.LLC_HIT.HITM_OTHER_CORE_[01] is exactly what you want -- it counts every time a store misses in a core's cache and the cache line is found modified in another core's cache.&amp;nbsp; (These are always "local", since the "client" parts only support a single package per system.)&amp;nbsp;&amp;nbsp; I have not tested this event, but if it works correctly, it should be exactly what you want.&lt;/P&gt;

&lt;P&gt;The "client" parts also have some relevant uncore counters described in Table 19-16, but these are a little harder to use.&lt;/P&gt;

&lt;P&gt;For the "server" Sandy Bridge parts, the preface to Table19-15 notes that a bypass needs to be disabled for the MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM&amp;nbsp; event to be accurate.&amp;nbsp; I think that this should be done automatically by VTune if this event is selected.&amp;nbsp;&amp;nbsp; Intel only lists a subset of the possible OFFCORE_RESPONSE events in Tables 19-14 and 19-15.&amp;nbsp; The ones that are listed are quite likely to work, but other sub-events might also work.&amp;nbsp;&amp;nbsp; The events are described in Section 18.8.5, which should be read in conjunction with the examples in Table 19-15, but this is not easy reading....&lt;/P&gt;</description>
      <pubDate>Mon, 04 Jan 2016 19:13:56 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/profiling-for-false-sharing-on-sandy-bridge/m-p/1072231#M7012</guid>
      <dc:creator>McCalpinJohn</dc:creator>
      <dc:date>2016-01-04T19:13:56Z</dc:date>
    </item>
  </channel>
</rss>

