Air VS OpenFL. Тест Nape.

ActionScript


Всем привет!
Наконец-то я собрался и сделал демки на AS3 и Haxe, чтобы сравнить производительность Nape на iPad 3.
Версии используемых технологий/библиотек/ОС:
  • Haxe 3.0.1,
  • Nape 2.0.13 (haxelib),
  • OpenFL 1.1.1 (haxelib),
  • openfl-tilelayer 0.1 (https://github.com/matthewswallace/openfl-tilelayer),
  • Flash CC,
  • Air 4 Beta,
  • Nape 2.0.12 SWC (http://napephys.com/nape-release.swc)
  • Starling 1.4.1 SWC
  • Xcode 5.0.2,
  • iOS 6.1,
  • OS X 10.9

Как собирались демки?
Haxe версия собиралась командой openfl build ios, тем самым создавался Xcode проект, с помощью которого компилировалась release ipa'шка и отправлялась на планшет.
AS3 делалась в последнем Flash CC и бете AIR 4, с типом публикации «Apple App Store».

Исходники?
github.com/Hitek55/AS3NapeTest
github.com/Hitek55/HaxeNapeTest

Скриншоты?
Линки на полноразмерки:
Air s9.postimg.org/5xr1hjlyl/IMG_0258.png
Haxe s17.postimg.org/hokwuszfh/IMG_0257.png

Результаты:
Давайте разберемся с исходниками и выведем производительность Air на уровень Хакса =)
Air 4 выдавал 5-20 кадров в секунду.
Хакс же проседал до 45 кадров в начале сцены (когда у Эйра было 5 FPS), когда все 210 физ.объектов прикасаются друг к другу и летят вниз, потом фпс поднимается до стабильных 60 и более не опускается.

Что я делаю не так?

UPD#1
Прилепил quadBatch, drawcalls = 1, фпс теперь колеблется от 18 до 38. Сорцы обновил.

UPD#2
Отключил рендер, мах FPS был 50 кадров, что существенно уступает хаксу.

UPD#3
326 тел хакс выдерживает достойно:
при создании ~25 кадров,
когда разлетаются ~60,
лежат и прикасаются, 45, пока не заснут
5.firepic.org/5/images/2013-11/16/orc1merzvlgt.png
  • +5

Комментарии (71)

0
Ща придёт TheRabbit и всё тебе расскажет :)
  • SeeD
  • SeeD
  • ↓
0
Я для него же эти тесты сделал)
0
Кролик очень занят. Навскидку — объясни почему в Air версии у тебя 210 DRAWCALLS? Там должно быть не более 3х. 4 максимум. И еще ответь мне в теме наконец-то на счет сборки SWC
0
Я конечно не сильно разбираюсь в старлинге, но вот эта строчка:
0 
var image:Image = Image.fromBitmap(new Img());


намекает на то, что наверняка на каждую такую картинку создается текстура. отсюда и столько дроуколлов. тогда как в hx-версии юзается тайл-леер который рисует через 1 дроуколл :)
+1
Тут и разбираться не надо — создавать 210 объектов каждый раз с уникальной текстурой размером 64х64 и тем самым создавать 210 проходов отрисовки GPU — верх неправильности. Для таких вещей придумали атласы либо пул объектов. В данном случае — текстуру надо 1 натягивать на всё, а не 1 на 1 объект.

Я не знаю как устроен хакс и его компиляция в натив, но дико интересно стало… Прикрути туда подсчет drawcalls, чтоб было ясно. Можешь мне в приват залепить как ты хакс собирал — я у себя тоже его собрать попробуй. У меня iPad4 — не могу тестировать соответственно.

Могу тебе скинуть ipa где у меня 60 fps. Main.ipa ставь его, джейл не нужен. И опиши свой опыт просмотра моей сборки.
0
Ставлю на то что OpenFL-овский TileLayer рисует всё за 1 дроуколл, ибо текстура одна, что логично. Интересно было бы посмотреть сравнение «нормальной» as3-версии, которая так же по идее должна за 1 дроуколл отрисосывать, хотя к чему всё это писькомерство, я не знаю :)
0
Выше я дал ссылку на файл ipa — в нем сертификат мой корпоративный. ipa станет на любой ipad без надобности джейла. Ограничение — там retina onlye. Тупо нормальная версия, где 1 drw на as3 )
0
Ты сделал тоже что и я? FPS идентичный, что в моей сборке, что в твоей.
0
Я вынес из цикла:
var texture : Texture = Texture.fromBitmap(new Img(),false);

а в цикле написал:
var image:Image = new Image(texture);


Таким образом, 210 объектов используют 1 текстуру, а не 210 разных. Меньше Draw calls — больше fps.
0
Ты имеешь ввиду, что в моей сборке 5-20 fps и 210 DRW тоже???
0
Я в Nape вижу много косяков в коде. Но это к Луке. А он со мной не хочет разговаривать.
Да и в as3 файле есть моменты, которые можно поправить еще ;) Мне просто некогда это ща делать. Мне надо сервер настраивать…
0
Не, и в моей и в твоей от 20 до 40 теперь.
0
Просто для интереса спрошу.
А почему ты сначала меняешь позицию спрайта, а потом делаешь space.step()?
Это какая-то хитрая оптимизация?
Типа пока ГПУ жует vertex buffer ты степаешь физику?
0
Правда, никогда значение этому не придавал.
0
Поправил.
0
Может вообще рендер отключить?
Оставить только фпс.
0
Согласен, начните с этого. А потом почините батчинг в старлинге, чтобы был один дроукол на сцену.
0
Починили, фпс вырос в ~2 раза.
0
Отключил рендер, мах FPS был 50 кадров.
+1
На скриншотах у Air спрайты сглаженные по краям, у Haxe — «лесенка».
Может, если привести к единому виду то и FPS почти сравняется? )
0
Если причесать Nape и взять не Starling, а Genome2D — то FPS не почти, а сравняется ;)
0
Только Genome2D переписывается на Haxe.
Бинго
0
Он про as3. Да и для чего прикручивать геном2д, если без рендера air не вытягивает 60 фпс?
0
Отключил сглаживание у текстур, результат тот же 3.firepic.org/3/images/2013-11/16/9u74bi7ujziw.png
0
Ну и что выяснили? Во сколько раз натив быстрее чем эир? OpenFL прикольная штука — хотя не пробовал, но для себя поставил заметку, что если нужна будет нативная производительность то вот вариант.
0
По поводу результатов тестов — как уже ни раз сравнивалось — эир очень неплох когда много графики, но мало cpu вычислений — что мы увидели как я понял когда отключили рендер — только цифра фпс у опен фл не была озвучена — сколько? Вот чем мне кажется просто обязаны заниматься в адоб так это оптимизацией as3 компилятора — если flashcc генерирует в несколько раз более производительный байткод для той же виртуальной машины, то явно места для оптимизации еще много.
0
flashcc тоже далек от натива, хоть конечно и лучше чистого ас3 www.youtube.com/watch?v=IH4mrUagA74
0
Не ну это ясно — натив есть натив — вопрос насколько флешсс код быстрее чем аналочичный код на as3 — с одной c одной стороны тормоза от сборщика мусора ка есть так и останутся — нужно кэшировать частосоздаваемые- убиваемые обьъекты на ас3 — но если есть разница в производительности кода в котором нет выделения памяти — вот это уже серьезный повод для оптимизации.
0
Тоже интерсен flascc и чистый as3. Инфы в сети не нашел.
Надо наверное будет небольшой тест запилить.
вот бокс фласц github.com/jesses/wck/wiki/box2d-flash-alchemy-port
0
Вру, вот тест.
Алхимия — 42 FPS
Обычный — 33 FPS
Разница 21%.
Может как раз в этом всё и дело с хексом и as3?
0
Слушай ну 20% — это ерунда — тут рассказывали что енкодер mp3 на флешсс в разы быстрее работает
0
Кстати а для 2д физики есть нативный эктеншн подобный? Потому что как я понят тут многих именно тормоза физики в эире беспокоят — данное нативное расширение по моему эти вопросы снимает
0
github.com/mnem/box2d_ane 2 сек гугления
0
Та мне это не интересно — хотел тему для обсуждения интересующихся подкинуть :) я просто не понимаю откуда тогда все эти домыслы какая была бы производительность эира если бокс в нативный экстеншн перевести — вот же есть уже вроде
0
Еще недавно автор старлинга писал, выяснил что нужно избегать вызова функций у которых в декларации есть (… args) то есть принимает произвольное количество параметров — потому что в этом случае при вызове функции каждый раз выделяется массив, что создает понятное дело нагрузку на сборщик мусора. То есть например обычное добавление в вектор myVector.push(obj) лучше заменить на myVector[myVector.length] = obj
0
Сори, пока не копался в хексе. Т.е. он выбрасывает натив C++ для iOS? Без всякий встроенных рантаймов?
0
Насколько мне известно — да
0
То есть это open fl такое дает — а язык да — хакс
0
Ну не совсем без рантаймов, все-таки хекс — язык со сборкой мусора, поэтому у него есть либа поддержки (hxcpp), которая реализует, например GC. Короче свой небольшой рантаймец :)
0
Там на плюсах этот рантайм эмулируется. Счетчики ссылок, триллион всяких методов и полей на любой класс и т.п.
0
лол что? что значит эмулируется? там полноценный сборщик мусора реализован. «триллион методов» — это в основном для рефлекшена и поддержки динамических фич haxe. это ли не рантайм? :)
0
>> что значит эмулируется?

Значит именно то, что я написал. Язык си++ не имеет встроенного рантайма аля haxe и он эмулируется имеющимися средствами языка.

>> там полноценный сборщик мусора реализован

Через подсчёт ссылок он реализован в том числе.

>> это ли не рантайм?

Скорее всего имеет место быть неопределённость при использовании термина. Рантайм в данном контексте это встроенные возможности языка времени исполнения. На плюсах фичи хакса приходится эмулировать разумеется.
0
326 тел хакс выдерживает достойно:
при создании ~25 кадров,
когда разлетаются ~60,
лежат и прикасаются, 45, пока не заснут
5.firepic.org/5/images/2013-11/16/orc1merzvlgt.png
0
сорри — результаты как то не систематизированы — то есть у эйра 210 тел давало 18-38 фпс — у хакса 326 тел — 45-60 фпс — так? это при включенном рендере на обоих?
0
Да, так, с рендером.
0
то есть раза в 4 эир проигрывает опен фл в данном тесте (210*18 / 326*45 = 0.26)
0
Некорректно все же разное кол-во объектов сравнивать.
0
так выкладывай цифры с одинаковым кол-вом объектов сравним!
0
Протестил Air. Минимум 10кадров, максимум 23 при 326 тел.
0
как ни крути в 4 раза где-то: 10 fps (эир) против 45 (хакс)
0
какие 10 против 45…? собери nape на с++ в native extension и ты получишь свои 45 кадров назад. Тормозит физика в as3, а не отрисовка stage3d. Вообще глупый тест.

Пиши сразу, — 1 против 4.5 — так круче выглядеть будет. Или «вообще не запускается против белого экрана».
+2
1) Перепиши физику на native extension
2) Перепиши логику на native extension
3) Перепиши графику на native extension
4) Выкинь AIR за ненадобностью
…
6) PROFIT :D
0
Ну так пиши нативно. Кто тебе не дает? Может быть незнание?
+1
Ну так пиши нативно.
Бинго! Это как раз и есть пропущенный пятый пункт. Ты начал этот список — ты его и завершил. Ведь можешь же :D
0
Т.е. ты считаешь, что я уверен в том, что с нативом по скорости можно погонятся на Air или на Unity?
Все, кто умеют писать нативно — им ни html5 ни air ни unity3d ни marmelade нафиг не нужен. Я думал это озвучивать даже смысла нет ибо это капитанство…
0
Издеваешься? Переписать Nape на ANE — это нужно потратить 1-2 месяца, и иметь приличные знания в С++, а ты говоришь, будто это раз плюнуть.
0
Чувак, писавший Box2D ANE на гитхабе забросил проект, потому что он стал непомерно большим, и он просто не осилил его доделать.
0
Меня Nape в том виде в каком он есть сейчас — устраивает на 150%
0
Интересно будет ли жив флеш лет так через 20.
0
Конечно будет. Но он будет не такой как сейчас. Будет намного мощнее. Возможно ActionScript «Next» станет первым шагом, уже давно очень ожидаемым шагом
0
«Next», который отменили, ага.
0
Ну не отменили, а отложили релиз. По их словам потому что помнят какие были проблемы быстрого и сырого релиза as3
0
Adobe will focus its future Flash Player development on top of the existing Flash Player architecture and virtual machine, and not on a completely new virtual machine and architecture (Flash Player «Next») as was previously planned. At the same time, Adobe plans to continue its next-generation virtual machine and language work as part of the larger web community doing such work on web-based virtual machines.

Отмена разработки плеера Next не так плохо, т.к. провести серьезное улучшения текущей VM существенно способно увеличить производительность. Конечному пользователю без разницы как это будет называться, ведь главное тут — не отказ от улучшений. По-этому не надо сеять панику. Все хорошо.
0
Ну так чем все закончилось?
Почему никто не рассказывает про энкодеры мп3 бороздящие пространство большого театра?
0
Всмысле? что тебе рассказывать? О кривом* Nape, который из Caxe собран был в Haxe из которого потом AS3 делается, работая с которым виратульная машина современная напрягается из-за «магии», которая работала отлично раньше, но не сейчас?

* кривизна заключается в том, что течет память и байт код хоть и работает — делает это он не так, как должен. За это «спасибо» haxe «магии», которая действительно была актуально раньше. На старой VM. Это уже ясно стало благодаря куче внутренних тестов.

Nape быстрый, но может быть быстрее. Самое интересное — если OpenFL использует Nape от haxe, а не от as3 swc — то улучшив Nape мы добьемся еще большей производительности на устройстве именно в Air, а не OpenFL.
0
… если OpenFL использует Nape от haxe, а не от as3 swc
А какой ему смысл использовать as3 swc?
0
ну так это и объясняет скорость nape в данном тесте. собрать его в ANE и можно смело бить себя в гордую грудь :)
+13
Господа. Вы меня извините, но уже замучили этими 5см vs 6см vs 7 см. Хотите скорости — идите на native чистый. Каждый пишет на том, на чем хочет. Любая технология имеет преимущества и недостатки. Любые фреймворки содержат ошибки. Не полагайтесь на то, что кто-то за Вас сделал что-то правильно. Starling — работает медленее, чем самописный движок. Nape работает медленее чем самописный. Хочешь сделать что-то лучше — сделай это сам. С чем тут спорить? Я буквально в конце лета писал как не надо делать тесты и тут мы видим в этой теме «не знал, что от этого зависит».

Сначала узнайте все от корочки до корочки и потом принимайте решения и убеждайте людей в чем-то. Кому мало одной технологии — двигайте на другую. Не надо только свои неудачи описывать так, как это неудача всей системы. Это лично Ваш опыт. И уверен, что Ваш опыт имеет ошибки реализации и не надо его выставлять как единственно правильный.

Посмотрите на IE — глюк на глюке. Кто-то запрещает под управлением Windows работать в другом браузере? Тогда что Вы тут доказываете?
0
занавес.
0
Ну наконец то же! Плюсую!
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.