multithreading - TLS 可变查找速度

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 是第一种情况下相对于 %rip 的负载吗？为什么不能它是由加载程序重定位的直接内存地址吗？是这个 %rip 相对负载导致缓慢？如果是，为什么？

编译标志:gcc -O3 -std=c99 -Wall -Werror -lpthread

Answer 1

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

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

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

这个问题在 NUMA 系统上被极大地放大了，例如在多处理器(后)Nehalem 或 AMD64 板上。不仅保持高速缓存一致性的成本要高得多，而且共享变量将驻留在内存中，附加到套接字，第一个“接触”变量的线程就驻留在该套接字上。然后，在其他套接字的内核上运行的线程将不得不通过连接套接字的 QPI 或 HT 总线执行远程内存访问。正如一位客座教授最近所说(粗略的释义):“将共享内存系统编程为分布式内存系统。”这涉及制作要处理的全局数据的本地副本 - 这正是 __thread 属性所实现的。

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