Переменная x - int с возможными значениями: -1, 0, 1, 2, 3.
Какое выражение будет быстрее (в тиках процессора):
1. (x < 0)
2. (x == -1)
Язык: C/С++, но я полагаю, что все остальные языки будут иметь одинаковый язык.
P.S. Я лично считаю, что ответ (x < 0).
Более широко для гуру: что, если x от -1 до 2^30?
Это зависит полностью от ISA, которую вы компилируете, и от качества вашего оптимизатора компилятора. Не оптимизируйте преждевременно: сначала профиль, чтобы найти узкие места.
Тем не менее, в x86 вы обнаружите, что в обоих случаях они одинаково быстрые. В обоих случаях вы получите сравнение (cmp) и инструкции условного перехода (jCC). Однако для (x < 0) могут быть некоторые случаи, когда компилятор может выполнить команду cmp, ускоряя ваш код за один цикл.
В частности, если значение x хранится в регистре и в последнее время является результатом арифметической операции (например, add или sub, но есть еще много возможностей), которая устанавливает флаг знака SF в регистре EFLAGS, тогда нет необходимости в команде cmp, и компилятор может испустить только команду js. Нет простой инструкции jCC, которая перескакивает, когда входной сигнал равен -1.
Почему? Что бы вы ни делали, компилятор оптимизирует его на любой платформе, на которой вы сейчас компилируете.
Если вам нужно проверить, является ли оно -1, используйте (x == -1), если вы хотите узнать, меньше ли оно нуля, используйте его вместо этого. Напиши, что бы ты читал вслух.
Крошечные вещи вроде этого не будут делать ничего быстрее, и вы должны беспокоиться о читаемости и чистом дизайне, а не о том, какая крошечная операция выполняется быстрее.
И даже если это не приведет к каким-либо логическим изменениям, возможно, на вашей платформе, оба будут выполняться в одном цикле процессора.
Попробуй и посмотри! Сделайте миллион, или лучше, миллиард каждый и время их. Бьюсь об заклад, нет статистической значимости в ваших результатах, но кто знает - возможно, на вашей платформе и компиляторе вы можете найти результат.
Это отличный эксперимент, чтобы убедить себя, что преждевременная оптимизация, вероятно, не стоит вашего времени - и вполне может быть " корень всего зла - по крайней мере, в программировании.
Обе операции могут выполняться на одном шаге CPU, поэтому они должны быть одинаковыми по производительности.
Это может зависеть от того, какие операции предшествуют или преуспевают в сравнении. Например, если вы назначаете значение x перед выполнением сравнения, то, возможно, быстрее проверить флаг знака, чем сравнивать с определенным значением. Вы можете повлиять на производительность процессора, зависящую от процессора.
Но, как говорили другие, это зависит от архитектуры процессора, архитектуры памяти, компилятора и многих других вещей, поэтому нет общего ответа.
x < 0 будет быстрее. Если ничего другого, это предотвращает получение константы -1 в качестве операнда. Большинство архитектур имеют специальные инструкции для сравнения с нулем, поэтому это тоже поможет.
Важным соображением, во всяком случае, является то, что на самом деле направляет поток вашей программы точно, и что просто приводит к такому же результату?
Если x - это действительно и индекс или значение в перечислении, то всегда будет то, что вы хотите, или будет работать какое-либо отрицательное значение? Прямо сейчас -1 является единственным отрицательным, но это может измениться.
Вы даже не можете ответить на этот вопрос вне контекста. Если вы попробуете тривиальный микрозапуск, вполне возможно, что оптимизатор внесет ваш код в эфир:
// 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.
То же самое, обе операции обычно выполняются за 1 такт.
Это зависит от архитектуры, но x == -1 более подвержен ошибкам. x < 0 - путь.
Как говорили другие, вероятно, нет никакой разницы. Сравнения - это такие фундаментальные операции в процессоре, которые разработчики чипов хотят сделать как можно быстрее.
Но есть еще кое-что, что вы могли бы подумать. Проанализируйте частоты каждого значения и сравните их в этом порядке. Это может сэкономить вам довольно много циклов. Конечно, вам все равно нужно скомпилировать ваш код в asm, чтобы проверить это.
Я уверен, что вы уверены, что это настоящий тайм-аут.
Я бы предположил, что попросить машину дать более надежный ответ, чем мог бы дать любой из нас.
Я нашел, даже в коде, как вы говорите, мое предположение, что я знал, где время идет, было не совсем правильным. Например, если это во внутреннем цикле, если есть какой-либо вызов функции, даже невидимый, вставленный компилятором, стоимость этого вызова будет доминировать далеко.
Николай, вы пишете:
Это фактически оператор узких мест в программа высокой нагрузки. Производительность эти 1-2 строки намного более ценны чем читаемость...
Все узкие места обычно маленький, даже в идеальном дизайне с совершенные алгоритмы (хотя нет например). Я занимаюсь обработкой высокой нагрузкой и знаю мое поле и мои алгоритмы довольно хорошо
Если да, почему бы не сделать следующее:
Вы получите ответ.