Страницы

Накладные расходы на структурное программирование

Когда речь заходит о структурном программировании, одним из аргументов противников того, чтобы кодировать исключительно структурно является вопрос производительности. На мой взгляд, структурный подход не может существенно понижать производительность, тем более при использовании оптимизирующих компиляторов. С другой стороны, большинство современных языков, используемых в производстве, не продвигают структурность, поэтому и их компиляторы не учитывают специфику подхода, что мешает использованию специальных оптимизаций. Так стоит ли волноваться по этому поводу? Для ответа на этот вопрос я написал небольшой тест, представляющий из себя несколько воплощений линейного поиска в трёхмерном массиве.

"Восток". Накладные расходы проверок.

Сообщения о трансляторе переехали в отдельный блог.

Сделал тест для измерения накладных расходов проверок корректности времени исполнения, которыми транслятор сопровождает основной код. Воплощены проверки: переполнения типа, выхода за границы массива, использования неинициализированных переменных, приведения базовой записи к расширенной, пользовательские ASSERT. Тест представляет собой специальную сборку транслятора, которая несколько раз собирает сама себя. Полагаю, это хороший практический тест. Для сравнения добавлены проверки, доступные в современных компиляторах С: fsanitize=address и fsanitize=undefined.

Для запуска теста используется сценарий benchmark.sh, находящийся в каталоге проекта.

Компилятор: gcc-6.3.0 -O3 -flto.

Размер, байтРазмер, отношениеВремя, секундВремя, отношение
Без проверок 161 776 1 0.27 1
Восток 219 128 1.35 0.34 1.26
asan undefined 1 284 392 7.93 0.42 1.56
asan address 566 520 3.5 0.74 2.74
asan addr+undef 3 006 456 18.58 0.90 3.33
Восток+addr+undef3 637 976 22.49 1.04 3.85

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