multithreading - 当光线跟踪与GCD并行时，线程捕获了刻录CPU

我已经编写了一个基本的光线跟踪器并使用Grand Central Dispatch来并行计算像素，使用4个独立的渲染块。

这在Yosemite 10.10.1下的2014 MacBook Pro上运行良好。现在，我第一次在新的iMac上启动相同的应用程序来检查速度的提高。（两个系统上的CPU都有4个核心。）突然间，我在控制台日志中看到消息“线程抓住了CPU”：

28.11.14 03：19：45,000内核[0]：进程edXCG_hw3-Cocoa [510] 线程50878抓住了刻录CPU！它使用了超过50％的CPU（实际最近   用法：97％）超过180秒。线程生命周期cpu使用率90.016272   秒，（89.714813用户，0.301459系统）分类帐信息：余额：   90003522038点数：90003522038借记：0限制：90000000000（50％）   期间：自上次补充以来的18亿次（ns）：91932078384

28.11.14 03：19：45,832 spindump [486]：为edXCG_hw3-Cocoa版本1.0（1）保存了cpu_resource.diag报告   /Library/Logs/DiagnosticReports/edXCG_hw3-Cocoa_2014-11-28-031945_Chriss-iMac.cpu_resource.diag

（我当时退出了申请。）

现在我想知道......

Grand Central Dispatch的某些技术是否需要避免这种情况？我只是将4个内核中的每一个分别发送给渲染工作，确保在最后一个渲染块完成后，它们将始终保持忙碌状态。这是我第一次在实际应用程序中使用GCD（和并行化），所以现在我想知道这是否是正确的方法。
这有什么硬件情况？我的印象是它不应该损坏CPU让它们的核心在满负荷运行几分钟左右。我认为内核消息可能更具有警示性，以避免过热，但其措辞足以令人紧张（由于与显卡有关的散热问题，我最近丢失了旧的Macbook）。
我很惊讶这种情况发生在iMac上，而不是MacBook Pro上，两者都运行OS X 10.10.1。 iMac的散热情况是否更加困难，可能是因为它的设计，所以我无法运行这种CPU密集型应用程序？！
或许这个内核消息只是拼写出早期版本的OS X中已经发生的事情，即WindowServer闲置CPU以使处理器不会过热？

重型热循环会缩短机器的使用寿命，而与内部核心是否能够处理热量无关。

所以，我猜你对＃34;最佳表现感兴趣＆＃34;在适合机器设计的热参数范围内。

尝试将问题分解成更小的块并使用较低的Grand Central Dispatch＆＃34;服务质量＆＃34;设置，如QOS_CLASS_UTILITY或QOS_CLASS_BACKGROUND。

较小的调度块和较低的服务质量＆＃34;设置将允许操作系统通过适当地限制所需的队列调度速率来管理相互关联的能量/热量/ CPU负载。

WWDC2015 Session 718 "Building Responsive and Efficient Apps with GCD"简要讨论了相对于第一台无风扇Mac的上述方法。

想象一下，你有一个应用程序......使用大量能源来驱动机器，我们需要帮助控制这些能量，以使机器保持在合理的温度。

嗯，我们可以做的是我们可以开始在不太重要的服务质量等级上挤压我们要做的工作量。

当光线跟踪与GCD并行时，线程捕获了刻录CPU

1 个答案: