是否有控制 CPU 负载共享的 BIOS 设置?

Che*_*vas 13 bios cpu

我注意到,对于任何长时间运行的单线程任务,我的家用 PC 将全部使用分配给整个进程的单个逻辑核心。但是,对于完全相同的进程,我的工作 PC 在所有内核之间共享负载(每个内核轮流运行单线程进程)。

两台电脑都运行 Windows 10。我的家用电脑有不同的 CPU 和不同的主板(华硕 ROG 第 11 版)。

这似乎适用于任何进程,但我刚刚测试的示例是我编写的 R 脚本。两台运行完全相同的 R 脚本、相同版本的 R 的 PC 具有不同的 CPU 负载共享方法。更糟糕的是,我的家用 PC 似乎总是将 CPU0 用于此类事情。

我希望有一个 BIOS 设置可以应用到我的家用 PC 上,让它均匀地分担负载。在那儿?

Eug*_*eck 26

将线程调度到内核是一门艺术,而且非常困难。这与现代多核 CPU 管理其热分布的方式有关。根据具体型号,CPU 可能会或多或少地执行以下一项或多项操作:

  • 如果存在热摆动空间,则提高一个或多个内核的时钟频率
  • 关闭未使用的组件(包括内核)以在热配置文件中腾出更多空间
  • 节流一些核心以允许在热封套内部提升其他核心
  • 多得多

这意味着,对于单线程工作负载(如R脚本),最佳策略变化很大:

  • 如果 CPU 可以以牺牲其他核心为代价来提升一个核心,那么最好将该线程“固定”到一个提升的核心
  • 如果热封套很小,则不时将任务分配给不同的核心到最冷的核心是有意义的

无论调度程序选择什么,您都应该相信它比任何人都做得更好。

  • @AndrewSavinykh 我认为重点是修补处理器亲和力有点像手动调用垃圾收集器或内存管理器。*大多数*情况下,系统会自己做得更好。此类系统很少需要干预,此类干预需要深入了解系统正在做什么,以便正确评估干预是否会导致更高效的工作流程。在这种情况下,并没有真正有效的“经验法则”。每种情况确实需要根据自己的优点进行评估,这不是一件容易的事情。 (12认同)
  • @AndrewSavinykh 虽然调度程序是由人类编写的,但它可以做一些人类永远无法做到的事情:每毫秒读取大量状态信息并采取相应的行动。虽然人类当然可以**设计**这样的行为,但人类永远不能真正以这种方式**行动**。 (10认同)
  • 调度(与任何其他系统软件一样)进行权衡(吞吐量、延迟、公平性等)并做出某些选择。用户可能能够做出更好的选择,因为他们可能更了解他们的用例和他们喜欢的权衡。例如,考虑论文“FreeBSD ULE vs. Linux CFS”(https://www.usenix.org/system/files/conference/atc18/atc18-bouron.pdf),它演示了这些调度程序如何进行差异权衡并在差异场景中获得更好或更差的性能。 (3认同)
  • 调度程序是由人类编写的程序。将 R 线程“固定”到内核也可以由人类编程。虽然我理解这种情绪,调度程序是由该地区可能有能力的人编写的,而 OP,因为他们不得不询问在该地区的能力较差,声明“调度程序......做得比任何人都好做”听起来不对我。 (2认同)

Kel*_*ari 13

不能。计算机的 BIOS 可能能够控制启用或禁用哪些 CPU 内核以及内核的速度,但它无法控制在其上执行的内容。程序及其线程的执行由操作系统控制。

现在至于为什么您的两台计算机的行为不同,这是一个完全不同的问题。它可能是您的操作系统设置或 R 配置。这需要在不同的问题中提出,并且需要有关您的硬件和软件配置的更多详细信息。

我还想指出,它仅在一个内核上运行没有任何问题。运行程序就是它的设计目的。也许,您的工作计算机正在运行更多的并发任务并且必须处理 CPU 使用情况。可能是您的家用计算机具有更快的内核,并且无需将线程交换到其他内核。

  • @ChechyLevas 不。同样,执行代码是它们的目的。只要你不疯狂超频,散热足够,就没有什么可担心的。 (11认同)

Cor*_*ias 11

我认为最有可能的罪魁祸首是您的家用计算机正在利用 Windows 10 调度程序中的一项功能,即众所周知的“首选核心”支持,该功能将高性能核心优先于低性能核心。在 2018 年之前,通常可以信任桌面 CPU 以相同的速度运行线程,无论您将其放在哪个核心上。即使一个内核理论上能够在给定电压下以比另一个内核更高的频率运行,CPU 的设计也不允许这样做。

直到 2018 年 AMD Zen+ Ryzen CPU 的出现,这种情况的改变才变得普遍。有了这些模型,AMD 开始允许具有混合质量内核的 CPU 提升到不同的时钟频率,具体取决于哪些内核处于负载状态。当调度程序将线程交换到每个内核时,无论性能配置如何,这在很大程度上变得无效。AMD 的架构将内核分成称为“CCX”的组,从而加剧了性能损失;在 CCX 中将线程从一个内核传输到另一个内核比在不同的 CCX 之间传播线程要快。

Intel 的“Extreme Edition”CPU 也有这种明确的混合性能支持。他们将其称为Intel Turbo Boost Max Technology 3.0。英特尔表示,支持此功能的最早版本的 Windows 10 是“RS5”,似乎是 1809。

借助英特尔® Turbo Boost Max 技术 3.0,通过识别处理器最快的内核并将最关键的工作负载分配给它们,优化了轻线程性能。

直到 2019 年,所有版本的 Windows 都不知道这些事实,并且在 AMD CPU 的所有物理内核上均等地调度线程。Windows 10 版本 1903 包含一个更新的调度程序,它知道 AMD 的 CCX 单元并尝试将线程保持在同一单元内。关联

这些改进旨在对仅使用几个内核的任务产生特殊影响。线程现在将更少地在单个 CCX 之间来回切换。

Windows 10 版本 1909 对调度程序进行了进一步改进,现在使其能够在一项称为“首选 CPU 核心优化”的功能中了解混合性能核心情况。关联

在最近的 Windows Insider 博客文章中,微软表示 Windows 10 19H2 将包括关于如何将指令分发到这些受欢迎的内核的优化。

我承认,我对这个时间线的理解不是 100% 确定的,并且可能在早期版本中使用了偏爱的核心,但要找到关于此的具体信息却出奇地困难。大多数新闻帖子似乎都同意“首选核心”支持对 1909 年来说是全新的,尽管该语言暗示它存在于早期版本中。

2011 年以来,ARM 体系结构实际上明确支持这种称为“big.LITTLE”的混合性能配置。在 ARM 上运行的 Windows 10 版本于2017年发布,并且从一开始或至少到2018 年就包含了对 big.LITTLE 的支持。这似乎与添加对我们现代 Intel 和 AMD 情况的支持非常吻合。

顺便说一句,逻辑核心仅在需要时才会被排除,因为它们被停放,而不是因为调度程序本身了解它们。关联

Core Parking 仅在 Windows Server 2008 R2 上受支持。但是,Core Parking 算法和基础架构还用于平衡 Windows 7 客户端系统上的逻辑处理器与包含英特尔超线程技术的处理器之间的处理器性能。