Я помню из C дней, что нам было предложено использовать
i > -1
вместо
i >= 0
из-за производительности.
Это все еще применяется в мире С#.NET? Каковы последствия производительности использования одного над другим с сегодняшними компиляторами? т.е. достаточно ли достаточно для компилятора оптимизировать их для вас?
(В качестве опции попробуйте ввести тип "use >= или > " в поле вопроса в "Переполнение стека" и посмотрите, что произойдет.)
Нет, нет проблем с производительностью, связанных с операторами сравнения. И любой хороший компилятор в любом случае оптимизирует что-то такое тривиальное.
Я не уверен, где вы получили предложение использовать "i > -1", а не "i >= 0" . В архитектуре x86 нет никакой разницы, которую вы используете: в одном случае выполняется ровно две инструкции... один для сравнения и один для перехода:
;; if (i > -1) {
cmp eax, -1
jle else
then:
...
else:
;; if (i >= 0) {
cmp eax, 0
jl else
then:
...
else:
В большинстве архитектур RISC, которые я знаю, "i >= 0" может быть быстрее, поскольку обычно имеется специальный нулевой регистр, а "i > -1" может потребовать загрузки константы. Например, MIPS имеет только < инструкция (нет < =). Вот как две конструкции были бы (наивно!), Выраженные на языке ассемблера MIPS:
// if (i >= 0) { (assuming i is in register %t0)
stl $t1, $0, $t0 // in C: t1 = (0 < t0)
beq $t1, $0, else // jump if t1 == 0, that is if t0 >= 0
nop
then:
...
else:
// if (i > -1) { (assuming i is in register %t0)
addi $t2, $0, -1 // in C: t2 = -1
stl $t1, $t2, $t0 // in C: t1 = (t2 < t0) = (-1 < t0)
bne $t1, $0, else // jump if t1 != 0, that is if t0 > -1
nop
then:
...
else:
Итак, в наивном общем случае на самом деле будет одна инструкция быстрее делать "i >= 0" на MIPS. Конечно, код RISC настолько оптимизирован, что компилятор, скорее всего, изменит любую из этих последовательностей команд почти до неузнаваемости: -)
Итак... короткий ответ - нет, нет, нет разницы.
Не говоря уже о том, что любой достойный компилятор делает правильные вещи, и кроме того, что в современных архитектурах нет разницы в скорости между сравнениями > и >=, большая картинка гласит, что это "микро -оптимизация", которая не влияет на производительность во время выполнения в подавляющем большинстве случаев.
В случае сравнений он обычно не влияет на читаемость, какой бы способ вы его не пишете, но есть случаи, когда выбор одной границы над другой более ясен: например,
if (length >= str.size())
против
if (length > str.size() - 1)
Я не знаю о вас, но я бы выбрал вариант 1 в любой день.:-) В случаях, которые не оказывают заметного влияния на производительность, например, этот выигрыш должен быть более удобочитаемым.
Существует очень похожий вопрос (без критики, как вы говорите, поиск символов сложнее): "Если использовать < или <= в для петля"
(Да, я могу найти его легко, так как у меня много ответов на мой ответ...)
В принципе, сделайте все, что можно прочитать. В тот день, когда кто-то правильно догадывается, что внесение изменений в сторону от наиболее читаемой формы решит проблему производительности (без помощи профилировщика), я перестаю говорить о производительности:)
Нет, вам больше не нужно это делать. Да, компиляторы стали намного умнее, а два выражения не имеют различий в производительности.
Я помню из C дней, что нам было предложено использовать... из-за производительности.
Вы уверены в этом? Я работал с компьютерами, восходящими к началу 70-х (да, у моего отца колено...), и я никогда не видел процессор, который не мог обработать >= так же быстро, как > . (BH "Branch High" и BNL "Branch Not Low" в разговоре IBM360).
Это могло быть правдой для некоторых теневых языков сценариев, которые разбивают a >= на 2 сравнения, но кто бы ни побуждал вас использовать это для C... ну... вы, вероятно, должны стараться забыть все, что они когда-либо говорили вы.
Это напоминает мне рекомендацию использовать ++ я вместо я ++ (pre-increment vs. post-increment), потому что это была предположительно одна инструкция быстрее. (Я забыл, где я изначально читал об этом, но это был, вероятно, журнал пользователей C/С++ или Dr. Dobb Journal, но я не могу найти веб-ссылку.)
Я серьезно сомневаюсь, что > или >= быстрее или медленнее; вместо этого напишите свой код для ясности.
В качестве побочного примечания я разработал предпочтение для оператора pre-increment (++ i), даже если причина сейчас является устаревшей.
Для больше нуля он должен выполнить две проверки. Он проверяет, выключен ли отрицательный бит, и проверяет, выключен ли нулевой бит.
Для большего или равного нулю, только нужно проверить, выключен ли отрицательный бит, потому что нам не важно, включен ли нулевой бит.