Скорость доступа к локальной и глобальным переменным в GCC / G ++ на разных уровнях оптимизации
Я обнаружил, что различные уровни оптимизации компилятора в GCC дают совсем разные результаты при доступе к локальной или глобальной переменной в цикле. Причина, по которой это удивило, что если доступ к одному типу переменной более оптимизируемо, чем доступ к другому, я бы подумал, что оптимизация GCC будет эксплуатировать этот факт. Вот два примера (в C ++, но их C ++, но их C-коллеги дают практически одинаковые сроки):
global = 0;
for (int i = 0; i < SIZE; i++)
global++;
, которые используют глобальную переменную Long Global , против
long tmp = 0;
for (int i = 0; i < SIZE; i++)
tmp++;
global = tmp;
на уровне оптимизации -O0, по существу Как я ожидаю), на -O1 он несколько быстрее, но все еще равен, но из -2 версия, использующая глобальную переменную намного быстрее (фактор 7 или около того).
С другой стороны, в следующих фрагментах кода, где начинаются указывает на блок байтов размера размера:
global = 0;
for (const char* p = start; p < start + SIZE; p++)
global += *p;
по сравнению с размером
long tmp = 0;
for (const char* p = start; p < start + SIZE; p++)
tmp += *p;
global = tmp;
здесь в -O0 сроки закрыты, хотя версия, использующая локальную переменную, немного Быстрее, что не кажется слишком удивительным, так как, возможно, он будет храниться в реестре, тогда как Глобал не будет. Затем на -O1 и выше версия, используя локальную переменную значительно быстрее (более 50% или 1,5 раза). Как отмечалось раньше, это удивляет меня, потому что я бы подумал, что для GCC было бы так же легко, как и для меня, чтобы использовать локальную переменную (в сгенерированном оптимизированном коде), чтобы назначить глобальную позже.
Итак, мой вопрос: то, что это о глобальных и локальных переменных, что делает, что GCC может выполнять определенные оптимизации только к одному типу, а не другую?
Некоторые детали, которые могут или не могут быть актуальны: я использовал GCC / G ++ Версия 3.4.5 на машине работает RHEL4 с двумя одноразовыми процессорами и 4 ГБ оперативной памяти. Значение, которое я использовал для размера, который представляет собой препроцессорный макрос, составлял 1000000000. Блок байтов во втором примере был динамически выделен.
Вот некоторые выходные данные сроки оптимизации от 0 до 4 (в том же порядке, что и выше):
$ ./st0
Result using global variable: 1000000000 in 2.213 seconds.
Result using local variable: 1000000000 in 2.210 seconds.
Result using global variable: 0 in 3.924 seconds.
Result using local variable: 0 in 3.710 seconds.
$ ./st1
Result using global variable: 1000000000 in 0.947 seconds.
Result using local variable: 1000000000 in 0.947 seconds.
Result using global variable: 0 in 2.135 seconds.
Result using local variable: 0 in 1.212 seconds.
$ ./st2
Result using global variable: 1000000000 in 0.022 seconds.
Result using local variable: 1000000000 in 0.552 seconds.
Result using global variable: 0 in 2.135 seconds.
Result using local variable: 0 in 1.227 seconds.
$ ./st3
Result using global variable: 1000000000 in 0.065 seconds.
Result using local variable: 1000000000 in 0.461 seconds.
Result using global variable: 0 in 2.453 seconds.
Result using local variable: 0 in 1.646 seconds.
$ ./st4
Result using global variable: 1000000000 in 0.063 seconds.
Result using local variable: 1000000000 in 0.468 seconds.
Result using global variable: 0 in 2.467 seconds.
Result using local variable: 0 in 1.663 seconds.
Редактировать Это генерируемая сборка для первых двух фрагментов с Switch -O2, случай, когда разница является крупнейшей. Насколько я понимаю, он выглядит как ошибка в компиляторе: 0x3b9aca00 размер в шестнадцатеричном уровне, 0x80496dc должен быть адрес глобального. Я проверил с более новым компилятором, и это не происходит больше. Однако разница во второй паре фрагментов аналогична.
void global1()
{
int i;
global = 0;
for (i = 0; i < SIZE; i++)
global++;
}
void local1()
{
int i;
long tmp = 0;
for (i = 0; i < SIZE; i++)
tmp++;
global = tmp;
}
080483d0 <global1>:
80483d0: 55 push %ebp
80483d1: 89 e5 mov %esp,%ebp
80483d3: c7 05 dc 96 04 08 00 movl $0x0,0x80496dc
80483da: 00 00 00
80483dd: b8 ff c9 9a 3b mov $0x3b9ac9ff,%eax
80483e2: 89 f6 mov %esi,%esi
80483e4: 83 e8 19 sub $0x19,%eax
80483e7: 79 fb jns 80483e4 <global1+0x14>
80483e9: c7 05 dc 96 04 08 00 movl $0x3b9aca00,0x80496dc
80483f0: ca 9a 3b
80483f3: c9 leave
80483f4: c3 ret
80483f5: 8d 76 00 lea 0x0(%esi),%esi
080483f8 <local1>:
80483f8: 55 push %ebp
80483f9: 89 e5 mov %esp,%ebp
80483fb: b8 ff c9 9a 3b mov $0x3b9ac9ff,%eax
8048400: 48 dec %eax
8048401: 79 fd jns 8048400 <local1+0x8>
8048403: c7 05 dc 96 04 08 00 movl $0x3b9aca00,0x80496dc
804840a: ca 9a 3b
804840d: c9 leave
804840e: c3 ret
804840f: 90 nop
Наконец, вот код остальных фрагментов, которые теперь сгенерированы GCC 4.3.3 с использованием -O3 (хотя старая версия, кажется, создает аналогичный код). Похоже, что действительно Global2 (..) компилирует функцию, доступа к глобальной памяти в каждой итерации цикла, где local2 (..) использует реестр. Мне все еще не понятно, почему GCC не будет оптимизировать глобальную версию, используя реестр в любом случае. Это просто не хватает функции, или он действительно приведет к недопустимому поведению исполняемого исполнения?
void global2(const char* start)
{
const char* p;
global = 0;
for (p = start; p < start + SIZE; p++)
global += *p;
}
void local2(const char* start)
{
const char* p;
long tmp = 0;
for (p = start; p < start + SIZE; p++)
tmp += *p;
global = tmp;
}
08048470 <global2>:
8048470: 55 push %ebp
8048471: 31 d2 xor %edx,%edx
8048473: 89 e5 mov %esp,%ebp
8048475: 8b 4d 08 mov 0x8(%ebp),%ecx
8048478: c7 05 24 a0 04 08 00 movl $0x0,0x804a024
804847f: 00 00 00
8048482: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
8048488: 0f be 04 11 movsbl (%ecx,%edx,1),%eax
804848c: 83 c2 01 add $0x1,%edx
804848f: 01 05 24 a0 04 08 add %eax,0x804a024
8048495: 81 fa 00 ca 9a 3b cmp $0x3b9aca00,%edx
804849b: 75 eb jne 8048488 <global2+0x18>
804849d: 5d pop %ebp
804849e: c3 ret
804849f: 90 nop
080484a0 <local2>:
80484a0: 55 push %ebp
80484a1: 31 c9 xor %ecx,%ecx
80484a3: 89 e5 mov %esp,%ebp
80484a5: 31 d2 xor %edx,%edx
80484a7: 53 push %ebx
80484a8: 8b 5d 08 mov 0x8(%ebp),%ebx
80484ab: 90 nop
80484ac: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi
80484b0: 0f be 04 13 movsbl (%ebx,%edx,1),%eax
80484b4: 83 c2 01 add $0x1,%edx
80484b7: 01 c1 add %eax,%ecx
80484b9: 81 fa 00 ca 9a 3b cmp $0x3b9aca00,%edx
80484bf: 75 ef jne 80484b0 <local2+0x10>
80484c1: 5b pop %ebx
80484c2: 89 0d 24 a0 04 08 mov %ecx,0x804a024
80484c8: 5d pop %ebp
80484c9: c3 ret
80484ca: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
Спасибо.