Почему мои фьючерсы на scala не более эффективны? - PullRequest
Новая
       18

Почему мои фьючерсы на scala не более эффективны?

17 голосов
/ 02 сентября 2010

Я запускаю этот scala-код в 32-разрядной четырехъядерной системе Core2: 

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)(_+_))

(Да, я делаю знаю, что есть много более эффективных способов суммировать серии целых чисел; это просто для того, чтобы ЦП что-то сделал).

В зависимости от того, на что я установил 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 ++ и не сомневаюсь, что получу хорошее масштабирование до 4 ядер и вижу> 390% загрузки ЦП, если я закодирую такого рода вещи с помощью Intel TBB или boost::threads (это было бы значительно больше многословно конечно).

Итак: что происходит и как я могу получить масштабирование до 4 ядер, которые я ожидаю увидеть? Это ограничено чем-то в scala или JVM? Мне приходит в голову, что я на самом деле не знаю, «где» запускаются фьючерсы scala ... является ли поток порожденным в будущем или «Futures» предоставляет пул потоков, предназначенный для их запуска?

[Я использую пакеты scala 2.7.7 из Debian / Squeeze в системе Lenny с sun-java6 (6-20-0lennny1).]

Обновление:

Как и предполагалось в ответе Рекса, я перекодировал, чтобы избежать создания объекта. 

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 заданиями немного странный, когда одно задание последовательно выполняется за пару секунд до двух других).

Если продвинуться немного дальше, на четырехъядерном Hyper-Threading i7 последняя версия с JOBS=8 обеспечивает ускорение в 4,4 раза по сравнению с JOBS = 1 с 571% загрузкой ЦП.

Ответы [ 2 ]

15 голосов
/ 02 сентября 2010

Я предполагаю, что сборщик мусора выполняет больше работы, чем само дополнение.Таким образом, вы ограничены тем, чем может управлять сборщик мусора.Попробуйте запустить тест снова с чем-то, что не создает никаких объектов (например, используйте цикл while вместо range / map / fold).Вы также можете поиграть с параметрами параллельного GC, если ваше реальное приложение сильно ударит по GC.

2 голосов
/ 15 января 2011

Попробуйте 

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

Предполагается, что применение view (как я понял id) позволяет избежать повторных итераций и создания объектов путем предоставления простых оболочек.

Обратите внимание, что выможно использовать reduceLeft(_+_) вместо сгиба.

...