Н. Артём <artio...@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
