为什么我的 scala future 效率不高？

Question

我正在 32 位四核 Core2 系统上运行此 scala 代码：（

def job(i:Int,s:Int):Long = {
  val r=(i to 500000000 by s).map(_.toLong).foldLeft(0L)(_+_)
  println("Job "+i+" done")
  r
}

import scala.actors.Future
import scala.actors.Futures._

val JOBS=4

val jobs=(0 until JOBS).toList.map(i=>future {job(i,JOBS)})
println("Running...")
val results=jobs.map(f=>f())
println(results.foldLeft(0L)(_+_))

是的，我确实知道有更多更有效的方法来对一系列整数求和；只是给CPU一些事情做）。

根据我设置的 JOBS，代码会在以下时间运行：

JOBS=1 : 31.99user 0.84system 0:28.87elapsed 113%CPU
JOBS=2 : 27.71user 1.12system 0:14.74elapsed 195%CPU
JOBS=3 : 33.19user 0.39system 0:13.02elapsed 257%CPU
JOBS=4 : 49.08user 8.46system 0:22.71elapsed 253%CPU

令我惊讶的是，这并没有真正超出 2 个“正在运行”的 future。我编写了大量多线程 C++ 代码，毫无疑问，如果我使用 Intel 的 TBB 或 boost::threads 编写此类代码，我会很好地扩展到 4 个核心，并看到 >390% CPU 利用率code> （当然它会更加冗长）。

那么：发生了什么事以及如何才能扩展到我期望看到的 4 核？这是否受到 scala 或 JVM 中某些内容的限制？在我看来，我实际上并不知道 scala 的 futures 在“哪里”运行...是每个 future 生成的线程，还是“Futures”提供了一个专门用于运行它们的线程池？

[我在带有 sun-java6 (6-20-0lennnny1) 的 Lenny 系统上使用 Debian/Squeeze 的 scala 2.7.7 软件包。]

更新：

根据 Rex 的回答中的建议，我重新编码为避免创建对象。

def job(i:Long,s:Long):Long = {
  var t=0L
  var v=i
  while (v<=10000000000L) {
    t+=v
    v+=s
  }
  println("Job "+i+" done")
  t
}
// Rest as above...

这太快了，我必须显着增加迭代次数才能运行任意时间！结果是：

JOBS=1: 28.39user 0.06system 0:29.25elapsed 97%CPU
JOBS=2: 28.46user 0.04system 0:14.95elapsed 190%CPU
JOBS=3: 24.66user 0.06system 0:10.26elapsed 240%CPU
JOBS=4: 28.32user 0.12system 0:07.85elapsed 362%CPU

这更像是我希望看到的情况（尽管 3 份工作的情况有点奇怪，其中一项任务总是比其他两项早几秒钟完成）。

更进一步，在四核超线程 i7 上，后一个带有 JOBS=8 的版本比 JOBS=1 实现了 x4.4 的加速，CPU 使用率为 571%。

Answer 1

尝试

(i to 500000000 by s).view.map(_.toLong).foldLeft(0L)(_+_)

view 的应用程序应该（据我理解 id）通过提供简单的包装器来避免重复迭代和对象创建。

另请注意，您可以使用 reduceLeft(_+_) 而不是折叠。

Answer 2

我的猜测是，垃圾收集器所做的工作比添加本身还要多。因此，您受到垃圾收集器可以管理的内容的限制。尝试使用不创建任何对象的东西再次运行测试（例如使用 while 循环而不是范围/地图/折叠）。如果您的实际应用程序对 GC 的影响如此之大，您还可以使用并行 GC 选项。