我刚刚测试了带有和不带有并行后端的弹性网络。调用代码如下：
enetGrid <- data.frame(.lambda=0,.fraction=c(.005))ctrl <- trainControl( method="repeatedcv", repeats=5 )enetTune <- train( x, y, method="enet", tuneGrid=enetGrid, trControl=ctrl, preProc=NULL )我先在没有注册并行后端的情况下运行（在train调用完成后收到了来自%dopar%的警告信息），然后又在注册了7个核心（共8个核心）的情况下再次运行。第一次运行用了529秒，第二次用了313秒。但第一次运行的最大内存使用量为3.3GB（由Sun集群系统报告），而第二次则达到了22.9GB。我有30GB的内存，而接下来的任务会变得更加复杂。
问题：1）这是并行计算的一般特性吗？我以为它们是共享内存的…2）在仍然使用train中的enet的情况下，有没有办法解决这个问题？如果doParallel是问题所在，是否有其他我可以与%dopar%一起使用的架构——没有，对吗？
因为我想知道这是不是预期的结果，这与另一个问题密切相关但不完全相同，但我愿意关闭这个问题并将我的问题合并到那个问题中（或者标记那个问题为重复并指向这个问题，因为这个问题有更多细节），如果这是共识的话：
回答：
在多线程程序中，线程共享大量内存。主要是不共享线程之间的堆栈。但是，正如Dirk Eddelbuettel所说，“R是，并且将始终是单线程的”，因此R的并行包使用进程而不是线程，因此共享内存的机会要少得多。
然而，由mclapply分叉的进程之间是共享内存的（只要这些进程不修改它，这会触发操作系统中内存区域的复制）。这就是使用“multicore”API与使用“snow”API和parallel/doParallel相比，内存占用可能更小的原因之一。
换句话说，使用：
registerDoParallel(7)可能比使用：
cl <- makeCluster(7)registerDoParallel(cl)要高效得多，因为前者会导致%dopar%在Linux和Mac OS X上使用mclapply，而后者使用clusterApplyLB。
然而，“snow”API允许你使用多台机器，这意味着你的内存大小会随着CPU数量的增加而增加。这是一个很大的优势，因为它可以让程序扩展。有些程序在集群上并行运行时甚至可以获得超线性加速，因为它们可以访问更多的内存。
所以回答你的第二个问题，我建议如果你只有一台机器并且使用Linux或Mac OS X，请使用doParallel的“multicore”API，但如果你使用的是集群，请使用多台机器的“snow”API。我认为没有办法将共享内存包如Rdsm与caret包一起使用。
