我在办公室使用 Pentium 4 HT 机器运行 R，一些代码需要 plyr 包，我通常需要等待 6-7 分钟才能完成脚本运行，而我看到我的处理器只有使用了一半。
我听说在 R 中使用 Multicore 包可以更好地利用多核处理器，我的情况适合这个吗？
谢谢！
【问题讨论】：
有很多包可以做多核处理。请参阅doMPI、doSNOW、doMC 和 doSMP。它们都是运行并行化的其他程序的前端（如 MPI/OpenMPI、多核包......）。在 Windows 上，我对doSMP 有很好的体验，而在 Linux 上 doMC 看起来很有希望（对 windows 的一些支持正在兴起，但有些人对“fork”的模拟有疑问）。
话虽如此，我同意 Vince 的 cmets 关于需要编写 plyr 函数以使用并行计算的强大功能。您可以编写自己的函数来模拟使用%dopar% 的plyr（或编辑plyr）（参见foreach 包）。
两个“CPU 使用历史”窗口可能意味着两个内核或多线程。例如，我有一个具有 4 个内核的 i7-920 处理器，但我看到 8 个历史窗口，因为每个内核都是多线程的。
请原谅我的词汇和/或逻辑，但当涉及到这类事情时，我会成为文斯帖子中的那条鱼。
【讨论】：
这听起来像是一个愚蠢的问题，但您的处理器是否有多个内核？我的理解是 P4 没有，但我对硬件的了解就像鱼对天体物理学的了解一样多。
当您说“进程只使用了一半”时，您的意思是您正在监控两个核心并且只有一个正在使用，还是一个核心正在使用一半？如果是后者，您的应用程序可能是内存受限的（并且可能会占用交换空间），而不是 CPU，因此并行化将无济于事。
此外，plyr 包看起来并不使用multicore 包，因此您必须显式重写plyr 的部分内容才能实现并行化。但是，如果 plyr 的某些部分是令人尴尬的并行，我敢打赌它们已经被并行化了。
所以我不认为你的问题是 CPU 限制的，我认为它是内存限制的（并且命中交换）。监控你的内存，也许把它移到内存更高的机器上。
希望这会有所帮助！
编辑：
@Vince 正如我在 romunov 的回答中所写的那样； HT核心将执行2个进程 比 1 快（但比 2 慢 核心），所以它是值得制作 并行。甚至内存绑定 进程也将占用 100% 的核心。 （我的重点）
值得并行吗？这个等式还有更多内容。在探索 Python 的多处理和线程模块时，我无数次重写了整个程序——甚至是“易于并行化”的程序——而且它们的运行速度变慢了。为什么？打开新线程、进程、将数据混洗到不同的进程等都有固定的成本。这不是那么简单；根据我的经验，并行化从来没有是这里谈论的灵丹妙药。我认为这些答案具有误导性。
首先，我们正在讨论并行化需要“6-7 分钟”的任务。除非 OP 知道他/她的数据会大量增长，否则并行化甚至不值得花时间来编程。在实现并行版本所需的时间内，也许他/她可以完成 100 次非并行运行。在我的工作环境中，挂钟时间很重要。这些计算需要考虑到运行时方程（除非您这样做是为了学习/娱乐）
其次，如果它触及交换空间，最大的减速不是 CPU，而是磁盘 I/O。即使有一种简单的方法可以对 plyr 代码进行混洗以使某些部分并行化（我对此表示怀疑），但与添加更多内存相比，在 I/O 密集型进程上这样做会大大加快速度。
作为一个例子，我曾经从 reshape 包中运行了一个命令来演示这个确切的行为。它在一台具有 4GB 内存的多核 OS X 机器上，几秒钟内它就开始爬行（好吧，我的整个计算机都在爬行！），两个内核的 CPU 占 60-70%，并且使用了所有 4GB 的内存。我让它作为实验运行了一个小时，然后杀死了 R 并看到我的内存跳回了 3GB 空闲空间。我将它改组到 512GB RAM 服务器（是的，我们很幸运拥有它），它在 7 分钟内完成。核心使用量没有改变。
【讨论】：