<?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 CYCLE_ACTIVITY.CYCLES_L1D in Software Tuning, Performance Optimization &amp; Platform Monitoring</title>
    <link>https://community.intel.com/t5/Software-Tuning-Performance/difference-between-STALLS-L1D-PENDING-and-CYCLES-L1D-PENDING/m-p/996944#M3476</link>
    <description>&lt;P&gt;CYCLE_ACTIVITY.CYCLES_L1D_PENDING increments in each processor cycle if there is at least one L1 Data Cache load miss outstanding.&lt;/P&gt;

&lt;P&gt;CYCLE_ACTIVITY.STALLS_L1D_PENDING increments in each processor cycle if there is *both* at least one L1 Data Cache load miss outstanding *AND* no uops are dispatched to the execution ports.&lt;/P&gt;

&lt;P&gt;The latter event is intended to help identify cases in which cache misses are the cause of the stall.&amp;nbsp;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;This should be understood as an *indication*, not as proof that the cache miss(es) actually caused the stall.&amp;nbsp; (In an out-of-order processor there are too many ambiguous cases -- for example how do you assign "blame" when the processor is stalled for multiple reasons in the same cycle?&lt;/P&gt;

&lt;P&gt;I don't think that I have tested this carefully yet, but I expect this event to systematically under-count.&amp;nbsp; The problem is that the processor does not know if the data is in the cache, so it can "dispatch" memory load uops to the execution port(s) multiple times.&amp;nbsp; If the data is not in the L1 Data Cache, the uop is rejected and retried later.&amp;nbsp; The counters cannot distinguish between uops that are dispatched and complete vs uops that are dispatched and rejected, so this event will *not* count cycles in the latter category as stall cycles -- even though most of us would consider that to be a stall cycle for practical purposes.&lt;/P&gt;</description>
    <pubDate>Thu, 18 Sep 2014 19:56:33 GMT</pubDate>
    <dc:creator>McCalpinJohn</dc:creator>
    <dc:date>2014-09-18T19:56:33Z</dc:date>
    <item>
      <title>difference between STALLS_L1D_PENDING and CYCLES_L1D_PENDING</title>
      <link>https://community.intel.com/t5/Software-Tuning-Performance/difference-between-STALLS-L1D-PENDING-and-CYCLES-L1D-PENDING/m-p/996943#M3475</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;

&lt;P&gt;what is the difference between CYCLE_ACTIVITY:CYCLES_L1D_PENDING and CYCLE_ACTIVITY:STALLS_L1D_PENDING events for IVY-BRIDGE processors. Is it that STALLS indicate number of times executing stalled and CYCLES_ indicate the total time in cycles for the stalls?&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;&lt;BR /&gt;
	&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 17 Sep 2014 23:02:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Tuning-Performance/difference-between-STALLS-L1D-PENDING-and-CYCLES-L1D-PENDING/m-p/996943#M3475</guid>
      <dc:creator>Aditya_D_</dc:creator>
      <dc:date>2014-09-17T23:02:00Z</dc:date>
    </item>
    <item>
      <title>CYCLE_ACTIVITY.CYCLES_L1D</title>
      <link>https://community.intel.com/t5/Software-Tuning-Performance/difference-between-STALLS-L1D-PENDING-and-CYCLES-L1D-PENDING/m-p/996944#M3476</link>
      <description>&lt;P&gt;CYCLE_ACTIVITY.CYCLES_L1D_PENDING increments in each processor cycle if there is at least one L1 Data Cache load miss outstanding.&lt;/P&gt;

&lt;P&gt;CYCLE_ACTIVITY.STALLS_L1D_PENDING increments in each processor cycle if there is *both* at least one L1 Data Cache load miss outstanding *AND* no uops are dispatched to the execution ports.&lt;/P&gt;

&lt;P&gt;The latter event is intended to help identify cases in which cache misses are the cause of the stall.&amp;nbsp;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;This should be understood as an *indication*, not as proof that the cache miss(es) actually caused the stall.&amp;nbsp; (In an out-of-order processor there are too many ambiguous cases -- for example how do you assign "blame" when the processor is stalled for multiple reasons in the same cycle?&lt;/P&gt;

&lt;P&gt;I don't think that I have tested this carefully yet, but I expect this event to systematically under-count.&amp;nbsp; The problem is that the processor does not know if the data is in the cache, so it can "dispatch" memory load uops to the execution port(s) multiple times.&amp;nbsp; If the data is not in the L1 Data Cache, the uop is rejected and retried later.&amp;nbsp; The counters cannot distinguish between uops that are dispatched and complete vs uops that are dispatched and rejected, so this event will *not* count cycles in the latter category as stall cycles -- even though most of us would consider that to be a stall cycle for practical purposes.&lt;/P&gt;</description>
      <pubDate>Thu, 18 Sep 2014 19:56:33 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Tuning-Performance/difference-between-STALLS-L1D-PENDING-and-CYCLES-L1D-PENDING/m-p/996944#M3476</guid>
      <dc:creator>McCalpinJohn</dc:creator>
      <dc:date>2014-09-18T19:56:33Z</dc:date>
    </item>
  </channel>
</rss>

