В Си будет! ~ B когда-либо быстрее, чем b == 0xff?

Question

Давным-давно у меня застряла память, в которой говорится, что сравнение с нулем выполняется быстрее, чем любое другое значение (хм Z80).

В некотором C-коде, который я пишу, я хочу пропустить значения, в которых установлены все их биты. В настоящее время тип этих значений char, но может измениться. У меня есть два варианта выполнения теста:

if (!~b)
    /* skip */

и

if (b == 0xff)
    /* skip */

Помимо того, что последний делает предположение о том, что b является 8-битным символом, тогда как первый не делает, будет ли первый когда-либо быстрее из-за старого трюка по сравнению с нулевой оптимизацией, или современные процессоры намного выше этого

Answer 1

Если это быстрее, компилятор заменит его для вас.

В общем, вы не можете написать C лучше, чем компилятор может его оптимизировать. И в любом случае это зависит от архитектуры.

Короче говоря, не беспокойтесь об этом , если эта субмикро-нано-секунда не является чрезвычайно важной

Answer 2

Из того, что я помню на своих уроках архитектуры, я считаю, что они должны быть одинаково быстрыми. Оба имеют 2 инструкции.

Первый пример 1. Отрицание б в временный регистр 2. Сравните временный регистр, равный 0

Второй пример 1. Вычтите 0xff из b в временный регистр 2. Сравните временный регистр, равный 0

Они в основном идентичны, и, кроме того, даже если вашей конкретной архитектуре требуется больше или меньше, чем это, действительно ли это стоит доли наносекунды? Несколько минут было потрачено только на ответ на этот вопрос.

Answer 3

Я бы сказал, что не столько ЦП выходят за рамки этих уловок, сколько компиляторы .

Современные процессоры , однако, , выходят за рамки простых трюков, которые увеличивают такт или два такта. Даже если вы делаете это 100 000 раз в секунду, мы все еще говорим об увеличении скорости на 0,00003 секунды на одноядерном компьютере с частотой 3 ГГц - просто не стоит тратить время на подобные вещи.

Answer 4

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