Re: Перекомпиляция основных программ
Н. Артём <Artiom14@yandex.ru> writes:
> -falign-jumps=32 и подобное
>> -- позволяет до некоторой степени понизить вероятность сильных
>> отклонений, но не исключает их полностью [и, кстати, не
>> *увеличивает* в данном случае производительность, а именно
>> стабилизирует -- но не до конца, увы].
> Хм... Но ведь без изменения чего-бы то ни было, компилятор должен
> каждый раз создавать одинаковый код..?
Да, gcc обещает воспроизводимость на уровне "такой же код из такого же
исходника с такими же опциями" -- если только мы от этой
воспроизводимости очевидным образом не отказываемся,
см. -branch-probabilities.
Однако это неважно. Когда мы меряем влияние оптимизации, нам же не
интересно "без изменения" [и так ясно, что одинаковые бинарники
одинаковы] -- нам интересно, как какие-то конкретные опции влияют.
Каждая опция влияет двумя способами: "как задумано" [согласно её прямому
смыслу] и "как получится" [побочными эффектами из-за того, что код
расположен по-другому]. Если мы хотим получить обобщаемые результаты,
нам нужно первый способ учесть, а второй "выфильтровать".
В качестве иллюстрации представим древний компилятор, который ничего не
знает про выравнивание кода и никогда к нему не стремится, но у которого
есть -fomit-frame-pointer. Представим ситуацию, когда при наличии лишних
mov %esp, %ebp / push %ebp у вас точка входа в следующую функцию
случайно пришлась на адрес, кратный 16 байтам -- а эта функция вдруг
оказалась самой часто-вызываемой. "Наивная" методика тестирования может
привести вас к выводу, что -fomit-frame-pointer тормозит.
Так вот, набор тестов, который позволил бы отфильтровать шум, можно
получить для конкретной опцимизации [пример: как -ffast-math влияет на
скорость вычислений с плавающей точкой? Тестируем много *разных*
алгоритмов, у которых эти самые вычисления происходят большую часть
времени, потом расширяем массив измерений с помощью "шевеления" тех
опций, эффект от которых нас не интересует -- и знаем, что [1] на разных
программах "случайные" влияния пойдут в случайном направлении и не
накопятся, [2] скорость fp влияет настолько сильнее всего остального,
что и без этого было бы неплохо].
А вот когда вы сравниваете на десктопе два ядра с -O2 -mtune=686 и -O4
-mtune=core2, и видите разницу в скорости загрузки системы -- и близко
непонятно, что вы в результате намеряли и сколько в этом везения или
невезения.
Ошибки в методах тестирования *готовых* бинарников, к счастью, хорошо
популяризованы. А вот то, что нехилая систематическая погрешность может
быть создана уже при компиляции, не столь известно. (да и для меня
оказалось новостью, что разница может быть в 10-20% -- хотя это не
каждый день бывает и тоже должно "повезти", но сам факт!)
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
Reply to: