Действительно ли можно ли кэшировать поиск виртуальной функции в C++?

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

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

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

Вы не можете использовать указатель метода, потому что указатели на функции членов не считаются ковариантными типами возврата. См. Пример ниже:

#include <iostream>

struct base;
struct der;

typedef void(base::*pt2base)();
typedef void(der::*pt2der)();

struct base {
    virtual pt2base method() = 0;
    virtual void testmethod() = 0;
    virtual ~base() {}
};

struct der : base {
    void testmethod() {
        std::cout << "Hello from der" << std::endl;
    }
    pt2der method() { **// this is invalid because pt2der isn't a covariant of pt2base**
        return &der::testmethod;
    }
};

Другой вариант будет иметь метод, заявленный метод PT2Base () , но затем возвращение будет недействительным, потому что FER :: TESTMethod не имеет значения PT2Base.

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

Вызов виртуальной функции обходится мне в два раза дороже: Стабильный поиск и вызов функции.

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

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

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

Не могли бы вы использовать указатель метода?

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

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

Я проверил сообщество Wiki, чтобы представить больше обсуждений.

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

Вот модель случая полиморфизма выполнения:

struct Base {
  virtual void doit(int&)=0;
};

struct Foo : public Base {
  virtual void doit(int& n) {--n;}
};

struct Bar : public Base {
  virtual void doit(int& n) {++n;}
};

void work(Base* it,int& n) {
  for (unsigned int i=0;i<4000000000u;i++) it->doit(n);
}

int main(int argc,char**) {
  int n=0;

  if (argc>1)
    work(new Foo,n);
  else
    work(new Bar,n);

  return n;
}

Это занимает ~ 14, чтобы выполнить в My Core2, скомпилированном с GCC 4.3.2 (32-битный Debian), -O3 .

Теперь предположим, что мы заменяем версию «Работа» с помощью шаблонной версии (на шаблонном виде на бетонном типе, над которым он будет работать):

template <typename T> void work(T* it,int& n) {
  for (unsigned int i=0;i<4000000000u;i++) it->T::doit(n);
}

Main на самом деле не нужно обновлять, но отметить, что 2 Вызывы на работу теперь вызывают создания и вызовы двух различных и типовых функций (CF одна полиморфная функция ранее).

Эй, Presto работает в 0,001 человека. Не плохо ускоряется фактор для двух линий! Тем не менее, обратите внимание, что массивная скорость вверх полностью связана с компилятором, после возможности полиморфизма времени выполнения в работе работают функции, просто оптимизируя петлю и компиляцию результата непосредственно в код. Но это на самом деле делает важным моментом: в моем опыте, основным природом от использования такого рода трюк приходит от возможностей для улучшения встроения и оптимизации, они позволяют компилятору, когда генерируется менее полиморфная, более конкретная функция, не Из простого удаления подражания на величину (которое действительно очень дешево).

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

Вы можете найти Этот этот связанный вопрос тоже интересно.