Что быстрее (x <0) или (x == -1)?

Ответ 1

Это зависит полностью от ISA, которую вы компилируете, и от качества вашего оптимизатора компилятора. Не оптимизируйте преждевременно: сначала профиль, чтобы найти узкие места.

Тем не менее, в x86 вы обнаружите, что в обоих случаях они одинаково быстрые. В обоих случаях вы получите сравнение (cmp) и инструкции условного перехода (jCC). Однако для (x < 0) могут быть некоторые случаи, когда компилятор может выполнить команду cmp, ускоряя ваш код за один цикл.

В частности, если значение x хранится в регистре и в последнее время является результатом арифметической операции (например, add или sub, но есть еще много возможностей), которая устанавливает флаг знака SF в регистре EFLAGS, тогда нет необходимости в команде cmp, и компилятор может испустить только команду js. Нет простой инструкции jCC, которая перескакивает, когда входной сигнал равен -1.

Ответ 2

Почему? Что бы вы ни делали, компилятор оптимизирует его на любой платформе, на которой вы сейчас компилируете.

Если вам нужно проверить, является ли оно -1, используйте (x == -1), если вы хотите узнать, меньше ли оно нуля, используйте его вместо этого. Напиши, что бы ты читал вслух.

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

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

Ответ 3

Попробуй и посмотри! Сделайте миллион, или лучше, миллиард каждый и время их. Бьюсь об заклад, нет статистической значимости в ваших результатах, но кто знает - возможно, на вашей платформе и компиляторе вы можете найти результат.

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

Ответ 4

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

Ответ 5

Это может зависеть от того, какие операции предшествуют или преуспевают в сравнении. Например, если вы назначаете значение x перед выполнением сравнения, то, возможно, быстрее проверить флаг знака, чем сравнивать с определенным значением. Вы можете повлиять на производительность процессора, зависящую от процессора.

Но, как говорили другие, это зависит от архитектуры процессора, архитектуры памяти, компилятора и многих других вещей, поэтому нет общего ответа.

Ответ 6

x < 0 будет быстрее. Если ничего другого, это предотвращает получение константы -1 в качестве операнда. Большинство архитектур имеют специальные инструкции для сравнения с нулем, поэтому это тоже поможет.

Ответ 7

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

Если x - это действительно и индекс или значение в перечислении, то всегда будет то, что вы хотите, или будет работать какое-либо отрицательное значение? Прямо сейчас -1 является единственным отрицательным, но это может измениться.

Ответ 8

Вы даже не можете ответить на этот вопрос вне контекста. Если вы попробуете тривиальный микрозапуск, вполне возможно, что оптимизатор внесет ваш код в эфир:

// Get time
int x = -1;
for (int i = 0; i < ONE_JILLION; i++) {
    int dummy = (x < 0); // Poof!  Dummy is ignored.
}
// Compute time difference - in the presence of good optimization
// expect this time difference to be close to useless.

Ответ 9

То же самое, обе операции обычно выполняются за 1 такт.

Ответ 10

Это зависит от архитектуры, но x == -1 более подвержен ошибкам. x < 0 - путь.

Ответ 11

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

Но есть еще кое-что, что вы могли бы подумать. Проанализируйте частоты каждого значения и сравните их в этом порядке. Это может сэкономить вам довольно много циклов. Конечно, вам все равно нужно скомпилировать ваш код в asm, чтобы проверить это.

Ответ 12

Я уверен, что вы уверены, что это настоящий тайм-аут.

Я бы предположил, что попросить машину дать более надежный ответ, чем мог бы дать любой из нас.

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

Ответ 13

Николай, вы пишете:

Это фактически оператор узких мест в программа высокой нагрузки. Производительность эти 1-2 строки намного более ценны чем читаемость...

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

Если да, почему бы не сделать следующее:

• получить таймер, установить его на 0;
• скомпилируйте свою программу с высокой нагрузкой с помощью (x < 0);
• запустите свою программу и таймер;
• в конце программы посмотрите на таймер и запомните результат1.
• то же, что и 1;
• скомпилируйте свою программу с высокой нагрузкой с помощью (x == -1);
• то же самое, что и 3;
• в конце программы посмотрите на таймер и запомните результат2.
• сравнить результат1 и результат2.

Вы получите ответ.