Question

考虑以下计划：

#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的{{1}}加载？为什么不能它是一个直接的内存地址，由加载器重新定位？是这个%rip相对负载导致缓慢？如果是这样，为什么？

编译标记：%rip

Answer 1

没有__thread属性tls_var只是一个共享变量。每当一个线程写入它时，写入首先进入线程执行的核心的高速缓存。但由于它是一个共享变量，并且x86机器是高速缓存一致的，因此其他内核的高速缓存无效，其内容从最后一级高速缓存或主内存刷新（在您的情况下很可能来自最后一级高速缓存，这是Core i7上的共享L3缓存。请注意，尽管比主内存更快，但是最后一级缓存并不是无限快 - 它仍然需要很多周期才能将数据从那里移到L2和L1缓存中，每个内核都是私有的。

使用__thread属性，每个线程都有自己的tls_var副本，位于线程本地存储中。由于这些线程本地存储在内存中彼此相距很远，因此在修改它们时，不会涉及缓存一致性消息，并且数据保留在最快的L1缓存中。

RIP - 相关寻址（System V ABI推荐用于“近”数据的x64默认寻址模式）通常会导致更快的数据访问，但缓存一致性开销非常大，以至于TLS访问速度较慢当一切都保存在L1缓存中时，实际上会更快。

这个问题在NUMA系统上被大大放大，例如：在多处理器（后）Nehalem或AMD64板上。保持高速缓存连贯不仅昂贵得多，而且共享变量将驻留在连接到套接字的内存中，其中首先“触及”变量的线程已经存在。然后，从其他套接字在内核上运行的线程必须通过连接套接字的QPI或HT总线执行远程内存访问。正如一位客座教授最近所说（粗略的解释）：“将共享内存系统编程为好像它们是分布式内存系统。”这涉及制作全局数据的本地副本 - 正是__thread属性实现的目标。

另请注意，无论有没有tls_var在TLS中，您都应该得到不同的结果。由于它在TLS中，一个线程所做的修改对其他线程不可见。由于它是一个共享变量，您必须确保在给定时间不超过一个线程可以访问它。这通常通过关键部分或锁定添加来实现。

TLS变量查找速度

1 个答案: