如何估计线程上下文切换开销？

Question

我正在尝试通过实时截止日期提高线程应用程序的性能。它在 Windows Mobile 上运行并用 C/C++ 编写。我怀疑高频率的线程切换可能会导致有形的开销，但无法证明或反驳它。众所周知，缺乏证据并不是相反的证据:)。

因此，我的问题是双重的：

• 如果存在，我在哪里可以找到切换线程上下文成本的任何实际测量值？

• 在不花时间编写测试应用程序的情况下，有哪些方法可以估算现有应用程序中的线程切换开销？

• 有谁知道找出给定线程的上下文切换（开/关）数量的方法？

原文由 Ignas Limanauskas 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

虽然您说您不想编写测试应用程序，但我这样做是为了之前在 ARM9 Linux 平台上进行的测试，以了解开销是多少。只有两个线程会 boost::thread::yield() （或者，你知道）并增加一些变量，大约一分钟后（没有其他正在运行的进程，至少没有做某事），应用程序打印它每秒可以进行多少次上下文切换。当然，这并不完全准确，但关键是两个线程都相互让出 CPU，而且速度如此之快，以至于不再考虑开销。因此，只需继续编写一个简单的测试，而不是过多地考虑可能不存在的问题。

除此之外，您可以尝试使用性能计数器建议的 1800。

哦，我记得有一个在 Windows CE 4.X 上运行的应用程序，其中我们也有四个线程，有时需要频繁切换，并且从未遇到性能问题。我们还尝试在完全没有线程的情况下实现核心线程，并没有看到性能提升（GUI 只是响应慢了很多，但其他一切都一样）。也许您可以通过减少上下文切换的数量或完全删除线程（仅用于测试）来尝试相同的方法。

原文由 OregonGhost 发布，翻译遵循 CC BY-SA 2.5 许可协议

Answer 2

上下文切换非常昂贵。不是因为 CPU 操作本身，而是因为缓存失效。如果你有一个密集的任务正在运行，它将填充 CPU 缓存，包括指令和数据，内存预取、TLB 和 RAM 将优化内存的某些区域的工作。

当您更改上下文时，所有这些缓存机制都将被重置，并且新线程从“空白”状态开始。

除非您的线程只是增加一个计数器，否则接受的答案是错误的。当然，在这种情况下不涉及缓存刷新。在没有像真实应用程序那样填充缓存的情况下对上下文切换进行基准测试是没有意义的。

原文由 bokan 发布，翻译遵循 CC BY-SA 4.0 许可协议