Выполнение OR EQUAL против EQUAL назначения в цикле for - PullRequest
0 голосов
/ 25 ноября 2018

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

Рассмотрим цикл for, когда при выполнении определенного условия вы хотите сохранить trueв логическом:

b = false
for i in 1..N:
   if someCondition(i):
      b = true
   moreThatNeedsToBeDone(i)
endfor

Теперь рассмотрим то же самое для цикла с OR EQUAL вместо

b = false
for i in 1..N:
   if someCondition(i):
      b |= true
   moreThatNeedsToBeDone(i)
 endfor

Если условие выполнено более одного раза, будет ли последнее быстрее в теории?Или, по крайней мере, он будет делать меньше операций?В общем случае OR EQUAL оценивает переменную, и если она истинна, то она ничего не делает, следовательно, нет никакого дополнительного присваивания по сравнению с оператором EQUAL, где она будет хранить true несколько раз.Но, написав это, я понимаю, что OR EQUAL в любом случае добавляет дополнительную операцию для оценки / чтения текущего значения переменной.Итак, что будет быстрее или меньше операций?

1 Ответ

0 голосов
/ 26 ноября 2018

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

Если компилятор переводит буквально, операция |= не будет включать оценку переменной, чтобы узнать, следует ли выполнить значение ИЛИ или нет.Компилятор просто выдаст команду or, поскольку она будет эквивалентна и быстрее, чем первая проверка переменной (что может привести к очистке конвейера команд).

Без оптимизации сгенерированная сборка может быть (ax - это регистр процессора):

or ax,1  ; for b|=true

mov ax,1 ; for b=true

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

...