Производительность ARM vs Thumb на iPhone 3GS, код без плавающей запятой

Question

Мне было интересно, есть ли у кого-нибудь какие-нибудь точные цифры по производительности ARM vs Thumb code на iPhone 3GS.Специально для кода с неплавающей запятой (VFP или NEON) - я знаю о проблемах с производительностью с плавающей запятой в режиме Thumb.

Есть ли момент, когда дополнительный размер кода больших инструкций ARM становится угрозой производительности?Другими словами, если мой исполняемый код относительно невелик по сравнению с доступной памятью, есть ли какие-либо измеренный разница в производительности при включении режима Thumb?

Причина, по которой я спрашиваю, заключается в том, что, хотя я могу включить ARM для исходных файлов, специфичных для NEON, в Xcode, используя опцию "-marm", это прерывает сборку симулятора, поскольку GCC создает x86.Мне было интересно, должен ли я просто отключить "compile as thumb" и покончить с этим.

Answer 1

Я не знаю насчет iPhone, но общее утверждение о том, что thumb работает медленнее, чем ARM, вообще неверно.Учитывая 32-битную память с нулевым состоянием ожидания, thumb будет немного медленнее, например, 5% или 10%.Теперь, если это thumb2, это другая история, говорят, что thumb2 может работать быстрее, я не знаю, что есть в iPhone, я предполагаю, что это не thumb2.
Если у вас не заканчивается 32-разрядная память в состоянии нулевого ожидания, то ваши результаты будут отличаться.Одна большая вещь - это 32-битная память.Если вы работаете на 16-разрядной шине, подобной семейству GameBoy Advance, и в этой памяти или ПЗУ есть некоторые состояния ожидания, то thumb может легко превзойти ARM по производительности, даже если для выполнения той же задачи требуется больше инструкций thumb.

Протестируйте свой код!Нетрудно изобрести тест, который дает те результаты, которые вас интересуют, или нет.Показать, что рука сдувает большой палец, так же легко, как большой палец сдувает руку.Кого волнует, что такое dhrystones, важно то, насколько быстро он запускает ВАШ код СЕГОДНЯ.

Что я обнаружил за годы тестирования производительности кода для ARM, так это то, что ваш код и ваш компилятор являются важным фактором.Таким образом, thumb теоретически работает на несколько процентов медленнее, потому что он использует на несколько процентов больше инструкций для выполнения той же задачи.Но знаете ли вы, что ваш любимый компилятор может быть ужасным и, просто переключая компиляторы, вы могли бы работать в несколько раз быстрее (gcc попадает в эту категорию)?Или использовать один и тот же компилятор и смешивать параметры оптимизации.В любом случае вы можете скрыть разницу между рукой и большим пальцем, проявив смекалку в использовании инструментов.Вы, вероятно, знаете это, но вы были бы удивлены, узнав, как много людей думают, что единственный известный им способ компиляции кода - это единственный способ повысить производительность - использовать больше памяти или другого оборудования для решения проблемы.

Если вы пользуетесь iPhone, я слышал, что эти люди используют LLVM?Мне нравится концепция llvm во многих отношениях, и я горю желанием использовать ее в качестве своего ежедневного драйвера, когда она созреет, но обнаружил, что она создает код, который был на 10-20% (или намного больше) медленнее для конкретной задачи, которую я выполнял.Я был в режиме arm, я не пробовал режим thumb, и у меня был включен кэш l1 и l2.Если бы я тестировал без кэшей, чтобы действительно сравнить thumb с arm, я бы, вероятно, увидел, что thumb работает на несколько процентов медленнее, но если подумать (что меня в то время не интересовало), вы можете кэшировать в два раза больше кода thumb, чем кода arm, что МОЖЕТ означать, что даже при том, что в целом для задачи на несколько процентов больше кода, кэшируя значительно больше его и сокращая среднее время выборки, thumb может быть заметно быстрее.Возможно, мне придется пойти и попробовать это.

Если вы используете llvm, у вас есть другая проблема, связанная с несколькими местами для выполнения оптимизации.Переходя от C к байт-коду, вы можете оптимизировать, затем вы можете оптимизировать сам байт-код, затем вы можете объединить весь ваш байт-код и оптимизировать его в целом, затем при переходе от байт-кода к ассемблеру вы можете оптимизировать.Если бы у вас было только 3 исходных файла и предполагалось, что для каждой возможности существует только два уровня оптимизации, которые не оптимизируются или действительно оптимизируются, с gcc у вас было бы 8 комбинаций для тестирования, с llvm количество экспериментов почти на порядок выше.Больше, чем вы действительно можете запустить, от сотен до тысяч.Для одного теста, который я запускал, НЕ оптимизируя на этапе C для байт-кода, затем НЕ оптимизируя байт-код при разделении, но оптимизируя после объединения файлов байт-кода в один большой (ger).Оптимизация с помощью llc на пути к arm дала наилучшие результаты.

Итог ... тест, тест, тест.

Редактировать:

Я использовал слово байт-код, я думаю, что правильный термин - битовый код в мире LLVM.Код в файлах .bc - это то, что я имею в виду...

Если вы переходите с C на ARM, используя LLVM, в середине есть битовый код (bc).Существуют параметры командной строки для оптимизации на шаге C-bc.После bc вы можете оптимизировать каждый файл от bc к bc.При желании вы можете объединить два или более bc-файлов в более крупные bc-файлы или просто превратить все файлы в один большой bc-файл.Затем каждый из этих объединенных файлов также может быть оптимизирован.

Моя теория, за которой пока стоит всего пара тестовых примеров, заключается в том, что если вы не проводите никакой оптимизации до тех пор, пока не соберете всю программу / проект в одном большом файле bc, оптимизатор получит максимальный объем информации if, с помощью которой сможет выполнить свою работу.Таким образом, это означает переход от C к bc без оптимизации.Затем объедините все файлы bc в один большой файл bc.Как только у вас будет все это в виде одного большого файла bc, позвольте оптимизатору выполнить свой этап оптимизации, максимизируя информацию и, надеюсь, качество оптимизации.Затем перейдите из оптимизированного файла bc в ARM assembler.По умолчанию для llc включена оптимизация, вы действительно хотите разрешить эту оптимизацию, поскольку это единственный шаг, который знает, как оптимизировать для целевого объекта.Оптимизация от bc до bc является общей и не зависит от конкретной цели (AFAIK).

Вам все еще нужно тестировать, тестировать, тестировать.Продолжайте и поэкспериментируйте с оптимизацией между шагами, посмотрите, заставляет ли это вашу программу работать быстрее или медленнее.

Answer 2

Смотрите этот PDF-файл из ARM / Thumb, чтобы найти компромиссы между производительностью, размером кода и энергопотреблением.

Выбор РУКИ и большого пальца с учетом профиля Инструкции
   - Факультет компьютерных наук Аризонского университета, автор Раджив Гупта

Answer 3

Код Thumb, по сути, всегда будет медленнее, чем эквивалентный ARM.Единственный случай, когда Thumb-код может значительно повысить производительность, - это если он делает разницу между вашим кодом, помещаемым во встроенную память или кэш.

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

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