【问题标题】:Difference Between mem_load_uops_retired.l3_miss and offcore_response.demand_data_rd.l3_miss.local_dram Eventsmem_load_uops_retired.l3_miss 和 offcore_response.demand_data_rd.l3_miss.local_dram 事件之间的区别
【发布时间】:2021-06-01 03:48:27
【问题描述】:

我有一个Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz (Haswell) 处理器。 AFAIK,mem_load_uops_retired.l3_miss,计算DRAM demand(即non-prefetch)数据读取访问次数。顾名思义,offcore_response.demand_data_rd.l3_miss.local_dram 计算针对 DRAM 的 demand 数据读取次数。因此,这两个事件似乎等价(或至少几乎相同)。但根据以下基准,前一个事件频率远低于后者

1) 在 C 的循环中初始化 1000 元素全局数组:

Performance counter stats for '/home/ahmad/Simple Progs/loop':

         1,363      mem_load_uops_retired.l3_miss                                   
         1,543      offcore_response.demand_data_rd.l3_miss.local_dram                                   

   0.000749574 seconds time elapsed

   0.000778000 seconds user
   0.000000000 seconds sys

2) 在 Evince 中打开 PDF 文档:

Performance counter stats for '/opt/evince-3.28.4/bin/evince':

       936,152      mem_load_uops_retired.l3_miss                                   
     1,853,998      offcore_response.demand_data_rd.l3_miss.local_dram                                   

   4.346408203 seconds time elapsed

   1.644826000 seconds user
   0.103411000 seconds sys

3) 运行 Wireshark 5 秒:

Performance counter stats for 'wireshark':

     5,161,671      mem_load_uops_retired.l3_miss                                   
     8,126,526      offcore_response.demand_data_rd.l3_miss.local_dram                                   

  15.713828395 seconds time elapsed

   0.904280000 seconds user
   0.693906000 seconds sys

4) 在 Inkscape 中对图像运行模糊滤镜:

Performance counter stats for 'inkscape':

    13,852,121      mem_load_uops_retired.l3_miss                                   
    23,475,970      offcore_response.demand_data_rd.l3_miss.local_dram                                   

  25.355643897 seconds time elapsed

   7.244404000 seconds user
   1.019895000 seconds sys

所有四个基准测试中,offcore_response.demand_data_rd.l3_miss.local_dram 的频率几乎是mem_load_uops_retired.l3_miss两倍。这合理吗?为什么?请告诉我基准测试是否过于复杂粗粒度

【问题讨论】:

    标签: intel performancecounter perf memory-access intel-pmu


    【解决方案1】:

    据我(目前)所知,下表显示了 Haswell 上这两个事件之间的差异:

    mem_load_uops_retired.l3_miss offcore_response.demand _data_rd.l3_miss.local_dram
    Cacheable Retired Load Uops Per uop per line Y
    Cacheable Non-Retired Load Uops N Y
    Uncacheable WC Retired Load Uops One event per line N
    Uncacheable UC Retired Load Uops May occur N
    Uncacheable WC or UC Non-Retired Load Uops N N
    Locked Loads of any type to any memory type May occur I don't know
    Legacy IO requests May occur N
    L1D Prefetches N Y
    L2 Prefetches into L2 or L3 N N
    Software prefetches with no intention for write N Y
    Page Walk Loads N Y
    Servicing Unit Any Local DRAM
    Reliability May not be reliable Reliable

    现在您应该清楚,这些事件通常根本不等同。此外,比较这两个事件的计数以推断出有意义的事情也不是一件容易的事。

    在您提供的所有示例中,offcore_response.demand_data_rd.l3_miss.local_dram 事件计数大于mem_load_uops_retired.l3_miss 事件计数。但是,不难想出后者大于前者的真实例子。

    在所有四个基准测试中, offcore_response.demand_data_rd.l3_miss.local_dram 几乎是两倍 频繁如 mem_load_uops_retired.l3_miss。这合理吗?

    我认为“几乎两次”的描述实际上仅适用于第二个示例,而不适用于其他示例。如果没有看到确切的代码和执行环境信息,我无法评论您显示的数字。

    【讨论】:

    • 谢谢!这些差异会导致事件发生如此大的差异吗?
    • 打开和关闭Gedit817,014 vs. 1,264,826 / 打开和关闭Libreoffice2,795,660 vs. 3,970,107。在这里,在1.5x 附近。 offcore 事件经常更频繁。应该缺少一些东西
    • @TheAhmad:请注意,在 Hadi 的表中,L1d 预取算作非核心“需求”请求。如果负载的很大一部分实际上是由 L1d 预取器启动的,而不是实际的负载微指令,那可以解释观察结果。 (IDK L1d 预取器看起来有多远,因此它可能无法真正帮助隐藏尽可能多的延迟。此外,其中的一小部分可能是预取或预测执行超出数组末尾的实际负载,其中循环实际上停止了循环。)事实上,mem_load uops 上的实际需求未命中希望较低,这表明预取正在工作。
    • @TheAhmad 分支错误预测和管道刷新或重放的其他原因可能对为什么demand_data_rd.l3_miss.local_dram 可能大于mem_load_uops_retired.l3_miss 起到部分但非常重要的作用。在示例 1 中,这似乎是一个简单的程序,其中大多数负载实际上最终会退出。这里的事件计数相当接近。尽管您同时计算内核和用户模式事件,但这些计数受到系统调用和中断处理程序的干扰。最终,这取决于所分析的确切代码。
    • 首先,谢谢!我认为我应该接受这个信息丰富的答案,直到可能提供一个更彻底的答案。
    猜你喜欢
    • 2011-11-18
    • 2021-07-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-26
    • 2013-05-20
    • 2023-01-26
    相关资源
    最近更新 更多