【发布时间】：2011-04-07 08:13:00
【问题描述】：
我在 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 个期货之外。我编写了很多多线程 C++ 代码，毫无疑问，如果我使用 Intel 的 TBB 或 boost::threads 编写这种东西，我会很好地扩展到 4 个内核，并且看到 >390% 的 CPU 利用率（它会更多当然是冗长的）。
那么：发生了什么事，我如何才能扩展至我希望看到的 4 个内核？这是否受到 scala 或 JVM 中的某些东西的限制？我突然想到，我实际上并不知道 scala 的期货在“哪里”运行……是每个未来产生的线程，还是“期货”提供专用于运行它们的线程池？
[我在带有 sun-java6 (6-20-0lennny1) 的 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%。
【问题讨论】：
-
你只是不耐烦，想要今天的未来！说真的，雷克斯一针见血，你是在衡量垃圾收集，而不是期货效率。
-
嘿……太真实了。当我提交这个问题时，我使用 Scala 的时间并不长，并且可能对围绕它的一些极端炒作有点过于轻信了。
-
想用 akka.dispatch.Future 重新运行测试吗？
-
@Viktor：这是在我访问 2.8 之前提交的。现在 2.8 出现了并行集合，并行计算的未来已经过时（当然，它们在管理异步方面仍然有很好的用途）。上次我查看 scala 并行性能时，我在这张海报的“性能”框中得到了一些（好的）结果：timday.bitbucket.org/project_euler-poster.pdf 正如下面 Rex 所指出的，真正的问题是对象流失是否会杀死垃圾收集器。有什么特别的原因 Akka 会在那里做得更好吗？
-
我听说 Akka 2.0 Futures 在某些情况下可以击败 ParCol。 Akka Futures 也使用 0 锁并且非常小。
标签： multithreading performance scala scalability future