为什么我的 Intel Skylake/Kaby Lake CPU 在一个简单的散列表实现中会出现神秘的因子3减速?

简而言之:

我已经实现了一个简单的(多键)哈希表,其桶(包含多个元素)完全适合一个缓存。 插入到一个缓冲桶是非常简单的,而且主循环的关键部分。

我已经实现了三个版本,它们产生相同的结果,并且应该具有相同的行为。

神秘

然而,尽管所有版本都具有完全相同的缓存访问模式并导致相同的哈希表数据,但是我发现性能差异惊人地大了3倍。

与我的 CPU (i7-7700HQ)上的 insert_badinsert_alt相比,最好的实现 insert_ok的速度要慢3倍。 一个变体 insert _ bad 是对 insert_ok的一个简单修改,它添加了一个额外的不必要的线性搜索,以便查找要写入的位置(它已经知道了) ,并且不会受到 x3减速的影响。

完全相同的可执行文件显示 insert_ok比其他 CPU (AMD 5950X (Zen 3) ,Intel i7-11800H (Tiger Lake))上的 insert_badinsert_alt快1.6倍。

# see https://github.com/cr-marcstevens/hashtable_mystery
$ ./test.sh
model name      : Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
==============================
CXX=g++    CXXFLAGS=-std=c++11 -O2 -march=native -falign-functions=64
tablesize: 117440512 elements: 67108864 loadfactor=0.571429
- test insert_ok : 11200ms
- test insert_bad: 3164ms
(outcome identical to insert_ok: true)
- test insert_alt: 3366ms
(outcome identical to insert_ok: true)


tablesize: 117440813 elements: 67108864 loadfactor=0.571427
- test insert_ok : 10840ms
- test insert_bad: 3301ms
(outcome identical to insert_ok: true)
- test insert_alt: 3579ms
(outcome identical to insert_ok: true)

准则

// insert element in hash_table
inline void insert_ok(uint64_t k)
{
// compute target bucket
uint64_t b = mod(k);
// bounded linear search for first non-full bucket
for (size_t c = 0; c < 1024; ++c)
{
bucket_t& B = table_ok[b];
// if bucket non-full then store element and return
if (B.size != bucket_size)
{
B.keys[B.size] = k;
B.values[B.size] = 1;
++B.size;
++table_count;
return;
}
// increase b w/ wrap around
if (++b == table_size)
b = 0;
}
}
// equivalent to insert_ok
// but uses a stupid linear search to store the element at the target position
inline void insert_bad(uint64_t k)
{
// compute target bucket
uint64_t b = mod(k);
// bounded linear search for first non-full bucket
for (size_t c = 0; c < 1024; ++c)
{
bucket_t& B = table_bad[b];
// if bucket non-full then store element and return
if (B.size != bucket_size)
{
for (size_t i = 0; i < bucket_size; ++i)
{
if (i == B.size)
{
B.keys[i] = k;
B.values[i] = 1;
++B.size;
++table_count;
return;
}
}
}
// increase b w/ wrap around
if (++b == table_size)
b = 0;
}
}
// instead of using bucket_t.size, empty elements are marked by special empty_key value
// a bucket is filled first to last, so bucket is full if last element key != empty_key
uint64_t empty_key = ~uint64_t(0);
inline void insert_alt(uint64_t k)
{
// compute target bucket
uint64_t b = mod(k);
// bounded linear search for first non-full bucket
for (size_t c = 0; c < 1024; ++c)
{
bucket_t& B = table_alt[b];
// if bucket non-full then store element and return
if (B.keys[bucket_size-1] == empty_key)
{
for (size_t i = 0; i < bucket_size; ++i)
{
if (B.keys[i] == empty_key)
{
B.keys[i] = k;
B.values[i] = 1;
++table_count;
return;
}
}
}
// increase b w/ wrap around
if (++b == table_size)
b = 0;
}
}

我的分析

我已经尝试了对循环 C + + 的各种修改,但它本质上是如此简单,编译器将生成相同的程序集。 从产生的装配结果来看,因子3的损失可能会导致什么并不明显。 我试过用透视法测量,但似乎找不到任何有意义的差异。

比较3个版本的组装,它们都只是相对较小的循环,没有任何迹象表明任何接近的东西可能会导致这些版本之间的因子3损失。

因此,我认为3倍的减速是自动预取、分支预测、指令/跳转对齐或这些因素的组合造成的怪异效果。

是否有人有更好的见解或方法来衡量什么影响可能实际上在这里发挥作用?

细节

我已经创建了一个小的可用的 C + + 11示例来演示这个问题。 该代码可以在 < a href = “ https://github.com/cr-marcstevens/hashtable _ secret”rel = “ norefrer”> https://github.com/cr-marcstevens/hashtable_mystery 找到

这也包括我自己的静态二进制文件,它们在我的 CPU 上演示了这个问题,因为不同的编译器可能产生不同的代码。 以及所有三个哈希表版本的转储程序集代码。

性能事件测量

这里有很多性能事件的度量方法,我重点介绍了包括 missstall在内的一些度量方法。 每个项目有两行:

  • 第一行对应于 insert_ok,它有减速
  • 第二行对应于 insert_alt,它有一个额外的循环和额外的工作,但结束得更快
=== L1-dcache-load-misses ===
insert_ok : 171411476
insert_alt: 244244027
=== L1-dcache-loads ===
insert_ok : 775468123
insert_alt: 1038574743
=== L1-dcache-stores ===
insert_ok : 621353009
insert_alt: 554244145
=== L1-icache-load-misses ===
insert_ok : 69666
insert_alt: 259102
=== LLC-load-misses ===
insert_ok : 70519701
insert_alt: 71399242
=== LLC-loads ===
insert_ok : 130909270
insert_alt: 134776189
=== LLC-store-misses ===
insert_ok : 16782747
insert_alt: 16851787
=== LLC-stores ===
insert_ok : 17072141
insert_alt: 17534866
=== arith.divider_active ===
insert_ok : 26810
insert_alt: 26611
=== baclears.any ===
insert_ok : 2038060
insert_alt: 7648128
=== br_inst_retired.all_branches ===
insert_ok : 546479449
insert_alt: 938434022
=== br_inst_retired.all_branches_pebs ===
insert_ok : 546480454
insert_alt: 938412921
=== br_inst_retired.cond_ntaken ===
insert_ok : 237470651
insert_alt: 433439086
=== br_inst_retired.conditional ===
insert_ok : 477604946
insert_alt: 802468807
=== br_inst_retired.far_branch ===
insert_ok : 1058138
insert_alt: 1052510
=== br_inst_retired.near_call ===
insert_ok : 227076
insert_alt: 227074
=== br_inst_retired.near_return ===
insert_ok : 227072
insert_alt: 227070
=== br_inst_retired.near_taken ===
insert_ok : 307946256
insert_alt: 503926433
=== br_inst_retired.not_taken ===
insert_ok : 237458763
insert_alt: 433429466
=== br_misp_retired.all_branches ===
insert_ok : 36443541
insert_alt: 90626754
=== br_misp_retired.all_branches_pebs ===
insert_ok : 36441027
insert_alt: 90622375
=== br_misp_retired.conditional ===
insert_ok : 36454196
insert_alt: 90591031
=== br_misp_retired.near_call ===
insert_ok : 173
insert_alt: 169
=== br_misp_retired.near_taken ===
insert_ok : 19032467
insert_alt: 40361420
=== branch-instructions ===
insert_ok : 546476228
insert_alt: 938447476
=== branch-load-misses ===
insert_ok : 36441314
insert_alt: 90611299
=== branch-loads ===
insert_ok : 546472151
insert_alt: 938435143
=== branch-misses ===
insert_ok : 36436325
insert_alt: 90597372
=== bus-cycles ===
insert_ok : 222283508
insert_alt: 88243938
=== cache-misses ===
insert_ok : 257067753
insert_alt: 475091979
=== cache-references ===
insert_ok : 445465943
insert_alt: 590770464
=== cpu-clock ===
insert_ok : 10333.94 msec cpu-clock:u # 1.000 CPUs utilized
insert_alt: 4766.53 msec cpu-clock:u # 1.000 CPUs utilized
=== cpu-cycles ===
insert_ok : 25273361574
insert_alt: 11675804743
=== cpu_clk_thread_unhalted.one_thread_active ===
insert_ok : 223196489
insert_alt: 88616919
=== cpu_clk_thread_unhalted.ref_xclk ===
insert_ok : 222719013
insert_alt: 88467292
=== cpu_clk_unhalted.one_thread_active ===
insert_ok : 223380608
insert_alt: 88212476
=== cpu_clk_unhalted.ref_tsc ===
insert_ok : 32663820508
insert_alt: 12901195392
=== cpu_clk_unhalted.ref_xclk ===
insert_ok : 221957996
insert_alt: 88390991
insert_alt: === cpu_clk_unhalted.ring0_trans ===
insert_ok : 374
insert_alt: 373
=== cpu_clk_unhalted.thread ===
insert_ok : 25286801620
insert_alt: 11714137483
=== cycle_activity.cycles_l1d_miss ===
insert_ok : 16278956219
insert_alt: 7417877493
=== cycle_activity.cycles_l2_miss ===
insert_ok : 15607833569
insert_alt: 7054717199
=== cycle_activity.cycles_l3_miss ===
insert_ok : 12987627072
insert_alt: 6745771672
=== cycle_activity.cycles_mem_any ===
insert_ok : 23440206343
insert_alt: 9027220495
=== cycle_activity.stalls_l1d_miss ===
insert_ok : 16194872307
insert_alt: 4718344050
=== cycle_activity.stalls_l2_miss ===
insert_ok : 15350067722
insert_alt: 4578933898
=== cycle_activity.stalls_l3_miss ===
insert_ok : 12697354271
insert_alt: 4457980047
=== cycle_activity.stalls_mem_any ===
insert_ok : 20930005455
insert_alt: 4555461595
=== cycle_activity.stalls_total ===
insert_ok : 22243173394
insert_alt: 6561416461
=== dTLB-load-misses ===
insert_ok : 67817362
insert_alt: 63603879
=== dTLB-loads ===
insert_ok : 775467642
insert_alt: 1038562488
=== dTLB-store-misses ===
insert_ok : 8823481
insert_alt: 13050341
=== dTLB-stores ===
insert_ok : 621353007
insert_alt: 554244145
=== dsb2mite_switches.count ===
insert_ok : 93894397
insert_alt: 315793354
=== dsb2mite_switches.penalty_cycles ===
insert_ok : 9216240937
insert_alt: 206393788
=== dtlb_load_misses.miss_causes_a_walk ===
insert_ok : 177266866
insert_alt: 101439773
=== dtlb_load_misses.stlb_hit ===
insert_ok : 2994329
insert_alt: 35601646
=== dtlb_load_misses.walk_active ===
insert_ok : 4747616986
insert_alt: 3893609232
=== dtlb_load_misses.walk_completed ===
insert_ok : 67817832
insert_alt: 63591832
=== dtlb_load_misses.walk_completed_4k ===
insert_ok : 67817841
insert_alt: 63596148
=== dtlb_load_misses.walk_pending ===
insert_ok : 6495600072
insert_alt: 5987182579
=== dtlb_store_misses.miss_causes_a_walk ===
insert_ok : 89895924
insert_alt: 21841494
=== dtlb_store_misses.stlb_hit ===
insert_ok : 4940907
insert_alt: 21970231
=== dtlb_store_misses.walk_active ===
insert_ok : 1784142210
insert_alt: 903334856
=== dtlb_store_misses.walk_completed ===
insert_ok : 8845884
insert_alt: 13071262
=== dtlb_store_misses.walk_completed_4k ===
insert_ok : 8822993
insert_alt: 12936414
=== dtlb_store_misses.walk_pending ===
insert_ok : 1842905733
insert_alt: 933039119
=== exe_activity.1_ports_util ===
insert_ok : 991400575
insert_alt: 1433908710
=== exe_activity.2_ports_util ===
insert_ok : 782270731
insert_alt: 1314443071
=== exe_activity.3_ports_util ===
insert_ok : 556847358
insert_alt: 1158115803
=== exe_activity.4_ports_util ===
insert_ok : 427323800
insert_alt: 783571280
=== exe_activity.bound_on_stores ===
insert_ok : 299732094
insert_alt: 303475333
=== exe_activity.exe_bound_0_ports ===
insert_ok : 227569792
insert_alt: 348959512
=== frontend_retired.dsb_miss ===
insert_ok : 6771584
insert_alt: 93700643
=== frontend_retired.itlb_miss ===
insert_ok : 1115
insert_alt: 1689
=== frontend_retired.l1i_miss ===
insert_ok : 3639
insert_alt: 3857
=== frontend_retired.l2_miss ===
insert_ok : 2826
insert_alt: 2830
=== frontend_retired.latency_ge_1 ===
insert_ok : 9206268
insert_alt: 178345368
=== frontend_retired.latency_ge_128 ===
insert_ok : 2708
insert_alt: 2703
=== frontend_retired.latency_ge_16 ===
insert_ok : 403492
insert_alt: 820950
=== frontend_retired.latency_ge_2 ===
insert_ok : 4981263
insert_alt: 85781924
=== frontend_retired.latency_ge_256 ===
insert_ok : 802
insert_alt: 970
=== frontend_retired.latency_ge_2_bubbles_ge_1 ===
insert_ok : 56936702
insert_alt: 225712704
=== frontend_retired.latency_ge_2_bubbles_ge_2 ===
insert_ok : 10312026
insert_alt: 163227996
=== frontend_retired.latency_ge_2_bubbles_ge_3 ===
insert_ok : 7599252
insert_alt: 122841752
=== frontend_retired.latency_ge_32 ===
insert_ok : 3599
insert_alt: 3317
=== frontend_retired.latency_ge_4 ===
insert_ok : 2627373
insert_alt: 42287077
=== frontend_retired.latency_ge_512 ===
insert_ok : 418
insert_alt: 241
=== frontend_retired.latency_ge_64 ===
insert_ok : 2474
insert_alt: 2802
=== frontend_retired.latency_ge_8 ===
insert_ok : 528748
insert_alt: 951836
=== frontend_retired.stlb_miss ===
insert_ok : 769
insert_alt: 562
=== hw_interrupts.received ===
insert_ok : 9330
insert_alt: 3738
=== iTLB-load-misses ===
insert_ok : 456094
insert_alt: 90739
=== iTLB-loads ===
insert_ok : 949
insert_alt: 1031
=== icache_16b.ifdata_stall ===
insert_ok : 1145821
insert_alt: 862403
=== icache_64b.iftag_hit ===
insert_ok : 1378406022
insert_alt: 4459469241
=== icache_64b.iftag_miss ===
insert_ok : 61812
insert_alt: 57204
=== icache_64b.iftag_stall ===
insert_ok : 56551468
insert_alt: 82354039
=== idq.all_dsb_cycles_4_uops ===
insert_ok : 896374829
insert_alt: 1610100578
=== idq.all_dsb_cycles_any_uops ===
insert_ok : 1217878089
insert_alt: 2739912727
=== idq.all_mite_cycles_4_uops ===
insert_ok : 315979501
insert_alt: 480165021
=== idq.all_mite_cycles_any_uops ===
insert_ok : 1053703958
insert_alt: 2251382760
=== idq.dsb_cycles ===
insert_ok : 1218891711
insert_alt: 2744099964
=== idq.dsb_uops ===
insert_ok : 5828442701
insert_alt: 10445095004
=== idq.mite_cycles ===
insert_ok : 470409312
insert_alt: 1664892371
=== idq.mite_uops ===
insert_ok : 1407396065
insert_alt: 4515396737
=== idq.ms_cycles ===
insert_ok : 583601361
insert_alt: 587996351
=== idq.ms_dsb_cycles ===
insert_ok : 218346
insert_alt: 74155
=== idq.ms_mite_uops ===
insert_ok : 1266443204
insert_alt: 1277980465
=== idq.ms_switches ===
insert_ok : 149106449
insert_alt: 150392336
=== idq.ms_uops ===
insert_ok : 1266950097
insert_alt: 1277330690
=== idq_uops_not_delivered.core ===
insert_ok : 1871959581
insert_alt: 6531069387
=== idq_uops_not_delivered.cycles_0_uops_deliv.core ===
insert_ok : 289301660
insert_alt: 946930713
=== idq_uops_not_delivered.cycles_fe_was_ok ===
insert_ok : 24668869613
insert_alt: 9335642949
=== idq_uops_not_delivered.cycles_le_1_uop_deliv.core ===
insert_ok : 393750384
insert_alt: 1344106460
=== idq_uops_not_delivered.cycles_le_2_uop_deliv.core ===
insert_ok : 506090534
insert_alt: 1824690188
=== idq_uops_not_delivered.cycles_le_3_uop_deliv.core ===
insert_ok : 688462029
insert_alt: 2416339045
=== ild_stall.lcp ===
insert_ok : 380
insert_alt: 480
=== inst_retired.any ===
insert_ok : 4760842560
insert_alt: 5470438932
=== inst_retired.any_p ===
insert_ok : 4760919037
insert_alt: 5470404264
=== inst_retired.prec_dist ===
insert_ok : 4760801654
insert_alt: 5470649220
=== inst_retired.total_cycles_ps ===
insert_ok : 25175372339
insert_alt: 11718929626
=== instructions ===
insert_ok : 4760805219
insert_alt: 5470497783
=== int_misc.clear_resteer_cycles ===
insert_ok : 199623562
insert_alt: 671083279
=== int_misc.recovery_cycles ===
insert_ok : 314434729
insert_alt: 704406698
=== itlb.itlb_flush ===
insert_ok : 303
insert_alt: 248
=== itlb_misses.miss_causes_a_walk ===
insert_ok : 19537
insert_alt: 116729
=== itlb_misses.stlb_hit ===
insert_ok : 11323
insert_alt: 5557
=== itlb_misses.walk_active ===
insert_ok : 2809766
insert_alt: 4070194
=== itlb_misses.walk_completed ===
insert_ok : 24298
insert_alt: 45251
=== itlb_misses.walk_completed_4k ===
insert_ok : 34084
insert_alt: 29759
=== itlb_misses.walk_pending ===
insert_ok : 853764
insert_alt: 2817933
=== l1d.replacement ===
insert_ok : 171135334
insert_alt: 244967326
=== l1d_pend_miss.fb_full ===
insert_ok : 354631656
insert_alt: 382309583
=== l1d_pend_miss.pending ===
insert_ok : 16792436441
insert_alt: 22979721104
=== l1d_pend_miss.pending_cycles ===
insert_ok : 16377420892
insert_alt: 7349245429
=== l1d_pend_miss.pending_cycles_any ===
insert_ok : insert_alt: === l2_lines_in.all ===
insert_ok : 303009088
insert_alt: 411750486
=== l2_lines_out.non_silent ===
insert_ok : 157208112
insert_alt: 309484666
=== l2_lines_out.silent ===
insert_ok : 127379047
insert_alt: 84169481
=== l2_lines_out.useless_hwpf ===
insert_ok : 70374658
insert_alt: 144359127
=== l2_lines_out.useless_pref ===
insert_ok : 70747103
insert_alt: 142931540
=== l2_rqsts.all_code_rd ===
insert_ok : 71254
insert_alt: 242327
=== l2_rqsts.all_demand_data_rd ===
insert_ok : 137366274
insert_alt: 143507049
=== l2_rqsts.all_demand_miss ===
insert_ok : 150071420
insert_alt: 150820168
=== l2_rqsts.all_demand_references ===
insert_ok : 154854022
insert_alt: 160487082
=== l2_rqsts.all_pf ===
insert_ok : 170261458
insert_alt: 282476184
=== l2_rqsts.all_rfo ===
insert_ok : 17575896
insert_alt: 16938897
=== l2_rqsts.code_rd_hit ===
insert_ok : 79800
insert_alt: 381566
=== l2_rqsts.code_rd_miss ===
insert_ok : 25800
insert_alt: 33755
=== l2_rqsts.demand_data_rd_hit ===
insert_ok : 5191029
insert_alt: 9831101
=== l2_rqsts.demand_data_rd_miss ===
insert_ok : 132253891
insert_alt: 133965310
=== l2_rqsts.miss ===
insert_ok : 305347974
insert_alt: 414758839
=== l2_rqsts.pf_hit ===
insert_ok : 14639778
insert_alt: 19484420
=== l2_rqsts.pf_miss ===
insert_ok : 156092998
insert_alt: 263293430
=== l2_rqsts.references ===
insert_ok : 326549998
insert_alt: 443460029
=== l2_rqsts.rfo_hit ===
insert_ok : 11650
insert_alt: 21474
=== l2_rqsts.rfo_miss ===
insert_ok : 17544467
insert_alt: 16835137
=== l2_trans.l2_wb ===
insert_ok : 157044674
insert_alt: 308107712
=== ld_blocks.no_sr ===
insert_ok : 14
insert_alt: 13
=== ld_blocks.store_forward ===
insert_ok : 158
insert_alt: 128
=== ld_blocks_partial.address_alias ===
insert_ok : 5155853
insert_alt: 17867414
=== load_hit_pre.sw_pf ===
insert_ok : 10840795
insert_alt: 11072297
=== longest_lat_cache.miss ===
insert_ok : 257061118
insert_alt: 471152073
=== longest_lat_cache.reference ===
insert_ok : 445701577
insert_alt: 583870610
=== machine_clears.count ===
insert_ok : 3926377
insert_alt: 4280080
=== machine_clears.memory_ordering ===
insert_ok : 97177
insert_alt: 25407
=== machine_clears.smc ===
insert_ok : 138579
insert_alt: 305423
=== mem-stores ===
insert_ok : 621353009
insert_alt: 554244143
=== mem_inst_retired.all_loads ===
insert_ok : 775473590
insert_alt: 1038559807
=== mem_inst_retired.all_stores ===
insert_ok : 621353013
insert_alt: 554244145
=== mem_inst_retired.lock_loads ===
insert_ok : 85
insert_alt: 85
=== mem_inst_retired.split_loads ===
insert_ok : 171
insert_alt: 174
=== mem_inst_retired.split_stores ===
insert_ok : 53
insert_alt: 49
=== mem_inst_retired.stlb_miss_loads ===
insert_ok : 68308539
insert_alt: 18088047
=== mem_inst_retired.stlb_miss_stores ===
insert_ok : 264054
insert_alt: 819551
=== mem_load_l3_hit_retired.xsnp_none ===
insert_ok : 231116
insert_alt: 175217
=== mem_load_retired.fb_hit ===
insert_ok : 6510722
insert_alt: 95952490
=== mem_load_retired.l1_hit ===
insert_ok : 698271530
insert_alt: 920982402
=== mem_load_retired.l1_miss ===
insert_ok : 69525335
insert_alt: 20089897
=== mem_load_retired.l2_hit ===
insert_ok : 1451905
insert_alt: 773356
=== mem_load_retired.l2_miss ===
insert_ok : 68085186
insert_alt: 19474303
=== mem_load_retired.l3_hit ===
insert_ok : 222829
insert_alt: 155958
=== mem_load_retired.l3_miss ===
insert_ok : 67879593
insert_alt: 19244746
=== memory_disambiguation.history_reset ===
insert_ok : 97621
insert_alt: 25831
=== minor-faults ===
insert_ok : 1048716
insert_alt: 1048718
=== node-loads ===
insert_ok : 71473780
insert_alt: 71377840
=== node-stores ===
insert_ok : 16781161
insert_alt: 16842666
=== offcore_requests.all_data_rd ===
insert_ok : 284186682
insert_alt: 392110677
=== offcore_requests.all_requests ===
insert_ok : 530876505
insert_alt: 777784382
=== offcore_requests.demand_code_rd ===
insert_ok : 34252
insert_alt: 45896
=== offcore_requests.demand_data_rd ===
insert_ok : 133468710
insert_alt: 134288893
=== offcore_requests.demand_rfo ===
insert_ok : 17612516
insert_alt: 17062276
=== offcore_requests.l3_miss_demand_data_rd ===
insert_ok : 71616594
insert_alt: 82917520
=== offcore_requests_buffer.sq_full ===
insert_ok : 2001445
insert_alt: 3113287
=== offcore_requests_outstanding.all_data_rd ===
insert_ok : 35577129549
insert_alt: 78698308135
=== offcore_requests_outstanding.cycles_with_data_rd ===
insert_ok : 17518017620
insert_alt: 7940272202
=== offcore_requests_outstanding.demand_code_rd ===
insert_ok : 11085819
insert_alt: 9390881
=== offcore_requests_outstanding.demand_data_rd ===
insert_ok : 15902243707
insert_alt: 21097348926
=== offcore_requests_outstanding.demand_data_rd_ge_6 ===
insert_ok : 1225437
insert_alt: 317436422
=== offcore_requests_outstanding.demand_rfo ===
insert_ok : 1074492442
insert_alt: 1157902315
=== offcore_response.demand_code_rd.any_response ===
insert_ok : 53675
insert_alt: 69683
=== offcore_response.demand_code_rd.l3_hit.any_snoop ===
insert_ok : 19407
insert_alt: 29704
=== offcore_response.demand_code_rd.l3_hit.snoop_none ===
insert_ok : 12675
insert_alt: 11951
=== offcore_response.demand_code_rd.l3_miss.any_snoop ===
insert_ok : 34617
insert_alt: 40868
=== offcore_response.demand_code_rd.l3_miss.spl_hit ===
insert_ok : 0
insert_alt: 753
=== offcore_response.demand_data_rd.any_response ===
insert_ok : 131014821
insert_alt: 134813171
=== offcore_response.demand_data_rd.l3_hit.any_snoop ===
insert_ok : 59713328
insert_alt: 50254543
=== offcore_response.demand_data_rd.l3_miss.any_snoop ===
insert_ok : 71431585
insert_alt: 83916030
=== offcore_response.demand_data_rd.l3_miss.spl_hit ===
insert_ok : 244837
insert_alt: 6441992
=== offcore_response.demand_rfo.any_response ===
insert_ok : 16876557
insert_alt: 17619450
=== offcore_response.demand_rfo.l3_hit.any_snoop ===
insert_ok : 907432
insert_alt: 45127
=== offcore_response.demand_rfo.l3_hit.snoop_none ===
insert_ok : 787567
insert_alt: 794579
=== offcore_response.demand_rfo.l3_hit_e.any_snoop ===
insert_ok : 496938
insert_alt: 173658
=== offcore_response.demand_rfo.l3_hit_e.snoop_none ===
insert_ok : 779919
insert_alt: 50575
=== offcore_response.demand_rfo.l3_hit_m.any_snoop ===
insert_ok : 128627
insert_alt: 25483
=== offcore_response.demand_rfo.l3_miss.any_snoop ===
insert_ok : 16782186
insert_alt: 16847970
=== offcore_response.demand_rfo.l3_miss.snoop_none ===
insert_ok : 16782647
insert_alt: 16850104
=== offcore_response.demand_rfo.l3_miss.spl_hit ===
insert_ok : 0
insert_alt: 1364
=== offcore_response.other.any_response ===
insert_ok : 137231000
insert_alt: 189526494
=== offcore_response.other.l3_hit.any_snoop ===
insert_ok : 62695084
insert_alt: 51005882
=== offcore_response.other.l3_hit.snoop_none ===
insert_ok : 62975018
insert_alt: 50217349
=== offcore_response.other.l3_hit_e.any_snoop ===
insert_ok : 62770215
insert_alt: 50691817
=== offcore_response.other.l3_hit_e.snoop_none ===
insert_ok : 62602591
insert_alt: 50642954
=== offcore_response.other.l3_miss.any_snoop ===
insert_ok : 74247236
insert_alt: 139212975
=== offcore_response.other.l3_miss.snoop_none ===
insert_ok : 75911794
insert_alt: 141076520
=== other_assists.any ===
insert_ok : 1
insert_alt: 3
=== page-faults ===
insert_ok : 1048719
insert_alt: 1048718
=== partial_rat_stalls.scoreboard ===
insert_ok : 530950991
insert_alt: 539869553
=== ref-cycles ===
insert_ok : 32546980212
insert_alt: 12930921138
=== resource_stalls.any ===
insert_ok : 21923576648
insert_alt: 5205690082
=== resource_stalls.sb ===
insert_ok : 397908667
insert_alt: 402738367
=== rs_events.empty_cycles ===
insert_ok : 1173721723
insert_alt: 1880165720
=== rs_events.empty_end ===
insert_ok : 87752182
insert_alt: 160792701
=== sw_prefetch_access.t0 ===
insert_ok : 20835202
insert_alt: 20599176
=== task-clock ===
insert_ok : 10416.86 msec task-clock:u # 1.000 CPUs utilized
insert_alt: 4767.78 msec task-clock:u # 1.000 CPUs utilized
=== tlb_flush.stlb_any ===
insert_ok : 1835393
insert_alt: 1835396
=== topdown-fetch-bubbles ===
insert_ok : 1904143421
insert_alt: 6543146396
=== topdown-slots-issued ===
insert_ok : 7538371393
insert_alt: 14449966516
=== topdown-slots-retired ===
insert_ok : 5267325162
insert_alt: 5849706597
=== uops_dispatched_port.port_0 ===
insert_ok : 1252121297
insert_alt: 1489605354
=== uops_dispatched_port.port_1 ===
insert_ok : 1379316967
insert_alt: 1585037107
=== uops_dispatched_port.port_2 ===
insert_ok : 1140861153
insert_alt: 1785053149
=== uops_dispatched_port.port_3 ===
insert_ok : 1187151423
insert_alt: 1828975838
=== uops_dispatched_port.port_4 ===
insert_ok : 1577171758
insert_alt: 1557761857
=== uops_dispatched_port.port_5 ===
insert_ok : 1341370655
insert_alt: 1653599117
=== uops_dispatched_port.port_6 ===
insert_ok : 1856735970
insert_alt: 4387464794
=== uops_dispatched_port.port_7 ===
insert_ok : 508351498
insert_alt: 603583315
=== uops_executed.core ===
insert_ok : 7225522677
insert_alt: 12716368190
=== uops_executed.core_cycles_ge_1 ===
insert_ok : 3041586797
insert_alt: 5168421550
=== uops_executed.core_cycles_ge_2 ===
insert_ok : 2017794537
insert_alt: 3653591208
=== uops_executed.core_cycles_ge_3 ===
insert_ok : 1225785335
insert_alt: 2316014066
=== uops_executed.core_cycles_ge_4 ===
insert_ok : 657121809
insert_alt: 1143390519
=== uops_executed.core_cycles_none ===
insert_ok : 22191507320
insert_alt: 6563722081
=== uops_executed.cycles_ge_1_uop_exec ===
insert_ok : 3040999757
insert_alt: 5175668459
=== uops_executed.cycles_ge_2_uops_exec ===
insert_ok : 2015520940
insert_alt: 3659989196
=== uops_executed.cycles_ge_3_uops_exec ===
insert_ok : 1224025952
insert_alt: 2319025110
=== uops_executed.cycles_ge_4_uops_exec ===
insert_ok : 657094113
insert_alt: 1141381027
=== uops_executed.stall_cycles ===
insert_ok : 22350754164
insert_alt: 6590978048
=== uops_executed.thread ===
insert_ok : 7214521925
insert_alt: 12697219901
=== uops_executed.x87 ===
insert_ok : 2992
insert_alt: 3337
=== uops_issued.any ===
insert_ok : 7531354736
insert_alt: 14462113169
=== uops_issued.slow_lea ===
insert_ok : 2136241
insert_alt: 2115308
=== uops_issued.stall_cycles ===
insert_ok : 23244177475
insert_alt: 7416801878
=== uops_retired.macro_fused ===
insert_ok : 410461916
insert_alt: 735050350
=== uops_retired.retire_slots ===
insert_ok : 5265023980
insert_alt: 5855259326
=== uops_retired.stall_cycles ===
insert_ok : 23513958928
insert_alt: 9630258867
=== uops_retired.total_cycles ===
insert_ok : 25266688635
insert_alt: 11703285605

背景资料

我正在用 C + + 11实现一个密码分析攻击,需要找到两个大型列表(都是动态生成的)之间的许多冲突。 因此,攻击的关键部分只包括两个关键循环:

  1. 首先用一个列表填充哈希表
  2. 然后将其他列表与哈希表进行匹配。

因此,哈希表操作对性能至关重要,因子3的减速意味着攻击的速度减慢了3倍。

关于设计: 除了尽量减少内存使用之外,我还试图让一个典型的哈希表操作仅在一个单独的缓存上进行操作。正如我预期的那样,这将提高整体攻击性能,特别是在运行所有 CPU 核心的攻击时。

5662 次浏览

摘要

TLDR 是指那些错过 TLB 的所有级别(因此需要进行页遍历)并且被 地址未知存储区分隔开的负载不能并行执行,也就是说,负载被序列化并且 内存级并行性(MLP)因子被限制在1。实际上,存储 篱笆的负载,很像 lfence

插入函数的缓慢版本会导致出现这种情况,而其他两种情况则不会(存储地址已知)。对于较大的区域,内存访问模式占主导地位,性能几乎与 MLP 直接相关: 快速版本可以重叠加载错过,得到大约3的 MLP,导致3倍的加速(我们下面讨论的较窄的再现情况可以显示超过 10倍在 Skylake 上的差异)。

潜在的原因似乎是 Skylake 处理器试图维护 页表连贯性页表连贯性,这不是规范所要求的,但可以解决软件中的 bug。

细节

对于那些感兴趣的人,我们将深入挖掘正在发生的事情的细节。

我可以在我的 Skylake i7-6700HQ 机器上立即重现这个问题,通过剔除多余的部分,我们可以将原来的 hash 插入基准减少到这个简单的循环中,它展示了同样的问题:

tlb_fencing:


xor     eax, eax  ; the index pointer
mov     r9 , [rsi + region.start]


mov     r8 , [rsi + region.size]
sub     r8 , 200                   ; pointer to end of region (plus a bit of buffer)


mov     r10, [rsi + region.size]
sub     r10, 1 ; mask


mov     rsi, r9   ; region start


.top:
mov     rcx, rax
and     rcx, r10        ; remap the index into the region via masking
add     rcx, r9         ; make pointer p into the region
mov     rdx, [rcx]      ; load 8 bytes at p, always zero
xor     rcx, rcx        ; no-op
mov     DWORD [rsi + rdx + 160], 0 ; store zero at p + 160
add     rax, (64 * 67)  ; advance a prime number of cache lines slightly larger than a page


dec     rdi
jnz     .top


ret

这大致相当于 insert_ok4最内层循环的 B.size访问(负载)和 B.values[B.size] = 1访问(存储)。

专注于循环,我们做一个跨步装载和一个固定的存储。然后将加载位置向前移动一点,大于页面的大小(4KiB)。重要的是,存储地址 取决于是加载的结果: 因为寻址表达式 [rsi + rdx + 160]包含 rdxrdx是保存加载的 value1的寄存器。存储总是出现在相同的地址上,因为循环中没有地址组件发生更改(所以我们期望总是出现 L1缓存命中)。

最初的哈希示例做了更多的工作,随机访问内存,并让存储与加载相同的行,但是这个简单的循环捕获了相同的效果。

我们还使用了基准测试的另一个版本,除了负载和存储之间的非操作 xor rcx, rcxxor rdx, rdx替换之外,它们是相同的。这个 休息负载和存储地址之间的依赖关系。

天真地说,我们并不指望这种依赖性能起多大作用。这里的存储是 火与忘记:,我们不会再次从存储位置读取(至少在很多次迭代中不会) ,因此它们不属于任何附带的依赖链。对于较小的区域,我们期望瓶颈仅仅是通过 ~ 8 uops 的咀嚼,对于较大的区域,我们期望处理所有缓存错误的时间占主导地位: 关键的是,我们期望许多错误并行处理,因为加载地址可以独立于简单的非内存 uops 计算。

以下是区域大小从4KiB 到256MiB 的性能周期,有以下三种变化:

2M dep: 使用 2个 MiB 巨大的页面执行上面显示的循环(存储地址取决于负载)。

4K dep: 上面显示的循环(存储地址取决于负载)使用标准的4KiB 页面。

4K indp: 上述循环的变体,使用4 KiB 页面,用 xor rdx, rdx代替 xor rcx, rcx来打破加载结果和存储地址之间的依赖关系。

结果是:

Shows the dep case sucking when region is 8 MiB or more

对于较小的区域大小,所有变体的性能基本相同。一切高达256KiB 需要2个周期/迭代,仅仅受限于循环中的8个 uops 和 CPU 宽度为4个单位/周期。一点数学计算表明我们有不错的 MLP (内存级别并行性) : 一个 L2缓存命中有12个周期的延迟,但是我们每2个周期完成一个,所以平均来说我们必须重叠6个 L1错过的延迟才能达到。

在256KiB 和4096KiB 之间,随着 L3命中的开始,性能有所下降,但性能很好,MLP 很高。

在8196 KiB 的性能下降灾难性的 只有4K 的的情况下,跨越150个周期,最终稳定在约220个周期。它比 十次慢,比其他两例 2慢。

我们已经可以提出一些关键的意见:

  • 2米深4K都是快速的: 所以这不是关于存储之间的依赖关系的 只是,而是关于分页行为的。
  • 2米深的情况是最快的,所以我们知道依赖关系不会导致一些基本的问题,即使当您错过了内存。
  • 慢速 4K 的情况下的性能与我的机器的内存延迟非常相似。

我在上面提到了 MLP,并根据观察到的性能计算了 MLP 的下限,但是在 Intel CPU 上,我们可以直接使用两个性能计数器来度量 MLP:

l1d_pend_miss.pending

计算 L1D 未完成的持续时间,即需求读取要求的未完成填充缓冲区(FB)的每个周期数。

l1d_pend_miss.pending_cycles

L1D 负载的自行车未达标

第一个计数,每个周期,有多少请求是从 L1D 未完成。因此,如果3次未命中正在进行中,该计数器每周期增加3次。第二个计数器增量1每个周期至少 错过是在进行中。你可以把它看作是第一个计数器的一个版本,它在每个周期1饱和。这些计数器在一段时间内的比值 l1d_pend_miss.pending / l1d_pend_miss.pending_cycles是 MLP 因子的平均值,而任何失误都是优秀的 3

让我们描绘出4K 基准的 Dep确实版本的 MLP 比率:

Shows that MLP tanks in the 4K dep case to 1 at 8 MiB

问题变得非常明显。直到4096 KiB 的区域,性能是相同的,MLP 是高的(对于非常小的区域大小有“没有”MLP,因为没有 L1D 失误在所有)。突然在8192 KiB,依赖情况下的 MLP 下降到1并停留在那里,而在独立情况下,MLP 几乎达到10。仅此一项就基本上解释了10倍的性能差异: 相关情况根本不能重叠负载。

为什么?问题似乎是 TLB 未击中。在8192 KiB 时发生的情况是,基准开始缺少 TLB。具体来说,每个 Skylake 核心有1536个 STLB (二级 TLB)条目,可以覆盖1536 × 4096 = 6MiB 的4K 页面。因此,在4到8个 MiB 区域大小之间,基于 dtlb_load_misses.walk_completed的 TLB 错过率达到每次迭代1,导致了这个几乎完美的假情节:

Shows that 1.0 page walks are done for both 4k cases at 8 MiB

这就是发生的情况: 当地址未知的存储在存储缓冲区中时,错过 STLB 的负载不能重叠: 它们一次一个。所以每次访问都要承受完整的内存延迟。这也解释了为什么2 MB 的页面大小是快速的: 2 MB 的页面可以覆盖3 GiB 的内存,所以对于这些区域大小没有 STLB 遗漏/页面遍历。

为什么

这种行为似乎源于 Skylake 和其他早期的 Intel 处理器实现了 页表连贯性,,尽管 x86平台并不需要它。页表一致性意味着,如果存储修改了地址映射(例如) ,那么使用受重映射影响的虚拟地址的后续加载将始终看到新的映射,而不会显式刷新。

这个观点来自于 Henry Wong,他在他的 关于页面行走连贯性的优秀文章报告中指出,如果在行走过程中遇到冲突或者 地址未知的存储器,那么页面行走就会被终止:

出乎意料的是,尽管没有修改页表,Intel Core 2和更新的系统表现得好像出现了页行一致性误解。这些系统具有内存依赖性预测,因此负载应该比存储更早地执行,并打破数据依赖链。

事实证明,正是早期执行的负载导致了错误检测的误判。这给出了一个关于如何检测一致性违规的提示: 通过比较 pagewalk 和已知的旧存储地址(在存储队列中?),并假设一致性违反,如果有一个冲突或未知地址的旧商店。

因此,即使这些存储是完全无害的,因为它们没有修改任何页表,它们也会陷入页表一致性机制中。通过观察事件 dtlb_load_misses.miss_causes_a_walk,我们可以找到这个理论的进一步证据。与 walk_completed事件不同的是,即使 开始了没有成功完成,它也会计算所有的行走次数。这一个看起来像这样(再次说明,2M 没有显示,因为它根本没有开始页面步行) :

Shows that the dep case has slightly more than 2 walks per iteration

哈!4K 依赖显示 已经开始行走,只有一个行走成功完成。那就是每载一批货要走两次路。这与迭代 N + 1中负载的页遍历开始的理论一致,但是它发现来自迭代 N 的存储仍然位于存储缓冲区中(因为迭代 N 的负载提供了它的地址,并且它仍然在进行中)。由于地址未知,正如亨利所描述的,页面行走被取消了。在解析存储地址之前,将延迟进一步的页遍历。结果是所有加载都以序列化的方式完成,因为加载 N + 1的页遍历必须等待加载 N 的结果。

为什么“ Bad”和“ alt”方法都很快

最后,还有一个未解之谜。上面解释了为什么最初的 hash 访问很慢,但是没有解释为什么其他两个很快。关键是这两个快速方法都没有地址未知的存储,因为与负载的数据依赖关系被推测性的控制依赖关系所替代。

看看 insert_bad方法的内部循环:

for (size_t i = 0; i < bucket_size; ++i)
{
if (i == B.size)
{
B.keys[i] = k;
B.values[i] = 1;
++B.size;
++table_count;
return;
}
}

注意,这些存储使用循环索引 i。与索引 [B.size]来自存储的 insert_ok情况不同,i只是寄存器中的一个计算值。现在 i相关的到加载值 B.size,因为它的最终值将是 平等到它,但是这是通过比较建立的,这是一个推测的控制依赖关系。它不会导致取消页行走的任何问题。这个场景确实有很多错误预测(因为循环出口是不可预测的) ,但是对于大区域来说,这些错误预测实际上并没有太大的危害,因为错误路径通常与正确路径进行相同的内存访问(具体来说,下一个插入的值总是相同的) ,内存访问行为占主导地位。

对于 alt情况也是如此: 使用计算值 i加载一个值,检查它是否是特殊标记值,然后使用索引 i在该位置写入,从而建立要写入的索引。同样,没有延迟存储地址,只有一个快速计算的寄存器值和一个推测的控制依赖项。

其他硬件呢

和问题作者一样,我发现了对 Skylake 的影响,但我也在 Haswell 身上观察到了同样的行为。在冰湖上,我不能复制它: Dep确实都有几乎相同的性能。

然而,用户 Noah 使用原始基准测试进行某些对齐。我认为最有可能的原因是 TGL 不受这种页面行走行为的影响,而是在某些对齐中,内存消歧预测器发生碰撞,导致了非常相似的效果: 加载无法在早期地址未知存储之前执行,因为处理器认为存储可能会转发到加载。

自己做

您可以运行我在上面描述的基准。这是 长椅的一部分。在 Linux (或 WSL,但是性能计数器不可用)上,您可以运行以下命令来收集结果:

for s in 2M-dep 4K-dep 4K-indep; do ./uarch-bench --timer=perf --test-name="studies/memory/tlb-fencing/*$s" --extra-events=dtlb_load_misses.miss_causes_a_walk#walk_s,dtlb_load_misses.walk_completed#walk_c,l1d_pend_miss.pending#l1d_p,l1d_pend_miss.pending_cycles#l1d_pc; done

有些系统可能没有足够的可用性能计数器(如果启用了超线程) ,因此每次可以使用不同的计数器集执行两次运行。


1 在这种情况下,rdx始终是零(该区域完全是零) ,所以存储地址碰巧与这个寄存器没有包含在寻址表达式中一样,但是 CPU 不知道这一点!

在这里,虽然差距不大,但是 2米深情况也开始显示出比 4K情况更好的表现。

3 注意“尽管任何失误是突出的”部分: 你也可以计算 MLP 作为 l1d_pend_miss.pending / cycles,这将是一段时间内的平均 MLP,不管是否有任何失误是突出的。每种方法都有自己的用处,但在这种情况下,如果错误不断出现,它们给出的值几乎相同。

是的,这个例子和原来的例子有很多不同之处。我们存储到一个单一的固定位置,而原始循环存储在负载位置附近,这会改变每次迭代。我们存储0而不是1。我们不检查 B.size是否太大。在我们的测试中,加载的值总是0。没有针对桶满时的搜索循环。我们不加载要寻址的随机值,只是做一个线性步长。然而,这些都不是实质性的: 两种情况下都会出现相同的效果,您可以通过删除复杂性来增量地修改原始示例,直到达到这个简单的情况。