Когда речь заходит о структурном программировании, одним из аргументов противников того, чтобы кодировать исключительно структурно является вопрос производительности. На мой взгляд, структурный подход не может существенно понижать производительность, тем более при использовании оптимизирующих компиляторов. С другой стороны, большинство современных языков, используемых в производстве, не продвигают структурность, поэтому и их компиляторы не учитывают специфику подхода, что мешает использованию специальных оптимизаций. Так стоит ли волноваться по этому поводу? Для ответа на этот вопрос я написал небольшой тест, представляющий из себя несколько воплощений линейного поиска в трёхмерном массиве.
"Восток". Накладные расходы проверок.
Сообщения о трансляторе переехали в отдельный блог.
Сделал тест для измерения накладных расходов проверок корректности времени исполнения, которыми транслятор сопровождает основной код. Воплощены проверки: переполнения типа, выхода за границы массива, использования неинициализированных переменных, приведения базовой записи к расширенной, пользовательские 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+undef | 3 637 976 | 22.49 | 1.04 | 3.85 |
Проверки ещё несовершенны, поэтому можно ожидать некоторого увеличения накладных расходов по мере улучшения транслятора.