如何估计线程上下文切换开销？ [英] How to estimate the thread context switching overhead?

问题描述

我试图改善实时期限的线程应用程序的性能。它是运行在Windows Mobile和写在C / C ++。我有一个怀疑的线程切换高频可能会引起实际的开销，但既不能证明或否定它。众所周知，缺少证据不是相反的证明。）

I am trying to improve the performance of the threaded application with real-time deadlines. It is running on Windows Mobile and written in C / C++. I have a suspicion that high frequency of thread switching might be causing tangible overhead, but can neither prove it or disprove it. As everybody knows, lack of proof is not a proof of opposite :).

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

Thus my question is twofold:

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

• If exists at all, where can I find any actual measurements of the cost of switching thread context?

无需花费时间写一个测试应用程序，什么是估计线程现有的应用程序切换开销的方法是什么？

Without spending time writing a test application, what are the ways to estimate the thread switching overhead in the existing application?

有谁知道一种方法找出上下文切换次数（开/关）为给定的主题？

Does anyone know a way to find out the number of context switches (on / off) for a given thread?

推荐答案

虽然你说你不想写一个测试应用程序，我这样做是为了一个ARM9 Linux平台上的previous测试，以找出什么开销。这是）只有两个线程将提高::螺纹::收益率（（或，你知道）和增加一些变量，一分钟左右（不包括其他正在运行的进程，至少没有做什么）后，应用程序打印多少上下文切换它可以每秒做。当然，这是不是真的准确的，但问题是，这两个线程产生的CPU给对方，这是如此之快，它只是没有意义再思考的开销。
所以，简单地继续前进，只写一个简单的测试，而不是想太多关于可能是不存在的问题。

While you said you don't want to write a test application, I did this for a previous test on an ARM9 Linux platform to find out what the overhead is. It was just two threads that would boost::thread::yield() (or, you know) and increment some variable, and after a minute or so (without other running processes, at least none that do something), the app printed how many context switches it could do per second. Of course this is not really exact, but the point is that both threads yielded the CPU to each other, and it was so fast that it just didn't make sense any more to think about the overhead. So, simply go ahead and just write a simple test instead of thinking too much about a problem that may be non-existent.

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

Other than that, you might try like 1800 suggested with performance counters.

哦，我记得在Windows CE 4.X，在这里我们也有四个线程密集交换，有时，从不跑进性能问题，运行的应用程序。我们也试图执行无绪的核心线程件事一切，没有看到性能改进（图形用户界面只是响应要慢得多，但一切是一样的）。也许你可以尝试同样的，通过降低上下文切换的数量或完全删除线程（只是用于测试）。

Oh, and I remember an application running on Windows CE 4.X, where we also have four threads with intensive switching at times, and never ran into performance issues. We also tried to implement the core threading thing without threads at all, and saw no performance improvement (the GUI just responded much slower, but everything else was the same). Maybe you can try the same, by either reducing the number of context switches or by removing threads completely (just for testing).

这篇关于如何估计线程上下文切换开销？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！