Я не знаю об iPhone, но общее заявление о том, что большой палец медленнее, чем 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% (или намного больше) медленнее для конкретной задачи, которую я выполнял. Я был в режиме руки, я не пробовал режим большого пальца, и у меня был включен кеш l1 и l2. Если бы я тестировал без кешей, чтобы действительно сравнить большой палец с рукой, я, вероятно, увидел бы, что большой палец на несколько процентов медленнее, но если подумать (что меня не интересовало в то время), вы можете кэшировать в два раза больше кода большого пальца, чем кода руки, который МОЖЕТ означать, что, несмотря на то, что в целом для задачи имеется на несколько процентов больше кода, кэширование значительно большего его объема и сокращение среднего времени выборки может быть заметно быстрее. Возможно, мне придется попробовать это.
Если вы используете llvm, у вас есть другая проблема, связанная с несколькими местами для выполнения оптимизации. Переходя от C к байт-коду, вы можете оптимизировать, затем вы можете оптимизировать сам байт-код, затем вы можете объединить весь свой байт-код и оптимизировать его в целом, затем при переходе от байт-кода к ассемблеру вы можете оптимизировать. Если бы у вас было только 3 исходных файла и предполагалось, что для каждой возможности было только два уровня оптимизации, а те, которые не оптимизируются или оптимизируются, с gcc у вас было бы 8 комбинаций для тестирования, с llvm количество экспериментов почти на порядок выше. . Больше, чем вы можете пробежать, от сотен до тысяч. Для одного теста, который я запускал, НЕ оптимизировался на этапе C для байт-кода, а затем НЕ оптимизировал байт-код, когда он был отдельным, но оптимизировал после объединения файлов байт-кода в один большой (ger). Оптимизация ООО на пути к вооружению дала наилучшие результаты.
Итог... тест, тест, тест.
РЕДАКТИРОВАТЬ:
Я использовал слово байт-код, я думаю, что правильным термином является бит-код в мире LLVM. Я имею в виду код в файлах .bc...
Если вы переходите с C на ARM с помощью LLVM, в середине есть битовый код (bc). Существуют параметры командной строки для оптимизации на этапе C to bc. После bc вы можете оптимизировать для каждого файла, от bc до bc. Если вы решите, вы можете объединить два или более файла bc в большие файлы bc или просто превратить все файлы в один большой файл bc. Затем каждый из этих объединенных файлов также можно оптимизировать.
Моя теория, за которой пока стоит всего пара тестовых случаев, заключается в том, что если вы не выполняете никакой оптимизации до тех пор, пока у вас не будет всей программы/проекта в одном большом файле bc, у оптимизатора будет максимальное количество информации, с которой можно работать. делать свою работу. Так что это означает переход от C к bc без оптимизации. Затем объедините все файлы bc в один большой файл bc. Как только вы получите все это в виде одного большого файла bc, позвольте оптимизатору выполнить свой шаг оптимизации, максимизируя информацию и, надеюсь, качество оптимизации. Затем перейдите от оптимизированного файла bc к ассемблеру ARM. Настройка по умолчанию для llc включает оптимизацию, вы хотите разрешить эту оптимизацию, поскольку это единственный шаг, который знает, как оптимизировать для цели. Оптимизация bc to bc является общей и не зависит от цели (AFAIK).
Вам еще предстоит тестировать, тестировать, тестировать. Продолжайте и поэкспериментируйте с оптимизацией между шагами, посмотрите, заставит ли это вашу программу работать быстрее или медленнее.
person
old_timer
schedule
02.08.2009
