Константы и оптимизация компилятора в C++

махание рукой начинается

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

конец махать рукой

Он не оптимизирует функцию, объявленную const.

Он может оптимизировать функции, которые вызов объявлены как const.

void someType::somefunc();

void MyFunc()
{
    someType A(4);   // 
    Fling(A.m_val);
    A.someFunc();
    Flong(A.m_val);
}

Здесь для вызова Fling в регистр ЦП необходимо загрузить valud A.m_val. Если someFunc () не является константой, значение необходимо будет перезагрузить перед вызовом Flong (). Если someFunc имеет значение const, мы можем вызвать Flong со значением, которое все еще находится в регистре.

Основная причина использования методы в качестве константы - это правильность константы, а не возможная оптимизация компиляции самого метода.

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

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

К тому же компилятор не может полагаться на то, что вы говорите правду - вы можете отбросить константу внутри библиотечной функции, о которой он не знает.

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

Я был бы удивлен, если бы оптимизатор действительно вложил много средств в объявление const. Существует много кода, который в конечном итоге отбрасывает константу, это был бы очень безрассудный оптимизатор, который полагался на объявление программиста, чтобы предположить, когда состояние может измениться.

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

Херб Саттер в Статья GotW # 81 очень хорошо объясняет, почему компилятор не может ничего оптимизировать при передаче параметров по ссылке const или при объявлении возвращаемого значения const. Причина в том, что компилятор не может быть уверен, что объект, на который ссылается, не будет изменен, даже если он объявлен как const: можно использовать const_cast, или какой-либо другой код может иметь неконстантную ссылку на тот же объект.

Однако, цитируя статью Херба Саттера:

There is [only] one case where saying "const" can really mean something, and that is when objects are made const at the point they are defined. In that case, the compiler can often successfully put such "really const" objects into read-only memory[...].

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

Наиболее очевидный момент, когда const является прямой оптимизацией, - это передача аргументов функции. Часто важно убедиться, что функция не изменяет данные, поэтому единственными реальными вариантами подписи функции являются следующие:

void f(Type dont_modify); // or
void f(Type const& dont_modify);

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

/ EDIT: на самом деле хороший компилятор может анализировать поток управления функцией, определять, что он не изменяет аргумент, и сам выполнять оптимизацию (передавая ссылку, а не копию). const здесь просто помощник для компилятора. Однако, поскольку C++ имеет довольно сложную семантику и такой анализ потока управления может быть очень дорогостоящим для больших функций, нам, вероятно, не следует полагаться в этом на компиляторы. Есть ли у кого-нибудь данные, подтверждающие мою неправоту?

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

Этот код,

class Test
{
public:
  Test (int value) : m_value (value)
  {
  }

  void SetValue (int value) const
  {
    const_cast <Test&>(*this).MySetValue (value);
  }

  int Value () const
  {
    return m_value;
  }

private:
  void MySetValue (int value)
  {
    m_value = value;
  }

  int
    m_value;
};

void modify (const Test &test, int value) 
{
  test.SetValue (value);
}

void main ()
{
  const Test
    test (100);

  cout << test.Value () << endl;
  modify (test, 50);
  cout << test.Value () << endl;
}

выходы:

100
50

что означает, что объявленный объект const был изменен в функции-члене const. Наличие const_cast (и ключевого слова mutable) в языке C++ означает, что ключевое слово const не может помочь компилятору в создании оптимизированного кода. И, как я отмечал в своих предыдущих постах, это может даже дать неожиданные результаты.

Как общее правило:

const != optimisation

Фактически, это законный модификатор C++:

volatile const

Не обращаем внимания на методы и будем смотреть только на константные объекты; здесь у компилятора гораздо больше возможностей для оптимизации. Если объект объявлен как const, то (ISO / IEC 14882: 2003 7.1.5.1 (4)):

Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.

Не обращаем внимания на объекты, которые могут иметь изменяемые члены - компилятор может предположить, что объект не будет изменен, поэтому он может произвести значительную оптимизацию. Эти оптимизации могут включать в себя такие вещи, как:

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

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

На практике я не думаю, что существуют компиляторы, которые выполняют какую-либо значительную оптимизацию для всех видов константных объектов. но для объектов, которые являются примитивными типами (целые числа, символы и т. д.), я думаю, что компиляторы могут быть довольно агрессивными в оптимизации использование этих предметов.

const помогает компиляторам оптимизировать в основном потому, что позволяет писать оптимизируемый код. Разве что кинуть const_cast.

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

Есть только один вид кода, в котором имеет значение оптимизация компилятора, это код, который

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

Если остальные 99% кода оптимизированы до N-й степени, это не будет иметь большого значения, потому что это имеет значение только в коде, где счетчик программы фактически тратит время (что вы можете найти путем выборки).

Константа-правильность также полезна как документация. Если функция или параметр указан как const, мне не нужно беспокоиться о том, что значение изменится из-под моего кода (если только кто-то другой в команде не очень капризничает). Я не уверен, что оно того стоило бы, если бы оно не было встроено в библиотеку.