超线程Smt究竟可以快多少?(斐波那契版)

商务办公
SMT测试很有意思,但是编译内核涉及的因素太多了,包括访问文件系统等耗时受到存储器性能的影响,难以估算,因此很难评判SMT对性能的提升如何。

[[430416]]

宋老师的SMT测试很有意思,但是编译内核涉及的因素太多了,包括访问文件系统等耗时受到存储器性能的影响,难以估算,因此很难评判SMT对性能的提升如何。

为了探究SMT对计算密集型workload的效果,我自己写了一个简单的测试程序。

使用pthread开多个线程,每个线程分别计算斐波那契数列第N号元素的值。每个线程计算斐波那契数列时除线程的元数据外只分配两个unsigned long变量,由此避免过高的内存开销。

workload的详细代码和测试脚本在[https://github.com/HongweiQin/smt_test]

毫无疑问,这是一个计算密集型负载,我在自己的笔记本上运行,配置如下(省略了一些不重要的项目):

  1. $ lscpu 
  2. Architecture:                    x86_64 
  3. CPU(s):                          12 
  4. On-line CPU(s) list:             0-11 
  5. Thread(s) per core:              2 
  6. Core(s) per socket:              6 
  7. Socket(s):                       1 
  8. NUMA node(s):                    1 
  9. Vendor ID:                       GenuineIntel 
  10. Model name:                      Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 
  11. L1d cache:                       192 KiB 
  12. L1i cache:                       192 KiB 
  13. L2 cache:                        1.5 MiB 
  14. L3 cache:                        12 MiB 

可以看到笔记本有一个Intel i7的处理器,6核12线程。经查,CPU0和CPU6共用一个Core,CPU1和CPU7共用一个Core,以此类推。

以下的测试(Test 1-5)中,每个线程分别计算斐波那契数列第40亿号元素的数值。

Test1:采用默认配置,开12线程进行测试。测试结果为总耗时45.003s。

  1. qhw@qhw-laptop:~/develop/smt_test$ time ./smt_test -f 4000000000 
  2. threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=32 
  3.   
  4. real0m45.003s 
  5. user7m12.953s 
  6. sys0m0.485s 

Test2:把smt关掉,同样的测试方法(12线程)。总耗时为25.733s。

  1. qhw@qhw-laptop:~/develop/smt_test$ cat turnoff_smt.sh 
  2. #!/bin/bash 
  3.  
  4. echo "turn off smt" 
  5. sudo sh -c 'echo off > /sys/devices/system/cpu/smt/control' 
  6. qhw@qhw-laptop:~/develop/smt_test$ ./turnoff_smt.sh 
  7. turn off smt 
  8. qhw@qhw-laptop:~/develop/smt_test$ time ./smt_test -f 4000000000 
  9. threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=32 
  10.   
  11. real0m25.733s 
  12. user2m23.525s 
  13. sys0m0.116s 

对,你没看错。同样的workload,如果关掉smt,总耗时还变少了。Intel诚不欺我!

Test3:再次允许smt,但是将程序限制在三个物理Core上运行,则总耗时为34.896s。

  1. qhw@qhw-laptop:~/develop/smt_test$ ./turnon_smt.sh 
  2. turn on smt 
  3. qhw@qhw-laptop:~/develop/smt_test$ time taskset -c 0-2,6-8 ./smt_test -f 4000000000 
  4. threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=32 
  5.   
  6. real0m34.896s 
  7. user3m17.033s 
  8. sys0m0.028s 

Test3相比于Test1用了更少的Core,反而更快了。

为什么在Test2和3会出现这样违反直觉的结果?

猜想:Cache一致性在作怪!

图1

测试程序的main函数会分配一个含有T(T=nr_threads)个元素的`struct thread_info`类型的数组,并分别将每个元素作为参数传递给每个计算线程使用。`struct thread_info`定义如下:

  1. struct thread_info { 
  2. pthread_t thread_id; 
  3. int thread_num; 
  4. unsigned long res[2]; 
  5. }; 

结构体中的res数组用于计算斐波那契数列,因此会被工作线程频繁地写。

注意到,sizeof(struct thread_info)为32,而我的CPU的cacheline大小为64B!这意味着什么?

图2

如图所示,如果Thread 0在Core 0上运行,则它会频繁写tinfo[0],Thread 1在Core 1上运行,则它会频繁写tinfo[1]。

这意味着,当Thread 0写tinfo[0]时,它其实是写入了Core 0上L1 Cache的Cacheline。同样的,当Thread 1写tinfo[1]时,它其实是写入了Core 1上L1 Cache的Cacheline。此时,由于Core 1上的Cacheline并非最新,因此CPU需要首先将Core 0中的Cacheline写入多核共享的L3 Cache甚至是内存中,然后再将其读入Core 1的L1 Cache中,最后再将Thread 1的数据写入。此时,由于Cache 0中的数据并非最新,Cacheline会被无效化。由此可见,如果程序一直这样运行下去,这一组数据需要在Cache 0和1之间反复跳跃,占用较多时间。

这个猜想同样可以解释为什么使用较少的CPU可以加速程序运行。原因是当使用较少的CPU时,多线程不得不分时共用CPU,如果Thread 0和Thread 1分时共用了同一个CPU,则不需要频繁将Cache无效化,程序运行时间也就缩短了。

验证猜想:增加内存分配粒度!

对程序进行修改后,可以使用`-g alloc_granularity`参数设定tinfo结构体的分配粒度。使用4KB为粒度进行分配,再次进行测试:

Test4:12线程,开启SMT,分配粒度为4096。总耗时为13.193s,性能相比于Test1的45.003s有了质的提升!

  1. qhw@qhw-laptop:~/develop/smt_test$ time ./smt_test -f 4000000000 -g 4096 
  2. threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096 
  3.   
  4. real0m13.193s 
  5. user2m31.091s 
  6. sys0m0.217s 

Test5:在Test4的基础上限制只能使用3个物理Core。总耗时为24.841s,基本上是Test4的两倍。这说明在这个测试下,多核性能还是线性可扩展的。

  1. qhw@qhw-laptop:~/develop/smt_test$ time taskset -c 0-2,6-8 ./smt_test -f 4000000000 -g 4096 
  2. threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096 
  3.   
  4. real0m24.841s 
  5. user2m26.253s 
  6. sys0m0.032s 

超线程SMT究竟可以快多少?

表格和结论:

 

测试名  硬件配置  运行时间(s)
Test6  “真”6核   38.562 
Test7 “假”6核  58.843
Test8 “真”3核   73.175 

测试使用的是6个工作线程。为了减少误差,增加一点运行时间,每个线程计算斐波那契数列第200亿项的值。

对比Test6和7,可以看到SMT的提升大概在52.6%左右。

测试记录:

Test6:别名“真”6核,使用6个关闭了SMT的物理核进行计算。总耗时为38.562s。

Test7:别名“假”6核,使用3个开启了SMT的物理核进行计算。总耗时为58.843s。

Test8:别名“真”3核,使用3个关闭了SMT的物理核进行计算。总耗时为1m13.175s。

  1. qhw@qhw-laptop:~/develop/smt_test$ cat test.sh 
  2. #!/bin/bash 
  3.  
  4. fibonacci=20000000000 
  5. sudo printf "" 
  6.   
  7. ./turnoff_smt.sh 
  8. time ./smt_test -f $fibonacci -g 4096 -t 6 
  9.   
  10. ./turnon_smt.sh 
  11. time taskset -c 0-2,6-8 ./smt_test -f $fibonacci -g 4096 -t 6 
  12.   
  13. ./turnoff_smt.sh 
  14. time taskset -c 0-2,6-8 ./smt_test -f $fibonacci -g 4096 -t 6 
  15.   
  16. ./turnon_smt.sh 
  17. qhw@qhw-laptop:~/develop/smt_test$ ./test.sh 
  18. turn off smt 
  19. threads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096 
  20.   
  21. real0m38.562s 
  22. user3m50.786s 
  23. sys0m0.000s 
  24. turn on smt 
  25. threads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096 
  26.   
  27. real0m58.843s 
  28. user5m53.018s 
  29. sys0m0.005s 
  30. turn off smt 
  31. threads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096 
  32.   
  33. real1m13.175s 
  34. user3m39.486s 
  35. sys0m0.008s 
  36. turn on smt 

 

责任编辑:武晓燕 来源: Linux阅码场
相关推荐

2021-10-18 11:55:10

SMTCPU线程

2021-10-31 21:01:00

数列TypeScriptJava

2012-02-22 10:14:44

Java

2021-12-28 07:20:44

斐波那契数算法数字

2021-05-16 18:02:52

系统编程JavaScript

2021-05-08 08:28:38

Java数据结构算法

2021-03-15 06:04:47

斐波那契数列背包问题算法

2020-05-11 14:18:14

JavaScript斐波那契数列递归

2022-11-14 08:12:34

2023-06-13 06:51:15

斐波那契数算法

2017-07-10 16:23:29

线程CPU单核

2024-03-25 08:00:00

C++递归函数

2021-03-17 08:37:23

算法性能分析递归算法递归树

2022-03-28 15:15:15

神经网络编程开发

2013-04-10 10:58:19

LambdaC#

2017-03-06 14:45:27

超线程技术处理器技术服务器

2020-04-20 11:09:18

Python开发语言

2009-04-27 12:26:45

AMD单核Nehalem

2020-11-23 08:53:34

堆Heap

2009-06-17 17:43:16

英特尔nehalem超线程
点赞
收藏

51CTO技术栈公众号