Почему неподписанные типы более эффективны в CPU руки?
Я читаю руководство руки и прихожу к этому предложению, но причина не упоминается.
Почему неподписанные типы быстрее?
2 ответа
Думаю, просто набор инструкций для процессоров ARM оптимизирован для работы без знака. Некоторые операции могут быть выполнены с одной инструкцией для беззнаковых типов, но потребуются несколько инструкций, если она подписана. Вот почему я думаю, что при компиляции для ARM в большинстве (всех?) Компиляторах C и C ++ по умолчанию используется unsigned char, а не более обычный знаковый char.
Единственные преимущества беззнаковых типов, о которых я могу думать, это то, что реализации деления и по модулю могут быть немного быстрее, и вы можете выполнять тесты вроде if (unsigned_value if (signed_value> = 0 && signed_value
Я подозреваю, что ваше руководство может быть устаревшим. Любая используемая сегодня ARM будет иметь v4 или более позднюю версию набора инструкций, и я почти уверен, что никакие инструкции не будут быстрее или медленнее в зависимости от подписи.
Я считаю, что на старых ARM умножение со знаком могло быть медленнее; Я думаю, что раннее завершение искало только все нули в старших битах, а не все единицы, поэтому умножение с использованием отрицательных чисел всегда занимало максимальное время. Хотя это зависело от значения, а не от того, был ли тип подписан или без знака. По крайней мере, на ARMv4 и более поздних версиях раннее завершение работает для отрицательных значений.
Кроме того, я думаю, что очень ранние ARM не могли загружать ни одного байта, только слово. Таким образом, вам понадобятся две инструкции для загрузки байта без знака и три для загрузки байта со знаком:
ldr r0, [r1]
and r0, r0, #0xff
против
ldr r0, [r1]
mov r0, r0, asl #24
mov r0, r0, asr #24 ; but this could maybe be combined with later instructions
против (в наши дни) ldrb r0, [r1] или ldrsb r0, [r1] для однобайтовой загрузки.
На современном процессоре маловероятно, что использование беззнаковых типов окажет заметное влияние на производительность. Используйте тот тип, который имеет наибольший смысл, а затем подробно изучите код, как только обнаружите узкие места в производительности.