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

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

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

вы действительно хотите разрешить эту оптимизацию, поскольку это единственный шаг, который знает, как оптимизировать для цели. Оптимизации от bc до bc являются общими, а не целевыми (AFAIK).

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

вы действительно хотите разрешить эту оптимизацию, поскольку это единственный шаг, который знает, как оптимизировать для цели. Оптимизации от bc до bc являются общими, а не целевыми (AFAIK).

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