Пикка - Актеры медленные? - PullRequest
7 голосов
/ 01 декабря 2011

Я сейчас экспериментирую с Actor-concurreny (на Python), потому что я хочу узнать больше об этом. Поэтому я выбрал pykka, но когда я тестирую его, он более чем вдвое медленнее , чем обычная функция.

Код только для того, чтобы посмотреть, работает ли он; это не должно быть элегантно. :)

Может я что-то не так сделал?

from pykka.actor import ThreadingActor
import numpy as np

class Adder(ThreadingActor):
    def add_one(self, i):
        l = []
        for j in i:
            l.append(j+1)
        return l

if __name__ == '__main__':
    data = np.random.random(1000000)
    adder = Adder.start().proxy()
    adder.add_one(data)
    adder.stop()

Это работает не так быстро:

time python actor.py

real    0m8.319s
user    0m8.185s
sys     0m0.140s

А теперь фиктивная «нормальная» функция:

def foo(i):
    l = []
    for j in i:
        l.append(j+1)
    return l

if __name__ == '__main__':
    data = np.random.random(1000000)
    foo(data)

Дает этот результат:

real    0m3.665s
user    0m3.348s
sys     0m0.308s

1 Ответ

14 голосов
/ 01 декабря 2011

Итак, здесь происходит то, что ваша функциональная версия создает два очень больших списка, что составляет большую часть времени. Когда вы представляете актеров, изменяемые данные, такие как списки, должны быть скопированы перед отправкой актеру для обеспечения надлежащего параллелизма . Также список, созданный внутри субъекта, также должен быть скопирован при отправке обратно отправителю. Это означает, что вместо двух очень больших списков мы создали четыре очень больших списка.

Подумайте о том, чтобы спроектировать данные, создаваемые и поддерживаемые субъектом , а затем запрашивать его с помощью обращений к субъекту, минимизируя размер сообщений, передаваемых туда и обратно. Попробуйте применить принцип минимального перемещения данных . Передача списка в функциональном случае эффективна только потому, что данные на самом деле не перемещаются, что позволяет использовать общее пространство памяти. Если бы актер находился на другой машине, мы не получили бы преимущества пространства совместно используемой памяти, даже если данные сообщения были неизменными и их не нужно было копировать.

...