重线程消耗对ARM (4核A72)和x86 (2核i5)的影响

Question

我有一个实时的linux桌面应用程序(用C编写)，我们正在移植到ARM (4核Cortex v8-A72 CPU)。在体系结构上，它有一个高优先级的显式线程(其中6个)和一对GCD(lib分派)工作队列(一个并发的和另一个串行的)的组合。

我关注的问题有两个方面：

• 我听说ARM不像x86那样超线程，因此我的4核将已经是上下文切换，以跟上我的6个线程(和后台进程)。我应该期望这样做会导致什么样的性能损失？
  • 我听说，我应该期望这些ARM上下文开关的效率低于x86。这是真的吗？
  • 对于非常罕见的事件，有几个线程是高优先级的处理程序，这对前景有多大的影响吗？(也就是说，它们坐在select语句上)

​

• 我更关心的是GCD在这个应用程序中的影响。我对GCD内部工作的理解是，它是一个动态缩放的线程池，它与调度程序交互，并将尝试添加更多的线程以适应负载。在我看来，这将对我的场景中的性能产生几乎完全的负面影响。(也就是说，在核心被完全消耗的系统中)，对吗？

Answer 1

我不是任何与x86架构相关的专家(希望更有经验的人能参与进来)，但以下是对您的问题的一些高层次的回答。

我听说手臂不像x86那样超线程.

正确，超线程是一个专有的英特尔芯片设计功能。据我所知，没有类似的ARM硅技术。

..。因此，我的4核将已经是上下文切换，以跟上我的6个线程(和后台进程)。我应该期待这样的表现吗？.

这并不一定是事实，尽管在许多情况下很可能会发生这种情况。它实际上更多地取决于您的每线程计算的性质-- are...are --您只是做了大量的大量计算，还是做了很多阻塞/等待IO的工作？无论哪种方式，这种退化都会发生在这两种架构上，这更像是一个一般的线程调度问题。在超线程的Intel世界中，每个“物理核”被操作系统看作是两个“逻辑核”，它们共享相同的资源，但是有自己的管道和注册集。维基百科的文章说：

每个逻辑处理器可以单独停止、中断或指示执行指定的线程，独立于共享相同物理核心的其他逻辑处理器。 与使用两个独立物理处理器的传统双处理器配置不同，超线程核心中的逻辑处理器共享执行资源。这些资源包括执行引擎、缓存和系统总线接口；资源共享允许两个逻辑处理器更有效地彼此工作，并允许逻辑处理器从停滞的逻辑核借用资源(假设两个逻辑核与同一个物理核相关联)。一个处理器在等待它发送的数据时会停止，这样它就可以完成对当前线程的处理。使用超线程或多核处理器的好处程度取决于软件的需求，以及如何编写软件和操作系统来有效地管理处理器。

因此，如果您的一些线程经常阻塞I/O，那么您可能会看到在一个4物理核心系统上的6线程应用程序(包括ARM和intel x86)有了更大的改进，因为理论上这是超线程会发光的地方……对IO或另一个线程的结果的线程阻塞可以“休眠”，同时仍然允许运行在同一核心上的另一个线程在没有线程开关的全部开销的情况下工作(专家请插入并告诉我，如果我错了)。

但4核心臂对2核心x86.假设其他一切都相等(显然不是这样，在现实中，时钟速度、缓存层次结构等等都有很大的影响)，那么我认为这真的取决于线程的性质。如果您只是做大量纯粹的CPU绑定计算(也就是说，线程不需要等待CPU以外的任何东西)，那么性能的下降可能会发生。但是，如果在每个线程中执行大量阻塞I/O操作，则可能会显示每个逻辑核心最多可能执行3或4个线程的显著加速。

另一件要记住的事情是缓存。当执行大量的cpu绑定计算时，线程开关有可能炸掉缓存，导致最初的内存访问速度要慢得多。这将发生在这两种架构之间。然而，I/O内存的情况并非如此。但是，如果您没有做很多阻塞的事情，那么线程的额外开销只会使其由于上述原因而变慢。

我听说，我应该期望这些ARM上下文开关的效率低于x86。这是真的吗？

硬件上下文开关是硬件上下文开关，您将所有寄存器推入堆栈并翻转一些位以更改执行状态。因此，不，我不认为在这方面两者都“更快”。然而，对于单个物理内核，使操作系统中的“上下文切换”(我认为您的意思是在线程之间切换)更快，因为两个程序的指令已经在同一核上并行执行。

我对GCD一无所知，所以不能对此发表评论。

最后，我想说的是，您最好的方法是在这两个架构上对应用程序进行基准测试。看看你的瓶颈在哪里。它在内存访问中吗？因此，保持缓存热是一个优先事项。我想，如果您能够将每个内核的线程设置为1线程，那么在任何情况下都是最优的。

在这件事上读到一些好东西：

1. https://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html
2. https://lwn.net/Articles/250967/
3. Optimal number of threads per core
4. Thread context switch Vs. process context switch