Оптимизация компиляции для iPhone: с плавающей запятой или с фиксированной запятой?

Question

Я собираю библиотеку для iphone (speex, но я уверен, что она будет применяться и ко многим другим библиотекам), и в скрипте make есть возможность использовать фиксированную точку вместо плавающей точки.

Поскольку процессор iphone ARM имеет расширение VFP и очень хорошо выполняет вычисления с плавающей запятой, считаете ли вы, что лучше использовать опцию с фиксированной запятой?

Если кто-то уже оценил это и хочет поделиться, ябыл бы очень благодарен ему.

Answer 1

Ну, это зависит от настроек вашего приложения, вот некоторые рекомендации

1. Сначала попробуйте включить оптимизацию до 0 (самый быстрый)
2. Включить Relax IEEE Compliance
3. Если ваше приложение может легко обрабатывать числа с плавающей запятой в смежных областях памяти независимо, вы должны взглянуть на встроенные инструкции ARM NEON и инструкции по сборке, они могут обработать до 4 чисел с плавающей запятой в одной инструкции.
4. Если вы уже интенсивно используете математику с плавающей точкой, попробуйте переключить часть своей логики на фиксированную точку (но имейте в виду, что переход от регистра NEON к целочисленному регистру приводит к полной остановке конвейера)
5. Если вы уже интенсивно используете целочисленную математику, попробуйте изменить часть своей логики на математику с плавающей запятой.
6. Не забудьте профиль до оптимизации
7. И, что самое главное, лучшие алгоритмы всегда будут лучше микрооптимизаций, таких как приведенные выше.

Answer 2

Если вы имеете дело с большими блоками последовательных данных, NEON определенно вам подойдет.

Float или исправлено, это хороший вопрос. NEON несколько быстрее справляется с фиксированным, но я бы сохранил исходный формат ввода, поскольку преобразования требуют времени и, в конечном итоге, дополнительной памяти.

Даже если библиотека предлагает в качестве опции другой формат вывода, это почти всегда означает преобразования внутри библиотеки. Так что я думаю, что float является родным в этом случае. Придерживайтесь этого.

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

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