考虑以下程序:
#include <pthread.h>
static int final_value = 0;
#ifdef TLS_VAR
static int __thread tls_var;
#else
static int tls_var;
#endif
void __attribute__ ((noinline)) modify_tls(void) {
tls_var++;
}
void *thread_function(void *unused) {
const int iteration_count = 1 << 25;
tls_var = 0;
for (int i = 0; i < iteration_count; i++) {
modify_tls();
}
final_value += tls_var;
return NULL;
}
int main() {
const int thread_count = 1 << 7;
pthread_t thread_ids[thread_count];
for (int i = 0; i < thread_count; i++) {
pthread_create(&thread_ids[i], NULL, thread_function, NULL);
}
for (int i = 0; i < thread_count; i++) {
pthread_join(thread_ids[i], NULL);
}
return 0;
}
在我的 i7 上,使用
TLS_VAR
定义和执行需要 1.308 秒8.392 秒未定义;我无法解释如此巨大的
区别。
modify_tls
的程序集看起来像这样(我只提到了不同的部分):
;; !defined(TLS_VAR)
movl tls_var(%rip), %eax
addl $1, %eax
movl %eax, tls_var(%rip)
;; defined(TLS_VAR)
movl %fs:tls_var@tpoff, %eax
addl $1, %eax
movl %eax, %fs:tls_var@tpoff
TLS 查找是可以理解的,带有来自 TCB 的负载。但为什么
第一种情况下的
tls_var
负载是相对于 %rip
的吗?为什么不能它是由加载程序重新定位的直接内存地址吗?是
这个
%rip
相对负载导致缓慢?如果是这样,为什么?编译标志:
gcc -O3 -std=c99 -Wall -Werror -lpthread
最佳答案
如果没有 __thread
属性,tls_var
只是一个共享变量。每当一个线程写入它时,写入首先进入内核的缓存,线程在那里执行。但是由于它是一个共享变量并且 x86 机器是缓存一致的,其他内核的缓存会失效,并且它们的内容从上一级缓存或主内存中刷新(在您的情况下很可能来自上一级缓存,这是 Core i7 上的共享 L3 缓存)。请注意,虽然比主内存快,但最后一级缓存并不是无限快 - 将数据从那里移到 L2 和 L1 缓存(每个内核私有(private))仍然需要很多周期。
使用 __thread
属性,每个线程都会获得自己的 tls_var
副本,位于线程本地存储中。由于这些线程本地存储在内存中彼此相距很远,因此在修改它们时不涉及缓存一致性消息,并且数据保留在最快的 L1 缓存中。RIP
相关寻址(System V ABI 推荐的 x64 默认寻址模式“近”数据)通常会导致更快的数据访问,但缓存一致性开销非常大,以至于当所有内容都保留时,较慢的 TLS 访问实际上更快在 L1 缓存中。
这个问题在 NUMA 系统上被极大地放大,例如在多处理器(后)Nehalem 或 AMD64 板上。不仅保持高速缓存的一致性要昂贵得多,而且共享变量将驻留在内存中,连接到套接字,第一个“接触”变量的线程驻留在那里。然后,在来自其他套接字的内核上运行的线程必须通过连接套接字的 QPI 或 HT 总线执行远程内存访问。正如一位客座教授最近所说(粗略的解释):“对共享内存系统进行编程,就好像它们是分布式内存系统一样。”这涉及制作要处理的全局数据的本地副本——正是 __thread
属性所实现的。
另请注意,在 TLS 中有和没有 tls_var
时,您应该期待不同的结果。由于它在 TLS 中,一个线程所做的修改对其他线程是不可见的。由于它是一个共享变量,您必须确保在给定时间不能有多个线程访问它。这通常通过临界区或锁定添加来实现。
关于multithreading - TLS 变量查找速度,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/13690307/