Pull to refresh

Comments 20

Я правильно понял, что в процессе портирования были исключены оптимизированные варианты некоторых функций (вместе с файлами, их содержащими), и вместо них проект подхватил их generic-реализации, написанные на C++ и потому компилирующиеся как на ARM, так и на IA-32?
В таком случае насколько, по вашему мнению, оправдано в дальнейшем написание аналогично соптимизированных (например, c задействованием асма/интринсиков SSE/AVX) специализаций этих функций для IA-32? Ожидаете ли вы дополнительного прироста в скорости работы движка от подобных усилий?
В данном случае исключаются не компоненты библиотеки, а некоторый семпл, просто являющийся частью общего комплекта библиотеки.

Еще учтите, что движок изначально кросс-платформенный. Поэтому, интринсики SSE там есть. Другое дело, что они не работают, но это не относится к теме поста.
… некоторый семпл ...
Действительно, сами пути к файлам на это намекают:
sample/test_ARM_NEON_...

Мы исключили компоненты самой библиотеки, оптимизированные под ARM:
src/base_level/solver/pfx_constraint_row_solver_neon.cpp
include/vecmath/neon/vectormath_neon_assembly_implementations.S

Да, сэмплы удалили тоже :)
Да, вы поняли правильно — под ARM взята версия из коробки, а под х86 потребовались небольшие изменения, но они окупились. :)
Для того чтобы ответить на ваше вопрос нужно сначала проанализировать какой ассемблер генерится компилятором, если он не векторизует критические к производительности участки кода, то тогда необходима ручная модификация, например, переписывание на интринсики или ассемблерные вставки. Такой анализ мы еще не проводили.
Судя по вашему приросту производительности, код генерится компилятором отличный. Хотя, нет в мире совершенства, может, что-то и улучшится, особенно, если заработает SSE часть.
А все таки какова скорость для ARM с включенным неоном?
Уточню вопрос:
Данный девайс IA32 архитектуры?
ARM на нем исполняется через трансляцию?
Отвечаю на свой же вопрос
Да он IA32
Да ARM через трансляцию.

То есть ваш вывод на мой взгляд должен быть немного другим:
Разработчикам обязательно надо собирать две версии ABI IA32 и ARM а андроид сам загрузит нужный.
А вот слова про «можно считать двукратное ускорение вычислений физики» это уже передергивание, так как в вашем случае идет транслция с ARM в IA32.

Поправите меня если я неправ?
Да, оба раза приложение запускается на IA32 девайсе, сначала через трансляцию. А вывод «Результатом успешного портирования на архитектуру x86, для конкретного примера, можно считать двукратное ускорение вычислений физики» абсолютно корректен (ускорение в сравнении с непортированной версией), как и корректно то, что вы говорите, одно другому не противоречит.
В «Таблица 1.» сравнивается производительность нативного x86 кода с работой эмулятора ARM на x86? Это же на голову не налазит, вы бы еще с эмулятором PS1 под Android скорость сравнивали!
Ну и числа 30 FPS и 60 FPS тоже никуда не годятся — уж очень они похожи на лимит vsync. Чтобы тест был адекватным надо проверять на двух реальных устройствах с похожими параметрами. Причем, сцену надо нагрузить так, чтобы FPS сам по себе просел из-за физики ниже порогового значения, хоть до 40 FPS в x86 варианте. Естественно, надо делать это с минимумом отрисовки, чтобы не оказалось, что сравниваются видеочипы.
Ну и в конце-концов, я не вижу «портирования» в каком-либо виде — ни одной строки кода не было изменено, только небольшие правки конфигов для смены build target.
Там нет эмулятора. Houdini — компонета, транслирующая бинарный ARM код в код x86. Причем, перед выполнением, а не во время. Ничего не эмулируется.
Насчет портирования выабсолютно правы, я именно это и сказала авторам, они общали подумать :). Но, с другой стороны, это отличная новость для разработчиков. Если все, что им надо для «портирования» — это сменить конфиги, то сделать это явно стОит, даже если бы прирост не был столь велик.
Давайте называть вещи своими именами — трансляция кода одной архитектуры на другую это именно разновидность эмуляции (emulation refers to the ability of a computer program in an electronic device to emulate (imitate) another program or device). Красивые ярлыки вроде Houdini, Rosetta или QuickTransit не отменяют факт, что производительность такого решения будет далека от нативной.
Статья имеет право на жизнь лишь из-за того, что подтверждает факт, что кросс-платформенная Bullet Physics компилируется под NDK почти без бубна, и это здорово. Но стоит ее дополнить удачными замерами скорости и чуть уменьшить гремящую «канцелярщину» в стиле, как посыплются плюсы и благодарности :)
О, да, давайте называть вещи своими именами. Тогда по-вашему получается, что любой компилятор- это эмулятор, ведь он переводит программу, написанную на английском языке в машинный код конкретного процессора, т.е. эмулирует то, что напрямую можно написать в машинном коде :)
А производительность далека от нативной по простой причине -при прямой компиляции идет оптимизация под конкретный процессор, скажем, автовекторизация, а при переводе -не идет.
Спасибо большое за идею исследовать масштабируемость данного приложения. Мы решили провести «усложненный» тест производительности. Демонстрационное приложение из статьи вычисляет взаимодействие 192 коробок, падающих на плоскость. Мы заставили наше устройство попотеть — увеличили число коробок в 16 раз — 3072 штуки.
image
ARM версия — 2 fps
x86 версия — 4 fps
Замеры проводились на одном и том же устройстве Samsung Galaxy tab 3 10.1, брали средний FPS за минуту работы приложения.
Чтобы убедиться, что данное приложение является CPU-bound, то есть львиная доля работы приходится именно на вычислительную составляющую мы воспользовались возможностью Intel GPA — Disable Draw Calls (данный эксперимент эмулирует бесконечно быстрый драйвер и GPU) в результате FPS не изменился, следовательно можно предположить, что данное приложение CPU-bound.
Уже гораздо лучше!
Я бы посоветовал бы выбрать в этот раз немного меньше моделей, чтобы было к примеру 20 fps в одном режиме и 10 fps в другом — обычно в тестах стараются избегать граничных значений, вдруг уже при таком количестве моделей бутылочное горлышко в памяти или где-то еще? Но все-равно это уже заметно показательнее. Для полноты теста осталось провести такой тест на ARM устройстве, чтобы быть уверенным, что имеет вообще смысл компилировать этот движок под ARM, может вообще окажется, что ему место только на Intel-ах.
А можно результат с точностью хотя бы 2 знака после запятой.
Я бы конечно посмотрел бы на ms по физике только.
Но если это сложно то хотябы для fps.
А то там может быть 2.99 vs 4.0 FPS.
Sign up to leave a comment.