Есть ли компиляторы, способные предложить оптимизацию, которая обязательно потребует одобрения программиста?

Question

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

Существуют некоторые потенциальные оптимизации, которые отклоняются компиляторами напрямую, потому что они могут не быть семантически эквивалентными.

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

Ошибки, предупреждения и ... предложения?

Компиляторы уже делают что-то похожее с «предупреждениями» в том смысле, что они объединяются во время каждой компиляции и остаются там навсегда в списке, пока вы не обратитесь к ним для удовлетворения компиляторов. Почему бы не иметь раздел «Предложения» или «Предлагаемые оптимизации», который работает аналогичным образом и потенциально может повысить производительность вашего приложения?

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

Оптимизация порядка операндов логических выражений

Рассмотрим «Оптимизация короткозамкнутых логических выражений» . Поскольку порядок операндов влияет на то, какой операнд может быть «замкнут» (т. Е. Не вызываться), порядок операндов в простых булевых выражениях (т. Е. A && B && C) является чем-то, что (я думаю) не затрагивается компилятором чтобы избежать введения неизвестных побочных эффектов, если какой-либо операнд имеет побочные эффекты.

Учтите это:

char c = reader.ReadChar(); //Stream bs; const string NEWLINE;
while (!IsStringPresent( c, bs, NEWLINE ) && c != ',')

Поскольку сравнение символа (быстрее / менее сложное), оно должно стоять на первом месте в выражении, чтобы логика короткого замыкания могла избежать вызова IsStringPresent при обнаружении запятой. Также верно и то, что в этом случае запятые (много на строку) встречаются чаще, чем новые строки.

char c = reader.ReadChar(); //Stream bs; const string NEWLINE;
if (c != ',' && !IsStringPresent( c, bs, NEWLINE )) //faster for short-circuit; plus ',' is encountered more often than newline

Краткое описание

Объективно, оптимальный порядок операндов может быть определен для любого выражения «A && B» на основе «Частота, которая A ложна против B, чтобы вызвать короткое замыкание» и «Стоимость вычисления A против B, благоприятствующая короткому замыканию» из более дорогого ". Если компилятор может определить приблизительные значения одного из них во время компиляции, во время выполнения или обоих, тогда он может определить, что конкретное выражение может быть неоптимальным, и он может создать предлагаемое изменение для реализации программистом. .

Какие-нибудь компиляторы делают что-нибудь подобное сегодня? Если нет, то почему?

Answer 1

Мой ответ «вероятно», но «это то, что мы действительно хотим сделать?»

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

Моя мысль, однако, больше похожа на это: «Привет, программист, если бы мы могли это сделать, мы получили бы гораздо более быстрый код, однако семантика была бы другой! Нам пришлось бы усилить предварительное условие этой функции, чтобы выполнить эту оптимизацию. Это нормально?»

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

Answer 2

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

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

Изменение порядка следования (в упомянутом вами примере) ограничено стандартами C, C ++, поскольку они могут изменить семантику программы. В тех случаях, когда побочные эффекты от операций отсутствуют, их можно переупорядочить, и компиляторы делают это во время планирования инструкций (при -O2 в clang ++ и g ++), но я не уверен, сколько других компиляторов делают это.

Answer 3

Мое мнение таково, что разрешение оптимизатору закорачивать вызов функции только потому, что программист считает, что все будет в порядке, - это рецепт для выявления неисправимых ошибок.Это спрашивает во время каждой компиляции?Я не знаю;просто звучит так, как будто было бы много проблем с чем-то вроде этого.