Пушыстый ([info]_winnie) wrote,
@ 2007-06-06 16:38:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Сделал мини-тест как бы игрового кода на Python - http://www.everfall.com/paste/id.php?0yg3jc12kvd8

Результаты - 200 FPS если писать "pos += vel * dt" и 1000 FPS если писать "madd(pos, vel, dt)". (Аналогичный код на плюсах - FPS = 77'000 в Debug -O0/Od, FPS = 272'000 в Release -O3/Ox)

Неприятно :(, значит на каждый кадр вызывать на каждый объект - напрашиваться на геморрой. Реальные нагрузки гораздо больше на каждый объект, даже когда они не двигаются, а просто рисуются, и я не могу отдать 100% времени на скрипты.

Правда, я не пробовал оптимизаторы вроде psyco (сомеваюсь правда, вряд ли он что-то сделает против создавания объектов на GC на каждый += *).

Кто-нибудь не сделает тест такого же кода на lua/squirrel/psyco? psyco мешает embeddig или нет?

Ещё замечу, что 200 объектов одновременно у меня двигаться не будут, так что думаю взлетит.

Так же возможны хитрые оптимизации "скрипт расставляет только key-poits, спит всю дорогу, а С++ интерполирует". Оно нетривиальное, наверное не буду делать для текущего проекта...

(Post a new comment)


[info]qiller_neu
2007-06-06 02:12 pm UTC (link)
http://www.everfall.com/paste/id.php?uo56rmmxg0do

madd - time: 0.05 , FPS: 8000
oop - time: 0.41 , FPS: 975.60975609756

Нагрузку на GC никто не отменял.

Однако, зачем это делать в скрипте?

(Reply to this) (Thread)

[info]_winnie
2007-06-06 02:14 pm UTC (link)
Задавать положение спрайтиков из скрипта иногда хочется...

(Reply to this) (Parent)

[info]_winnie
2007-06-06 02:19 pm UTC (link)
Не хочется игровые объекты держать в С++, хочется выдать раз и навсегда скрипту Клавиатуру, Мышь, DrawSprite, CreateSprite, PlaySound. Но как видим, мои хотения - сталкиваются с реальной жизнью.

(Reply to this) (Parent)
Скорость компьютера
[info]_winnie
2007-06-06 02:37 pm UTC (link)
http://dobrokot.nm.ru/tempora/test_speed.zip - скомпилированый exe из C++-кода, что бы можно было сравнить наши процессоры и нормализовать FPS.
У меня он выдаёт "time: 1.687000 FPS: 237107.279787"

(Reply to this) (Parent)(Thread)
Re: Скорость компьютера
[info]qiller_neu
2007-06-06 02:47 pm UTC (link)
time: 1.121000 FPS: 356824.247102

(Reply to this) (Parent)

[info]subdmitry
2007-06-06 06:06 pm UTC (link)
Чего-то Piton уж очень тормозит - разница с С++ 1000 с лишним раз. Для прилично написанного интерпретатора должно быть не больше 100.

Нагрузка на GC, как показывает практика, при использовании передовых технологий вроде копирующей инкрементальной сборки мусора оказывается не так уж и важна. Известен случай, когда счетная ML'ная программа, массово порождающая объекты в куче, выиграла по скорости у С++, который все операции делал на стеке.

(Reply to this) (Thread)

[info]brainslugs.blogspot.com
2007-06-06 06:32 pm UTC (link)
Ну насчет стека vs GC хип -- имхо можно придумать дофига случаев когда GC будет эффективнее.. )

А в питоне кстати какой-то хитрый GC, который вроде как на подсчете ссылок основан но при этом весь такой инкрементальный и generational, и циклы обнаруживать умеет.

(Reply to this) (Parent)

[info]_winnie
2007-06-07 07:50 am UTC (link)
Оно жестоко динамически типизировано, и интерпретатор написан не совсем прилично - http://alexeychen.livejournal.com/8153.html

(Reply to this) (Parent)(Thread)

[info]subdmitry
2007-06-07 04:53 pm UTC (link)
На самом деле от динамической типизации средство имеется. Основывается оно на том, что в коде в подавляющем количестве мест динамики типов реально не происходит. То есть можно для данного вызова в данном месте кода закэшировать результаты поиска по разным таблицам адреса вызываемого метода, и это дает отличные результаты. Кто-то, помню, даже хвастался, что такая конструкция вызова для ST работает быстрее, чем virtual call в С++ (но это, правда, уже, наверное, для комилятора (бывают и компиляторы ST)).

Насчет скорости разных языков есть неплохой ресурс.

(Reply to this) (Parent)

[info]qiller_neu
2007-06-06 06:44 pm UTC (link)
Посчитать бы еще скорость интерфейса C++ <-> Lua/Python...

(Reply to this)


[info]brainslugs.blogspot.com
2007-06-06 07:58 pm UTC (link)
Кстати, дело, я думаю, не в GC. В IronPython GC другой, а работает все точно с такой же скоростью. Плюс счетчики показывают time in GC ~3%. Скорее это оверхед на вызовы функций и всякие проверки типов.

Вот например если убрать в конструкторе приведение к float, в питоне 2.4 скорость в два раза возрастает, а в IronPython в три (для варианта без madd).

(Reply to this) (Thread)

[info]_winnie
2007-06-07 07:41 am UTC (link)
>Плюс счетчики показывают time in GC
Это время на сборку? Просто есть ещё время на суету по выделению, оно короткое, но зато очень часто.

(Reply to this) (Parent)(Thread)

[info]brainslugs.blogspot.com
2007-06-07 04:59 pm UTC (link)
Да, скорее всего именно на сборку.
Вообще странно.. Вот в Blade Of Darkness, если не ошибаюсь, чуть ли не полет капелек крови на питоне считали -- и ничего )

(Reply to this) (Parent)(Thread)

[info]_winnie
2007-06-07 05:02 pm UTC (link)
Ну, я думаю, их джедаи (как тёмные, так и светлые) от питона постарались, что бы не (очень сильно) тормозило :)

(Reply to this) (Parent)

[info]_pk_sly
2007-06-07 04:46 am UTC (link)
а зачем скрипт? в рантайме будет меняться его поведение?
можно попробовать динамическую компиляцию с любым компилируемым языком.

кстати.. на моё удивление, tcl в некоторых тестах обходит очень многие скриптовые языки (включая javascript и perl)

(Reply to this) (Thread)

[info]_winnie
2007-06-07 08:06 am UTC (link)
Меня немножко задолбало, что на С++ - половина времени уходит на борьбу с языком, а не с задачей.

(Reply to this) (Parent)(Thread)

[info]_pk_sly
2007-06-07 08:56 am UTC (link)
да, есть такой минус :)

я к чему - если платформа - win32 и только (ничего не хотел сказать плохого про другие платформы!;)) ), то довольно неплохим компромиссом между скоростью исполнения и удобством использования являются .net-языки (C#, javascript.net и т.д.)

у нас была аналогичная задача, использовали javascript (который в самом конце по ВСЕМ тестам) - упёрлись в производительность и немасштабируемость. в итоге почти всё было переписано обратно на С++.

насчёт тестов.
http://dada.perl.it/shootout/
http://shootout.alioth.debian.org/

вообще, тема скриптизации С++ного кода интересна.

(Reply to this) (Parent)

[info]_winnie
2007-06-07 08:07 am UTC (link)
Ну и дизайнеру удобней подправить какую-то лапшу из if в скрипте, а не в плюсах.

(Reply to this) (Parent)

[info]vshabanov
2007-06-07 09:42 pm UTC (link)
Вот, повозился тут ;)

Для начала оригинал:
  $ ./test_speed.exe
  time: 1.062000 FPS: 376647.816385
Также скомпилил сорец g++, изменив float на double для более корректного сравнения:
  $ gcc -dumpversion
  4.2.0
  $ g++ wt.cpp -o wt.cpp.exe         N=400000
  $ ./wt.cpp.exe
  time: 9.234000 FPS: 43318.171973
С опцией "-O2" g++ тут что-то очень сильно оптимизит, даже добавление случайных чисел в начальные значения не помогло:
  $ g++ -O2 wt.cpp -o wt.cpp.exe   N=40000000
  $ ./wt.cpp.exe
  time: 18.906000 FPS: 2115730.455940
В 5.6 раз быстрее, чем VC++. Как так, не знаю.


Теперь питон:
  $ python --version
  Python 2.5
  $ python winnie_test.py             N=40000
  time: 16.9059998989 , FPS: 2366.02391099
Чтобы не тормозило на dictionary заменил point и object на простые двухэлементные массивы. Чтобы не было лишних кастингов заменил 0,1,3 на 0.0, 1.0, 3.0. Итог не впечатлил:
  $ python winnie_test.py             N=40000
  time: 13.0460000038 , FPS: 3066.07389148
Видимо у питона действительно очень тухлый интерпретатор.


Теперь окемл:

Тупо один к одному (со всеми объектами) переведенный код оказался не сильно быстрее:
  $ ocamlc -version
  3.10.0
  $ ocamlc winnie_test.ml -o wt.bytecode.exe
  $ ./wt.bytecode.exe                 N=40000
  time: 5.860000; FPS:  6825.938689
скомпиленный в нейтив в несколько раз быстрее (почти такой же, как отладочный g++).
  $ ocamlopt winnie_test.ml -o wt.native.exe
  $ ./wt.native.exe                  N=400000
  time: 9.719000; FPS: 41156.497154
У окемла, не смотря на статическую типизацию, диспатчинг методов динамический (из-за того, что в кемле у объектов структурный полиморфизм, т.е. для вызова одинаковых методов объекты необязательно наследовать от общего класса, достаточно чтобы сигнатуры методов были одинаковые). По-этому заменил объекты на простые записи (struct по сишному):
  $ ocamlc winnie_test.ml -o wt.bytecode.exe
  $ ./wt.bytecode.exe                N=400000
  time: 44.515000; FPS: 8985.735124
Прирост в байткоде всего 30%. Видимо интерпретатор кемла тоже не особо хорош для числодробильни. Хотя он и в 3 раза быстрее питона в обоих случаях. Однако, при компиляции в нативный код:
  $ ocamlopt winnie_test.ml -o wt.native.exe
  $ ./wt.native.exe                N=40000000
  time: 82.140000; FPS: 486973.459325
получили производительность выше, чем у VC++ на 30% (однако меньше, чем у g++ в 4.3 раза).

Код на кемле (оба варианта):
http://www.everfall.com/paste/id.php?wilvry1e15zs


Сравнения:
  • g++ в 5.6 раз быстрее VC++
  • python в 160 раз медленнее VC++ и в 122 раза с массивами вместо объектов
  • байткодный ocaml в 55 раз медленнее VC++
  • байткодный ocaml с сишными структурами в 42 раза медленнее VC++
  • нативный ocaml в 9 раз медленнее VC++
  • нативный ocaml с сишными структурами в 1.3 раза быстрее VC++

Выводы:
  • у окемла не такой уж и быстрый байткод, если заниматься числодробильней
  • для данной задачи окемловский байткод быстрее питона всего в 3 раза
  • использование объектов в кемле для числодробильни и любых часто вызываемых участков кода неоправдано
  • при правильных структурах данных, код на нативном кемле получается на уровне С
  • и главное -- использование интерпретаторов для чистой числодробильни неоправдано

(Reply to this) (Thread)

[info]_winnie
2007-06-07 10:42 pm UTC (link)
Спасибо большое за анализ :)
Правда, оно будет не "числодробильня", а задавание траекторий рисуемых объектов.

(Reply to this) (Parent)

[info]thesz
2007-06-07 10:46 pm UTC (link)
Здорово. Спасибо. ;)

(Reply to this) (Parent)

[info]levgem
2007-07-03 01:51 pm UTC (link)
Лучше тебе на руби тогда не смотреть =)

Скрещивать его с С проще, чем любой другой язык, но пока что он ещё медленнее.

(Reply to this)


[info]_gvozdoder_
2007-08-07 06:21 am UTC (link)
По рассылкам недавно пробегал Falcon. Там генеральный программист хвалится, что его виртуальная машина уделывает все остальные виртуальные машины. Сам не проверял.

(Reply to this)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…