Уважаемые коллеги, хочу задать вопрос по оценке оптимизаций. Есть оптимизации,

которые после их применения компилятором "дают" 0.5%-3% выигрыша в числе попугаев на популярных бенчмарках. Есть тот же самый LLVM Bolt, с ним носятся как с писаной торбой, но который, судя по публикациям, даёт 7%. Это же все равно очень мало даже для того, чтобы произвести оценку! У меня замеры на монопольно используемом телефоне иногда просто прыгают на плюс/минус 5%, а здесь типа 7. Понятно, что можно брать среднее за 5-10 замеров, откидывать "вылеты" (скатиться в черри-пикинг), высчитывать дисперсию и стандартное отклонение, но что-то в работах я такого педантизма не наблюдаю или невнимательно читал.

А вопрос такой: может есть какой-то другой подход к оценке оптимизаций? Я знаю только хардварные счётчики, в случае Болта можно красиво показать, как уменьшаются icache и tlb миссы, но на выходе это превращается в те же 7%. А если взять не такие глобальные, классические оптимизации типа ArgumentPromotion, Dead code elimination, etc., их кто-то когда-то обосновывал в научных работах и как доказывали полезность?

Ну вообще черрипикинг это модно - незначительное приемущество, раздутое до якобы инновации - актуальный тренд в науке(95% нейросетей оказываются работающими хорошо только на "удачных" данных). Если же брать оптимизации, то естественно несмотря на не самый большой прирост производительности в процентах, на деле это может экономить минуты и часы времени, особенно если учесть что таких оптимизаций много и в сумме прирост оказывается значимее. В остальном - полезностб оптимизации можно оценить иногда лишь статистически, но причина не в неоднозначности оптимизаций, а во влиянии среды выполнения, в виде планировщика ОС, профилировщика, кэшей процессора, которые вносят шум в измерения. Поэтому по моему опыту иронично, но берут - самый быстрый прогон из десяти-двадцати у каждой из версий и только по ним строят оценки, ибо эти прогоны ближе всего к чистым, неперегруженным средой результатам.

7% это дофига (например, если задача идет час, то эти 7% - 4.2 минуты). Если задача многопоточная, то так можно на 128 ядрах сэкономить почти 9 CPU-часов! > Замеры на монопольноо используемом телефоне Там (1) системный шедулер мешается. Попробуйте прибивать тестируемую программу к какому-то определенному ядру с помощью numactl. (2) на вычислительных задачках можно перегреть телефон и частоты процессора упадут. Надо частоты стабилизировать для этого. Вариант - тестировать на нормально охлаждаемом железе, желательно с выключенным TurboBoost. В целом на современном серверном железе у меня получается видеть разницу до 0.1% на минутных запусках задачи, если я действительно один на ноде (зачастую хватает одного-двух прогонов теста, если все правильно сделано). > Dead code elimination Меньше бесполезного кода грузим в кеши => процессор меньше бессмысленной работы делает => считает быстрее. Вообще в процессорах много различных счетчиков, по которым можно оценить влияние различных оптимизаций включая/выключая их. (Ну и см.ответ выше)

Тестовая инфраструктура дотнета использует время работы тестов для оценки улучшений JIT. Если это совпадает с теоретической оценкой но изменения были сложные с потенциальными сайд эффектами берутся крупные внутренние проекты вроде Бинга и проекты с открытым кодом(что есть так как мало) На основании этого выводы про эффективность делают

Большое спасибо за ответ, я тоже склонялся к идее взять самый быстрый результат без оптимизаций и с оптимизациями, но смущало, что это некрасиво. Я понимаю, что 7% это много, вопрос в том, а есть ли они на самом деле. Вот тут ниже мне написали, что если правильно настроить тестовую среду, то можно увидеть 0.1%, но здесь скорее всего зависит от длительности теста ещё. Вообще про игру с числами целиком и полностью согласен, видел примеры, где так и объясняют, мол смотрите кода стало меньше на х%, а значит меньше нагрузка на кэш, ну а дальше какие-то логические выводы, но даже результаты бенчмарков не показывают. Чувствую здесь какое-то лукавство.

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

А время работы тестов изменяется в часах, минутах или как-то ещё, т.е. там большие тесты или микробенчмарки?

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

А вот в Java есть JMH, очень удобный тул как раз для написания микробенчмарков с прогревом JVM и прочими полезностями. Я подробно тестовую базу не смотрел, но понимаю, что микробенчмарки активно используются. А почему в .net не так? Или речь именно о компиляторных оптимизациях?

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

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

Стикер