2013-06-10 4 views
0

Я использую Eigen library, чтобы сделать некоторые вычисления на iPad 2. (то есть cortex-a9). Кажется, что некоторые операции векторизованы с использованием инструкций NEON, а другие нет.Собственное не векторизация матричного умножения в iOS?

Операции, которые я пробовал, чтобы получить векторизованные: точечные продукты, векторные и матричные дополнения и вычитания.

Операции, которые не становятся векторизованными: матричное умножение.

Я использую эти операции внутри одного и того же проекта и того же файла, поэтому параметры компилятора одинаковы. Я использую -O3 -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp.

Все матрицы, которые я использую, имеют динамические размеры. Есть ли что-то, что я делаю неправильно, или это ожидаемое поведение?

Спасибо.

+0

Насколько точно вы пришли к выводу, что некоторые операции вектурированы, а другие нет? Проверка кода? Как GCC, так и Clang испускают неоновые инструкции для операций с плавающей запятой для НЕОН, оборудованного блоком FP ​​на частях Cortex A. Кроме того, вы действительно хотите «-mfloat-abi-softfp» для iOS? Это обычное явление в Linux-land, где людям нравится создавать программное обеспечение, совместимое со множеством различных версий ARM-арки, но с неприятным штрафом во время исполнения. Вместо этого Apple выбирает жирные двоичные файлы. – marko

+0

Я использую Xcode Instruments для проверки кода ассемблера. Для точечного продукта я вижу кучу 'vadd' и' vmov', но не для матричного умножения. Кроме того, точечный продукт приводит к значительному улучшению функции OpenCV (примерно 50%), однако матричное умножение этого не делает. – user1906

ответ

0

Когда вы используете -mfpu=neon, gcc/clang будет векторизовывать целые операции, но не с плавающей точкой, потому что NEON не является 100% -ной жалобой IEEE (он не поддерживает денормальные числа). Вы должны указать -ffast-math, чтобы gcc/clang векторизовал код с плавающей запятой с помощью NEON. Однако вы должны быть осторожны, так как -ffast-math может повлиять на числовые результаты.

+0

no, фактически Eigen явно векторизовывает свою работу, когда NEON правильно включен независимо от наличия -ffast-math. Я думаю, проблема в том, что опция -mfloat-abi-softfp должна быть удалена. – ggael

+0

'-mfloat-abi = softfp' означает« использовать регистры общего назначения для передачи параметров, но аппаратные инструкции для вычислений FP ». Это не должно быть проблемой, программы Android всегда используют регистры общего назначения для передачи параметров. –

+0

'-mfloat-abi = softfp' - неприятный компромисс, который был принят на системах ARM Linux, включая Android. Несомненно, случаи, когда этот вариант является большим хитом производительности, особенно учитывая, что существует огромный перенос транзакций между NEON и целочисленным блоком, что должно происходить в прологах функций и эпилогах, когда аргументы передаются в целочисленных регистрах Один из причины, по которым он по-прежнему используется, - это «черные ящики» IP, поставляемые поставщиками SoC, - подумайте о OpenGL и библиотеках пользовательского пространства для доступа к аппаратным средствам камеры, которые встроены в эту конвенцию ABI. – marko