最小化跨核心上下文切换的数量

时间:2010-07-28 15:30:41

标签: .net performance profiling cpu-usage cpu-speed

我最近在应用程序分析方面进行了大量实验(使用Visual Studio性能向导)。在使用并发指标时,我注意到当应用程序运行多个线程(后台和前台)时,跨核心上下文切换速率非常高。

了解通常大量的跨核心上下文切换可能会对应用程序性能产生不利影响,我想将其降低到最低程度。

除了最小化同时运行的线程数之外,在.NET应用程序中执行此操作的可能方法是什么?

2 个答案:

答案 0 :(得分:2)

跨核心上下文切换实际上不太可能对应用程序性能有害。

任何上下文切换都会产生约1-4微秒的直接成本来保存/恢复线程状态,以及缓存预热的间接成本。间接成本取决于许多因素,例如数据位置和访问模式,并且变化很大:从几百纳秒,几乎没有增加总上下文切换成本,到几百微秒,总成本增加两个数量级。 / p>

虽然预计跨核心上下文切换需要更长的缓存预热(如果新核心不与旧核心共享缓存)是合理的,但是将线程安排到同一核心仍然需要缓存预热,因为部分或全部线程的数据将被其中在该核心上执行的其他线程从缓存中逐出。

在任何情况下,与线程执行量的约30-120毫秒(上下文切换之间的时间)相比,上下文切换的总成本仍然不明显。

仅在病态情况下,即当线程长时间工作且具有完全适合非共享高速缓存的相同数据集时,跨核心上下文切换可对性能产生明显影响。他们大部分时间都不会成为瓶颈。

作为旁注,与LBushkin的建议相反,BeginThreadAffinity不会帮助您处理器关联:它只将.NET线程固定到特定的OS线程,到特定的OS线程芯

有用的链接:

[1] Using Concurrency for Scalability
[2] Quantifying The Cost of Context Switch
[3] How long does it take to make a context switch?

答案 1 :(得分:1)

您可以将其中一些线程关联到单个核心。但是你必须be extremely careful when doing so - 因为它可能会阻止CLR / OS将线程调度到可用内核,从而降低性能。

为此,您可以使用BeginThreadAffinity方法强制线程保持固定到特定处理器或核心的标识。