Акка с Фреге работает медленнее, чем аналог Scala

Question

В качестве упражнения я взял эти примеры Akka для Scala и Java, чтобы перенести их во Фреге. Хотя он работает нормально, он работает медленнее (11 с), чем аналог Scala(540 мс).

module mmhelloworld.akkatutorialfregecore.Pi where
import mmhelloworld.akkatutorialfregecore.Akka

data PiMessage = Calculate | 
                Work {start :: Int, nrOfElements :: Int} |
                Result {value :: Double} | 
                PiApproximation {pi :: Double, duration :: Duration}

data Worker = private Worker where
    calculatePiFor :: Int -> Int -> Double
    calculatePiFor !start !nrOfElements = loop start nrOfElements 0.0 f where
        loop !curr !n !acc f = if n == 0 then acc
                               else loop (curr + 1) (n - 1) (f acc curr) f
        f !acc !i = acc + (4.0 * fromInt (1 - (i `mod` 2) * 2) / fromInt (2 * i + 1))

    onReceive :: Mutable s UntypedActor -> PiMessage -> ST s ()
    onReceive actor Work{start=start, nrOfElements=nrOfElements} = do
        sender <- actor.sender
        self <- actor.getSelf
        sender.tellSender (Result $ calculatePiFor start nrOfElements) self 

data Master = private Master {
    nrOfWorkers :: Int,
    nrOfMessages :: Int,
    nrOfElements :: Int,
    listener :: MutableIO ActorRef,
    pi :: Double,
    nrOfResults :: Int,
    workerRouter :: MutableIO ActorRef,
    start :: Long } where

    initMaster :: Int -> Int -> Int -> MutableIO ActorRef -> MutableIO UntypedActor -> IO Master
    initMaster nrOfWorkers nrOfMessages nrOfElements listener actor = do
        props <- Props.forUntypedActor Worker.onReceive
        router <- RoundRobinRouter.new nrOfWorkers
        context <- actor.getContext
        workerRouter <- props.withRouter router >>= (\p -> context.actorOf p "workerRouter")
        now <- currentTimeMillis ()
        return $ Master nrOfWorkers nrOfMessages nrOfElements listener 0.0 0 workerRouter now

    onReceive :: MutableIO UntypedActor -> Master -> PiMessage -> IO Master
    onReceive actor master Calculate = do
        self <- actor.getSelf
        let tellWorker start = master.workerRouter.tellSender (work start) self
            work start = Work (start * master.nrOfElements) master.nrOfElements
        forM_ [0 .. master.nrOfMessages - 1] tellWorker
        return master
    onReceive actor master (Result newPi) = do
        let (!newNrOfResults, !pi) = (master.nrOfResults + 1, master.pi + newPi)
        when (newNrOfResults == master.nrOfMessages) $ do
            self <- actor.getSelf
            now <- currentTimeMillis ()
            duration <- Duration.create (now - master.start) TimeUnit.milliseconds
            master.listener.tellSender (PiApproximation pi duration) self
            actor.getContext >>= (\context -> context.stop self)
        return master.{pi=pi, nrOfResults=newNrOfResults}

data Listener = private Listener where
    onReceive :: MutableIO UntypedActor -> PiMessage -> IO ()
    onReceive actor (PiApproximation pi duration) = do
        println $ "Pi approximation: " ++ show pi
        println $ "Calculation time: " ++ duration.toString
        actor.getContext >>= ActorContext.system >>= ActorSystem.shutdown

calculate nrOfWorkers nrOfElements nrOfMessages = do
    system <- ActorSystem.create "PiSystem"
    listener <- Props.forUntypedActor Listener.onReceive >>= flip system.actorOf "listener"
    let constructor = Master.initMaster nrOfWorkers nrOfMessages nrOfElements listener
        newMaster = StatefulUntypedActor.new constructor Master.onReceive
    factory <- UntypedActorFactory.new newMaster
    masterActor <- Props.fromUntypedFactory factory >>= flip system.actorOf "master"
    masterActor.tell Calculate
    getLine >> return () --Not to exit until done

main _ = calculate 4 10000 10000

Я делаю что-то не так с Аккой или это связано с ленью во Фреге за медлительность? Например, когда у меня изначально было fold(строгий сгиб) вместо loop в Worker.calculatePiForПрошло 27 с.

зависимости:

1. Акка родные определения для Фреге: Akka.fr
2. Java-помощник для расширения классов Akka, поскольку мы не можем расширять класс в Frege: Actors.java

Answer 1

Я не совсем знаком с актерами, но предполагаю, что самый крутой цикл действительно loop Вы могли бы избежать прохождения функции f в качестве аргумента.

Например, приложения переданных функций не могут воспользоваться строгостью фактической переданной функции. Скорее генерация кода должна консервативно предполагать, что переданная функция принимает свои аргументы лениво и возвращает ленивый результат.

Во-вторых, в нашем случае вы используете f на самом деле только один раз здесь, так что можно вставить это. (Вот как это делается в коде Scala в статье, на которую вы ссылаетесь.)

Посмотрите на код, сгенерированный для хвостовой рекурсии, в следующем примере кода, который имитирует ваш:

test b c = loop 100 0 f 
   where 
      loop 0 !acc f = acc
      loop n !acc f = loop (n-1) (acc + f (acc-1) (acc+1)) f   -- tail recursion
      f x y = 2*x + 7*y

Мы получаем там:

// arg2$f is the accumulator
arg$2 = arg$2f + (int)frege.runtime.Delayed.<java.lang.Integer>forced(
      f_3237.apply(PreludeBase.INum_Int._minusƒ.apply(arg$2f, 1)).apply(
            PreludeBase.INum_Int._plusƒ.apply(arg$2f, 1)
          ).result()
    );    

Вы видите здесь, что f называется лениво, что приводит к тому, что все выражения аргументов также вычисляются лениво. Обратите внимание на количество вызовов методов, которое требуется! В вашем случае код должен быть примерно таким:

(double)Delayed.<Double>forced(f.apply(acc).apply(curr).result())

Это означает, что два замыкания строятся с упакованными значениями acc и curr, а затем вычисляется результат, то есть функция f вызывается с нераспакованными аргументами, а результат снова помещается в коробку, просто чтобы снова (принудительно) распаковаться для следующего цикла.

Теперь сравните следующее, где мы просто не проходим f но назовите это напрямую:

test b c = loop 100 0 
    where 
      loop 0 !acc = acc
      loop n !acc = loop (n-1) (acc + f (acc-1) (acc+1)) 
      f x y = 2*x + 7*y

Мы получаем:

arg$2 = arg$2f + f(arg$2f - 1, arg$2f + 1);

Намного лучше! Наконец, в приведенном выше случае мы можем вообще обойтись без вызова функции:

      loop n !acc = loop (n-1) (acc + f) where
        f = 2*x + 7*y
        x = acc-1
        y = acc+1

И это получает:

final int y_3236 = arg$2f + 1;
final int x_3235 = arg$2f - 1;
...
arg$2 = arg$2f + ((2 * x_3235) + (7 * y_3236));

Пожалуйста, попробуйте это и дайте нам знать, что происходит. Основное повышение производительности должно произойти из-за не прохождения fв то время как встраивание, вероятно, будет сделано в JIT в любом случае.

Дополнительные расходы с fold вероятно, потому что вам также пришлось создать какой-то список перед его применением.