orm*_*orm 6 c++ x86-64 transactional-memory intel gcc4.8
我正在尝试使用haswell中的tsx扩展,通过调整现有的中型(1000行)代码库来使用GCC事务内存扩展(在本机中间接使用haswell tsx)而不是粗粒度锁.我正在使用GCC的transactional_memory扩展,而不是直接编写我自己的_xbegin/_xend.我正在使用ITM_DEFAULT_METHOD = htm
我遇到问题让它工作得足够快,因为我因为神秘的原因而导致高速率的硬件事务中止.如下所示,这些中止不是由于冲突,也不是由于容量限制.
这是我用来量化失败率和根本原因的perf命令:
perf stat \
-e cpu/event=0x54,umask=0x2,name=tx_mem_abort_capacity_write/ \
-e cpu/event=0x54,umask=0x1,name=tx_mem_abort_conflict/ \
-e cpu/event=0x5d,umask=0x1,name=tx_exec_misc1/ \
-e cpu/event=0x5d,umask=0x2,name=tx_exec_misc2/ \
-e cpu/event=0x5d,umask=0x4,name=tx_exec_misc3/ \
-e cpu/event=0x5d,umask=0x8,name=tx_exec_misc4/ \
-e cpu/event=0x5d,umask=0x10,name=tx_exec_misc5/ \
-e cpu/event=0xc9,umask=0x1,name=rtm_retired_start/ \
-e cpu/event=0xc9,umask=0x2,name=rtm_retired_commit/ \
-e cpu/event=0xc9,umask=0x4,name=rtm_retired_aborted/pp \
-e cpu/event=0xc9,umask=0x8,name=rtm_retired_aborted_misc1/ \
-e cpu/event=0xc9,umask=0x10,name=rtm_retired_aborted_misc2/ \
-e cpu/event=0xc9,umask=0x20,name=rtm_retired_aborted_misc3/ \
-e cpu/event=0xc9,umask=0x40,name=rtm_retired_aborted_misc4/ \
-e cpu/event=0xc9,umask=0x80,name=rtm_retired_aborted_misc5/ \
./myprogram -th 1 -reps 3000000
Run Code Online (Sandbox Code Playgroud)
因此,该程序运行一些代码,其中包含3000万次交易.每个请求都涉及一个事务gcc __transaction_atomic块.此次运行中只有一个线程.
此特定perf命令捕获英特尔软件开发人员手册第3卷中描述的大多数相关tsx性能事件.
输出perf stat如下:
0 tx_mem_abort_capacity_write [26.66%]
0 tx_mem_abort_conflict [26.65%]
29,937,894 tx_exec_misc1 [26.71%]
0 tx_exec_misc2 [26.74%]
0 tx_exec_misc3 [26.80%]
0 tx_exec_misc4 [26.92%]
0 tx_exec_misc5 [26.83%]
29,906,632 rtm_retired_start [26.79%]
0 rtm_retired_commit [26.70%]
29,985,423 rtm_retired_aborted [26.66%]
0 rtm_retired_aborted_misc1 [26.75%]
0 rtm_retired_aborted_misc2 [26.73%]
29,927,923 rtm_retired_aborted_misc3 [26.71%]
0 rtm_retired_aborted_misc4 [26.69%]
176 rtm_retired_aborted_misc5 [26.67%]
10.583607595 seconds time elapsed
Run Code Online (Sandbox Code Playgroud)
从输出中可以看出:
rtm_retired_start数为30万美元(相匹配的输入程序)rtm_retired_abort计数是差不多的(没有在所有提交)abort_conflict和abort_capacity计数为0,所以这些都不是理由.另外,回想起它只有一个线程在运行,冲突应该是罕见的.tx_exec_misc1和rtm_retired_aborted_misc3,这是在描述有些相似.英特尔手册(第3卷)定义了rtm_retired_aborted_misc3计数器:
代码:C9H 20H
助记符:RTM_RETIRED.ABORTED_MISC3
description:由于HLE不友好的指令导致RTM执行中止的次数.
定义tx_exec_misc1有一些相似的词:
代码:5DH 01H
助记符:TX_EXEC.MISC1
description:计算可能导致事务中止的一类指令被执行的次数.由于这是执行计数,因此可能并不总是导致事务中止.
我使用高精度(PEBS)支持的perf记录/性能报告检查了中止的装配位置rtm_retired_aborted.该位置具有mov从注册到注册的指令.附近没有看到奇怪的指令名称.
更新:
以下是我从那时起尝试的两件事:
1)我们在这里看到的tx_exec_misc1和rtm_retired_aborted_misc3签名可以通过表格的虚拟块获得
for (int i = 0; i < 10000000; i++){
__transaction_atomic{
_xabort(1);
}
}
Run Code Online (Sandbox Code Playgroud)
或其中一种形式
for (int i = 0; i < 10000000; i++){
__transaction_atomic{
printf("hello");
fflush(stdout);
}
}
Run Code Online (Sandbox Code Playgroud)
在这两种情况下,性能计数器看起来与我看到的相似.但是,在两种情况下perf report,-e cpu/tx-abort/ 指向直观正确的装配线:xabort第一个示例的指令和syscall第二个示例的指令.在实际的代码库中,perf报告指向函数开头的堆栈推送:
: 00000000004167e0 <myns::myfun()>:
100.00 : 4167e0: push %rbp
0.00 : 4167e1: mov %rsp,%rbp
0.00 : 4167e4: push %r15
Run Code Online (Sandbox Code Playgroud)
我也在intel软件开发模拟器下运行相同的命令.事实证明,在这种情况下问题就消失了:就应用程序而言,我没有中止.
| 归档时间: |
|
| 查看次数: |
693 次 |
| 最近记录: |