Есть ли разница в оптимизации между определением переменной до цикла

Подскажите, есть ли разница в производительности между
и

Второй кусок кода с точки зрения принципа "где родился, там и пригодился" более лаконичный, но боюсь, что определение переменной отъедает доп процессорное время. Или нет?

0

Поскольку никто до сих пор не написал "расжеваный" ответ отвечу я.

По теме ТС - разницы нет. Undisputed сделал какой-то вброс ассемблерного листинга, который так и не смог объяснить. COKPOWEHEU показал дифы при разных ключах компиляции, там видно, что при некоторых оптимизациях даже в исполняемых файлах нет разницы. Там, где разница есть она заключается в следующем - при размещении переменной вне цикла ее адрес считается при каждом обращении, при размещении переменной в цикле адрес запоминается в регистре 1 раз и далее читается уже оттуда. Если говорить о скорости, то проще сказать, что разницы нет, т.к. отличие в одной микроинструкции (регистр + константа), которую ты никакими тестами не замеришь. К тому же эта разница похожа (как выразились выше) на глюки компилятора.

Сообщение от Undisputed Во втором листинге вроде да.

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

Добавлено через 1 минуту

Сообщение от Undisputed И как ты объяснишь существенную разницу по ссылке выше?

В variableCreatedInLoopResult data читается при кажой итерации цикла (потому что volatile), в variableCreatedNotInLoop только 1 раз до входа цикл. Отсюда такая разница.

0

Сообщение от Kastaneda COKPOWEHEU кстати ассемблерный листинг получается проще - ключом -S, для этого не нужно исполняемый файл дампить.

ключ -S не выдает отладочной информации, комментарии и соответствия ассемблерного листинга Си-шному коду.

0

Сообщение от COKPOWEHEU Таким образом, формально отличие есть, но слишком незначительное

GCC 8.2 -O3: https://godbolt.org/z/39Aeoe
Никаких различий вообще

0

TheCalligrapher, кстати, а сколько вариантов этого кода для различных процессоров gcc генерит? (сейчас нет под рукой). Студия генерит 3 разные точки входа.

0

Сообщение от Undisputed Вариант когда input за пределами цикла на моих тестах оказался быстрее. Можете проверить и у себя на всякий

Не смотрел код на asm, но было бы неплохо ещё сказать как компилируется код, т.к. при включении оптимизации компилятор может сделать такой же или похожий код.

0

Сообщение от TheCalligrapher Никаких различий вообще

Различия незначительные. У меня нет желания перебирать компиляторы того сайта в попытке воспроизвести результат.
Могу повторить: стандарт не гарантирует что результат компиляции будет идентичен до байта. Он не гарантирует какой из вариантов будет оптимальнее и на сколько. Попытки определить это на каком-то конкретном компиляторе дадут информацию только об этом компиляторе.

0

Сообщение от Kastaneda На самом деле в обоих функциях ничего не выкинуто

Естественно. Иначе как процессор просчитал бы результат?

Сообщение от Kastaneda В variableCreatedInLoopResult data читается при кажой итерации цикла (потому что volatile), в variableCreatedNotInLoop только 1 раз до входа цикл. Отсюда такая разница.

Ну вот. А я что говорил? Но на предыдущей странице ты заявлял обратное. Цитирую тебя:

Сообщение от Kastaneda Это же очевидно, в одной из функций не производится сложения.

Что касается моей ошибки при комментировании твоего листинга: смотрел его достаточно бегло и не вникал особо в код. Это была моя ошибка.

Сообщение от Kastaneda По теме ТС - разницы нет. Undisputed сделал какой-то вброс ассемблерного листинга, который так и не смог объяснить.

Что конкретно я должен был объяснить? Было заявление что разницы нет. Я выдал листинг с разницей. Не смог и не пытался это две разные вещи. Ок, если тебе нужно пояснение то я попробую пояснить более значимую разницу в первом листинге. Как ты сам заметил, в основном интересное тут то, что mov заменяется на lea. В случае когда переменная за пределами цикла используется lea, в противном случае mov.

Теперь попробуем разобраться что в данном контексте делают эти две команды.
Начнем с mov:
mov dest, src - копирует данные из src в dest. что бы скопировать данные из src в dest требуется доступ к памяти.

Теперь о lea:
Это арифметическая инструкция и в данном случае она грузит в регистр адрес данных но не сами данные. По этой причине доступ к памяти не требуется. Почему операция с доступом к памяти медленнее чем операция без доступа к памяти надеюсь рассказывать не нужно...

Сообщение от Kastaneda зачем ты выкладываешь ассемблерные листинги не понимая их)

См. выше

Добавлено через 6 минут
интересно что по этому поводу скажет hoggy,
будет надменно подшучивать или все таки расскажет почему он думает что операция с доступом к памяти быстрее либо одинаково чем простое сложение без доступа к памяти?

0

О каком из вариантов кода идет речь?

Сообщение от Undisputed Это арифметическая инструкция и в данном случае она грузит в регистр адрес данных но не сами данные. По этой причине доступ к памяти не требуется.

В последнем примере lea совсем не для этого используется, в самом первом память все равно читается.

Добавлено через 1 час 45 минут

Сообщение от Kastaneda В последнем примере lea совсем не для этого используется

Кому интересно вот, проматываем до п.3

0

Сообщение от Kastaneda О каком из вариантов кода идет речь?

Ты вроде про первый вариант спрашивал...
Попробую расписать ход своих мыслей:
В случае с lea адрес берется путем сложения stack pointer + offset, так?
Думаю на уровне процессора даже сложения не будет потому что стек как правило фиксированного размера и адрес rsp+offset должен быть известен заранее. То есть по идее в регистр просто запишется адрес. В случае же с mov, придется копировать данные из памяти одного регистра в память другого регистра.

Все же думаю по вышеперечисленным причинам вариант с lea должен быть быстрее.

0