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

@andrewkop85 · Регистрация: 20.09.2018

Студворк — интернет-сервис помощи студентам

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

C++
1
2
3
4
5
6
7
8
9
int i;
while () {
    ....
    ....
    i = 0;
    while () {
          .....
    }
}

и

C++
1
2
3
4
5
6
7
8
while () {
    ....
    ....
    int i = 0;
    while () {
          .....
    }
}

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

@Kastaneda · 28.09.2018, 14:12

Сообщение от Undisputed

Что бы они именно остались

А ты посмотрел ассемблер? Там точно ничего не выкинулось?

@Undisputed · 28.09.2018, 14:14

При volatile компилятор по идее обязан генерировать код который будет читать значения этой переменной из памяти.
Соответственно он не может полагаться на count заданный изначально и по этой причине не может оптимизировать цикл.

@Kastaneda · 28.09.2018, 14:15

Сообщение от Undisputed

При volatile компилятор по идее обязан генерировать код который будет читать значения этой переменной из памяти.
Соответственно он не может полагаться на count заданный изначально и по этой причине не может оптимизировать цикл.

Это я понимаю, но тело цикла то он может выкинуть? Загляни в ассемблер.

@Undisputed · 28.09.2018, 14:18

Сообщение от Kastaneda

А ты посмотрел ассемблер?

В этом случае нет. Просто время протестировал

Добавлено через 58 секунд

Сообщение от Kastaneda

Это я понимаю, но тело цикла то он может выкинуть?

Не понимаю по каким причинам он должен выкидывать тело цикла...
Нужно же пройтись count раз по коду что бы выдать верный результат для sum

Добавлено через 1 минуту
Kastaneda,
Кажется я понял почему ты так думаешь. Потому что после подсчета sum никак не используется в моем примере.
Я просто забыл его сюда добавить.

@hoggy · 28.09.2018, 14:42

Сообщение от Undisputed

поэтому думаю и в ваших тестах не все так идеально.

о каких именно моих тестах идет речь?

Сообщение от Undisputed

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

прежде чем замерять шум на микросхемах,
их нужно протереть тряпочкой.

@Kastaneda · 28.09.2018, 14:51

Сообщение от Kastaneda

ты "слона" не видишь) основная разница не в этом, она есть

я переосмыслил код, не такой уж там и "слон", разница действительно мизерная.

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

Сообщение от Undisputed

Кажется я понял почему ты так думаешь. Потому что после подсчета sum никак не используется в моем примере.

давай ассемблер, покажи где там из цикла ничего не выкидывается

@COKPOWEHEU · 28.09.2018, 14:51

Сообщение от Kastaneda

COKPOWEHEU, у тебя по сути такой же выхлоп, что у Undisputed выше

В отличие от него я проверил все варианты оптимизации, и на самых распространенных -O0 и -Os разницы нет вообще

Сообщение от Kastaneda

ты "слона" не видишь) основная разница не в этом, она есть

Так поясни в чем она. Я в анализ не вдавался, как и в архитектуру х86_64

Сообщение от hoggy

тесты должны показывать стабильные результаты,
на которые можно и нужно закладываться.

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

@Kastaneda · 28.09.2018, 14:52

Сообщение от COKPOWEHEU

Так поясни в чем она.

см. мой ответы выше
Сейчас нам Undisputed должен рассказать в чем реально разница)

@Undisputed · 28.09.2018, 15:36

Сообщение от Kastaneda

Сейчас нам Undisputed должен рассказать в чем реально разница)

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include <iostream>
#include <chrono>
#include <cstdlib>
 
volatile size_t count = 10000000;
volatile size_t data = 123;
 
decltype(auto) variableCreatedInLoop()
{
    size_t sum = 0;
    
    auto start = std::chrono::steady_clock::now();
    
    for (size_t i = 0; i < count; i++)
    {      
        size_t add = data + 1;
        sum += add;
    }
    
    auto end = std::chrono::steady_clock::now();
    std::cout << sum << '\n';
    return end - start;
}
 
decltype(auto) variableCreatedNotInLoop()
{
    size_t sum = 0;
    size_t add = data + 1;
    
    auto start = std::chrono::steady_clock::now();
    for (size_t i = 0; i < count; i++)
    {      
        sum += add;
    }
    
    auto end = std::chrono::steady_clock::now();
    std::cout << sum << '\n';
    return end - start;
}
 
int main()
{
    if (variableCreatedInLoop() > variableCreatedNotInLoop()) {
        std::cout << "variableCreatedNotInLoop() faster than variableCreatedInLoop()\n";
    } else {
        std::cout << "equals or variableCreatedInLoop() faster than variableCreatedNotInLoop()\n";
    }
}

И где теперь эти хваленые оптимизации?

Добавлено через 1 минуту
Спасибо MrGluck за faster

@Kastaneda · 28.09.2018, 15:41

Сообщение от Undisputed

И где теперь эти хваленые оптимизации?

Вот же

variableCreatedInLoop

Assembler
1
2
3
4
5
6
7
.L3:
        mov     rdx, QWORD PTR data[rip]
        add     rax, 1
        lea     rbx, [rdx+1+rbx]
        mov     rdx, QWORD PTR count[rip]
        cmp     rdx, rax
        ja      .L3

variableCreatedNotInLoop

Assembler
1
2
3
4
5
6
.L12:
        mov     rdx, QWORD PTR count[rip]
        add     rax, 1
        add     rbx, rbp
        cmp     rdx, rax
        ja      .L12

Можешь объяснить, что из С++ кода здесь выкинулось? Или ты ассемблер не понимаешь? Если не понимаешь, то я могу расписать.

@Undisputed · 28.09.2018, 15:58

Сообщение от Kastaneda

Или ты ассемблер не понимаешь?

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

Так как разница в тестах существенна позволю себе дать ссылку на rextester.
http://rextester.com/UIWW60175

@Kastaneda · 28.09.2018, 16:12

Сообщение от Undisputed

листинг но он походу не полный

Это сами циклы, нет ощущения, что где-то сложение

C++
1
sum += add;

игнорируется?

@avgoor · 28.09.2018, 16:19

ИМХО, ТС спрашивал про про различия при оптимизации кода при ОДИНАКОВОМ поведении кода, но определении переменной в разных местах. при наличии volatile эти функции ведут себя ПРИНЦИПИАЛЬНО ПО-РАЗНОМУ. Как можно сравнивать их оптимизацию?

@Undisputed · 28.09.2018, 16:21

Kastaneda,
Во втором листинге вроде да.
Но как тогда идёт подсчёт?
Судя по всему твой компилятор забил на volatile и сразу посчитал данные.
А теперь попробуй создать ситуацию где данные заранее неизвестны

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

Добавлено через 1 минуту
avgoor,
Согласен. Я сейчас рассматриваю ситуацию в общем а не конкретный пример ТС.

@Kastaneda · 28.09.2018, 16:25

Сообщение от Undisputed

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

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

Сообщение от Undisputed

Судя по всему твой компилятор забил на volatile и сразу посчитал данные.

Нет, он такого не может сделать.

Сообщение от Undisputed

Но как тогда идёт подсчёт?

Вот же

Assembler
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
    .file   "tmp.cpp"
    .intel_syntax noprefix
    .section    .text.unlikely,"ax",@progbits
.LCOLDB0:
    .text
.LHOTB0:
    .p2align 4,,15
    .globl  _Z21variableCreatedInLoopv
    .type   _Z21variableCreatedInLoopv, @function
_Z21variableCreatedInLoopv:
.LFB1785:
    .cfi_startproc
    push    r12
    .cfi_def_cfa_offset 16
    .cfi_offset 12, -16
    push    rbp
    .cfi_def_cfa_offset 24
    .cfi_offset 6, -24
    push    rbx
    .cfi_def_cfa_offset 32
    .cfi_offset 3, -32
    sub rsp, 16
    .cfi_def_cfa_offset 48
    mov rax, QWORD PTR fs:40
    mov QWORD PTR [rsp+8], rax
    xor eax, eax
    call    _ZNSt6chrono3_V212steady_clock3nowEv
    mov r12, rax
    mov rax, QWORD PTR count[rip]
    test    rax, rax
    je  .L5
    xor eax, eax
    xor ebx, ebx
    .p2align 4,,10
    .p2align 3
.L3:
    mov rdx, QWORD PTR data[rip]
    add rax, 1
    lea rbx, [rdx+1+rbx]
    mov rdx, QWORD PTR count[rip]
    cmp rdx, rax
    ja  .L3
.L2:
    call    _ZNSt6chrono3_V212steady_clock3nowEv
    mov rsi, rbx
    mov edi, OFFSET FLAT:_ZSt4cout
    mov rbp, rax
    call    _ZNSo9_M_insertImEERSoT_
    lea rsi, [rsp+7]
    mov edx, 1
    mov rdi, rax
    mov BYTE PTR [rsp+7], 10
    call    _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
    mov rax, rbp
    sub rax, r12
    mov rcx, QWORD PTR [rsp+8]
    xor rcx, QWORD PTR fs:40
    jne .L9
    add rsp, 16
    .cfi_remember_state
    .cfi_def_cfa_offset 32
    pop rbx
    .cfi_def_cfa_offset 24
    pop rbp
    .cfi_def_cfa_offset 16
    pop r12
    .cfi_def_cfa_offset 8
    ret
.L5:
    .cfi_restore_state
    xor ebx, ebx
    jmp .L2
.L9:
    call    __stack_chk_fail
    .cfi_endproc
.LFE1785:
    .size   _Z21variableCreatedInLoopv, .-_Z21variableCreatedInLoopv
    .section    .text.unlikely
.LCOLDE0:
    .text
.LHOTE0:
    .section    .text.unlikely
.LCOLDB1:
    .text
.LHOTB1:
    .p2align 4,,15
    .globl  _Z24variableCreatedNotInLoopv
    .type   _Z24variableCreatedNotInLoopv, @function
_Z24variableCreatedNotInLoopv:
.LFB1789:
    .cfi_startproc
    push    r12
    .cfi_def_cfa_offset 16
    .cfi_offset 12, -16
    push    rbp
    .cfi_def_cfa_offset 24
    .cfi_offset 6, -24
    push    rbx
    .cfi_def_cfa_offset 32
    .cfi_offset 3, -32
    sub rsp, 16
    .cfi_def_cfa_offset 48
    mov rax, QWORD PTR fs:40
    mov QWORD PTR [rsp+8], rax
    xor eax, eax
    mov rbp, QWORD PTR data[rip]
    call    _ZNSt6chrono3_V212steady_clock3nowEv
    mov r12, rax
    mov rax, QWORD PTR count[rip]
    add rbp, 1
    test    rax, rax
    je  .L14
    xor eax, eax
    xor ebx, ebx
    .p2align 4,,10
    .p2align 3
.L12:
    mov rdx, QWORD PTR count[rip]
    add rax, 1
    add rbx, rbp
    cmp rdx, rax
    ja  .L12
.L11:
    call    _ZNSt6chrono3_V212steady_clock3nowEv
    mov rsi, rbx
    mov edi, OFFSET FLAT:_ZSt4cout
    mov rbp, rax
    call    _ZNSo9_M_insertImEERSoT_
    lea rsi, [rsp+7]
    mov edx, 1
    mov rdi, rax
    mov BYTE PTR [rsp+7], 10
    call    _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
    mov rax, rbp
    sub rax, r12
    mov rcx, QWORD PTR [rsp+8]
    xor rcx, QWORD PTR fs:40
    jne .L17
    add rsp, 16
    .cfi_remember_state
    .cfi_def_cfa_offset 32
    pop rbx
    .cfi_def_cfa_offset 24
    pop rbp
    .cfi_def_cfa_offset 16
    pop r12
    .cfi_def_cfa_offset 8
    ret
.L14:
    .cfi_restore_state
    xor ebx, ebx
    jmp .L11
.L17:
    call    __stack_chk_fail
    .cfi_endproc
.LFE1789:
    .size   _Z24variableCreatedNotInLoopv, .-_Z24variableCreatedNotInLoopv
    .section    .text.unlikely
.LCOLDE1:
    .text
.LHOTE1:
    .section    .rodata.str1.8,"aMS",@progbits,1
    .align 8
.LC2:
    .string "variableCreatedNotInLoop() faster than variableCreatedInLoop()\n"
    .align 8
.LC3:
    .string "equals or variableCreatedInLoop() faster than variableCreatedNotInLoop()\n"
    .section    .text.unlikely
.LCOLDB4:
    .section    .text.startup,"ax",@progbits
.LHOTB4:
    .p2align 4,,15
    .globl  main
    .type   main, @function
main:
.LFB1790:
    .cfi_startproc
    push    rbx
    .cfi_def_cfa_offset 16
    .cfi_offset 3, -16
    call    _Z24variableCreatedNotInLoopv
    mov rbx, rax
    call    _Z21variableCreatedInLoopv
    cmp rbx, rax
    jl  .L22
    mov esi, OFFSET FLAT:.LC3
    mov edi, OFFSET FLAT:_ZSt4cout
    call    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
.L20:
    xor eax, eax
    pop rbx
    .cfi_remember_state
    .cfi_def_cfa_offset 8
    ret
.L22:
    .cfi_restore_state
    mov esi, OFFSET FLAT:.LC2
    mov edi, OFFSET FLAT:_ZSt4cout
    call    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
    jmp .L20
    .cfi_endproc
.LFE1790:
    .size   main, .-main
    .section    .text.unlikely
.LCOLDE4:
    .section    .text.startup
.LHOTE4:
    .section    .text.unlikely
.LCOLDB5:
    .section    .text.startup
.LHOTB5:
    .p2align 4,,15
    .type   _GLOBAL__sub_I_count, @function
_GLOBAL__sub_I_count:
.LFB2135:
    .cfi_startproc
    sub rsp, 8
    .cfi_def_cfa_offset 16
    mov edi, OFFSET FLAT:_ZStL8__ioinit
    call    _ZNSt8ios_base4InitC1Ev
    mov edx, OFFSET FLAT:__dso_handle
    mov esi, OFFSET FLAT:_ZStL8__ioinit
    mov edi, OFFSET FLAT:_ZNSt8ios_base4InitD1Ev
    add rsp, 8
    .cfi_def_cfa_offset 8
    jmp __cxa_atexit
    .cfi_endproc
.LFE2135:
    .size   _GLOBAL__sub_I_count, .-_GLOBAL__sub_I_count
    .section    .text.unlikely
.LCOLDE5:
    .section    .text.startup
.LHOTE5:
    .section    .init_array,"aw"
    .align 8
    .quad   _GLOBAL__sub_I_count
    .globl  data
    .data
    .align 8
    .type   data, @object
    .size   data, 8
data:
    .quad   123
    .globl  count
    .align 8
    .type   count, @object
    .size   count, 8
count:
    .quad   10000000
    .local  _ZStL8__ioinit
    .comm   _ZStL8__ioinit,1,1
    .hidden __dso_handle
    .ident  "GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609"
    .section    .note.GNU-stack,"",@progbits

Сообщение от Undisputed

Во втором листинге вроде да.

Может в первом? Посчитай кол-во инструкций add.

@avgoor · 28.09.2018, 16:29

Undisputed, В общем случае при одинаковом наблюдаемом поведении - оптимизаторам пофиг, где и что вы определили, они сейчас достаточно умные. А то, про что говорите вы вообще не относится к оптимизации. Эти функции считают разные вещи. В таком случае определять переменную надо не "как быстрее" а "что нам надо посчитать".

@TheCalligrapher · 28.09.2018, 16:40

Как правильно было замечено в самом начале, для типов с тривиальной конструкцией и деструкцией, никакой разницы нет и быть не может (кроме разве что обусловленной глюками компилятора). Зачем и что тут мерить - не ясно.

@hoggy · 28.09.2018, 16:47

Сообщение от TheCalligrapher

Как правильно было замечено в самом начале, для типов с тривиальной конструкцией и деструкцией, никакой разницы нет и быть не может (кроме разве что обусловленной глюками компилятора). Зачем и что тут мерить - не ясно.

шум ветра на микросхемах. очевидно жеж.

@COKPOWEHEU · 28.09.2018, 17:13

Сообщение от TheCalligrapher

Как правильно было замечено в самом начале, для типов с тривиальной конструкцией и деструкцией, никакой разницы нет и быть не может (кроме разве что обусловленной глюками компилятора). Зачем и что тут мерить - не ясно.

Но ведь она есть, пусть и небольшая.

@TheCalligrapher · 28.09.2018, 17:21

Сообщение от COKPOWEHEU

Но ведь она есть, пусть и небольшая.

Какая именно?

Новые блоги и статьи Все статьи Все блоги /
ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Nekobox - outbounds[0].transport: unknown transport type: raw damix 01.10.2026 Фикс ошибки Правым кликом по серверу -> отладочная информация -> edit Заменить "net": "raw", на "net": "tcp", Нажать кнопку reload.	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	28.09.2018, 14:14
	При volatile компилятор по идее обязан генерировать код который будет читать значения этой переменной из памяти. Соответственно он не может полагаться на count заданный изначально и по этой причине не может оптимизировать цикл. 0

@avgoor 1550 / 877 / 179 Регистрация: 05.12.2015 Сообщений: 2,555
	28.09.2018, 16:19
	ИМХО, ТС спрашивал про про различия при оптимизации кода при ОДИНАКОВОМ поведении кода, но определении переменной в разных местах. при наличии `volatile` эти функции ведут себя ПРИНЦИПИАЛЬНО ПО-РАЗНОМУ. Как можно сравнивать их оптимизацию? 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	28.09.2018, 16:21
	Kastaneda, Во втором листинге вроде да. Но как тогда идёт подсчёт? Судя по всему твой компилятор забил на volatile и сразу посчитал данные. А теперь попробуй создать ситуацию где данные заранее неизвестны И как ты объяснишь существенную разницу по ссылке выше? Добавлено через 1 минуту avgoor, Согласен. Я сейчас рассматриваю ситуацию в общем а не конкретный пример ТС. 0

@avgoor 1550 / 877 / 179 Регистрация: 05.12.2015 Сообщений: 2,555
	28.09.2018, 16:29
	Undisputed, В общем случае при одинаковом наблюдаемом поведении - оптимизаторам пофиг, где и что вы определили, они сейчас достаточно умные. А то, про что говорите вы вообще не относится к оптимизации. Эти функции считают разные вещи. В таком случае определять переменную надо не "как быстрее" а "что нам надо посчитать". 0

@TheCalligrapher Вездепух 13229 / 6861 / 1827 Регистрация: 18.10.2014 Сообщений: 17,394
	28.09.2018, 16:40
	Как правильно было замечено в самом начале, для типов с тривиальной конструкцией и деструкцией, никакой разницы нет и быть не может (кроме разве что обусловленной глюками компилятора). Зачем и что тут мерить - не ясно. 0