在这篇帖子之后:multicore and data.table in R，我想知道在使用数据时是否有一种方法可以使用所有内核.表，通常按组进行计算，可以并行化.plyr似乎在设计上允许这样的操作.
在这篇帖子之后:multicore and data.table in R，我想知道在使用数据时是否有一种方法可以使用所有内核.表，通常按组进行计算，可以并行化.plyr似乎在设计上允许这样的操作.
首先要判断的是，data.table个常见问题3.1第2点已经深入:
只为最大的组分配一个内存，然后
这是一个原因.表格分组很快.但这种方法不适合并行化.并行化意味着将数据复制到其他线程，而不是耗费时间.但是，我的理解是，不管怎样，data.table分组通常比.parallel分组的plyr分组快.这取决于每组任务的计算时间，以及计算时间是否可以轻松减少.移动数据通常占主导地位(在对1或3次大型数据任务运行进行基准测试时).
More often, so far, it's actually some gotcha that's biting in the j expression of [.data.table. For example, recently we saw poor performance from data.table grouping but the culprit turned out to be min(POSIXct) (Aggregating in R over 80K unique ID's). Avoiding that gotcha yielded over 50 times speedup.
So the mantra is: 100, 100, 100.
此外，同一常见问题的第1点可能很重要:
只有该列被分组，其他19列被忽略，因为
所以，data.table真的完全没有遵循拆分-应用-合并的模式.它的工作原理不同.split-apply-combine有助于并行化，但它实际上无法扩展到 Big Data .
另见数据中的脚注3.表简介小插曲:
我们想知道有多少人正在部署并行技术来编写代码
这是想说"当然，并行速度明显更快，但一个高效的算法到底需要多长时间？".
但是，如果您已经分析过(使用Rprof)，并且每个组的任务都是计算密集型的，那么datatable help上的3篇帖子(包括"多核"一词)可能会有所帮助:
multicore posts on datatable-help
当然，在很多任务中，数据并行化会很好.桌子，有一种方法可以做到.但这项工作还没有完成，因为通常其他因素会起作用，所以它的优先级很低.如果你可以用虚拟基准测试来提高测试结果的优先级，那么这将有助于提高测试结果的可重复性.