Приводит ли более человеко-логический исходный код к созданию более оптимизированного скомпилированного кода?

Question

Я работаю над большим критичным к производительности проектом, который очень тяжелый для отрасли. В процессе разработки алгоритмов для этого продукта мой работодатель часто напоминает мне о написании кода, который более «логичен для человека» или написан так, чтобы более точно соответствовать тому, как мы логически мыслим.

Хотя это имеет смысл для меня с нескольких разных точек зрения (например, простота понимания / запоминания, сопровождение кода и т. Д.), Мне также интересно, можно ли когда-либо ожидать, что этот подход приведет к более оптимизированному скомпилированному выводу ,

Может ли это быть из-за того, что компиляторы написаны людьми, а оптимизаторы часто предназначены для распознавания знакомых блоков кода?

Я хотел бы услышать некоторые мысли о том, почему это не может быть / не так.

Answer 1

Рассмотрим два разных вида кода, код библиотеки и код приложения. Библиотечный код (например, библиотека строковых классов), вероятно, будет часто иметь счетчик программы, например:

while(some test){
  massage some data, while seldom calling sub-functions
}

Этот вид кода выиграет от оптимизации компилятора. (Поэтому, чтобы ответить на ваш вопрос, люди пишут такие тестовые функции, а разработчики компиляторов используют их в качестве тестовых случаев.)

С другой стороны, код приложения выглядит следующим образом:

if (some test){
  do a bunch of things, including many function calls
} else if (some other test){
  do a bunch of things, including many function calls
} else {
  do a bunch of things, including many function calls
}

В этом случае время, которое вы экономите с помощью прогнозирования ветвлений или циклического бритья, может составлять, например, 1 единицу времени, тогда как do a bunch of things... может тратить от 10 ^ 2 до 10 ^ 8 единиц времени с вводом или выводом , Так что выгода от оптимизации компилятора этого кода, как правило, полностью теряется в шуме.

Это не значит, что его нельзя оптимизировать. Просто компилятор не может этого сделать - это ваша работа.

Если вы хотите, чтобы последний вид кода выполнялся быстро, лучшим способом будет выяснить, какие строки кода находятся в стеке вызовов, и, если возможно, найти способ избежать их выполнения. ( Вот пример ускорения в 43 раза. )

Answer 2

Что такое «человеческая логика», вероятно, варьируется от человека к человеку.

Например, если я новичок, выполняющий задания в соответствии с письменными инструкциями, я (обычно) со временем выучу некоторые задания наизустьв то время как для других я вернусь к инструкциям просто потому, что задания выполняются недостаточно часто / слишком скучно или и то, и другое.Другие в той же ситуации могут или не могут функционировать аналогично, и не уверен, что задачи, которые они изучат, будут теми, которые я изучаю.

Для программирования это работает аналогично.Некоторые могут построить цикл одним способом и выполнить тест внутри него для удобства чтения, в то время как я мог бы сделать тест снаружи по соображениям производительности.Что более неправильно и что правильно?

Широко распространено мнение, что компиляторы что-то оптимизируют.Это правда, но, как я написал (радикально) в другом посте, применяется GIGO (Garbage In = Garbage Out).Компиляторы не работают в вакууме: при наличии набора правил они будут выполнять безопасную оптимизацию исходного кода в той мере, в какой их (конструкторы) воображение конструкторов и компетентность в оптимизации кода.Раздутый исходный код станет оптимизированным раздуванием машинного кода.Таким же образом обедненный и средний исходный код станет оптимизированным обедненным и средним машинным кодом.В критических местах можно подать исходный код компилятора, который он «чувствует» (ДА! У них действительно есть личности), абсолютно удобен для оптимизации, и полученный машинный код будет летать.

Мы все испытали плохую работупрограммного обеспечения.Если нам повезет, мы испытали программное обеспечение, которое работает невероятно хорошо.Один разработчик может научиться писать фрагмент кода, который работает хорошо за то же время, что и другой, пишет код, который работает плохо.