Скорость виртуального вызова в C# vs C++

Question

Кажется, я кое-что вспомнил, что стоимость виртуального вызова в C# не такая высокая, относительно говоря, как на C++. Это правда? Если да - почему?

Answer 1

Виртуальный вызов C# должен проверить, что «это» является нулевым, а виртуальный вызов C++ - нет. Поэтому я вообще не вижу, почему виртуальные вызовы C# будут быстрее. В особых случаях компилятор C# (или JIT-компилятор) может иметь возможность встроить виртуальный вызов лучше, чем компилятор C++, поскольку компилятор C# имеет доступ к лучшей информации о типе. Команда метода вызова может иногда быть медленнее на C++, так как C# JIT может использовать более быструю инструкцию, которая справляется только с небольшим смещением, поскольку она знает больше о макете памяти выполнения и модели процессора, а затем компиляторе C++.

Однако мы говорим о горстке инструкции процессора в большинстве случаев. На модемном суперскалярном процессоре очень возможно, что команда «null check» запускается одновременно с «методом вызова» и, следовательно, не требует времени.

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

Тот факт, что код C# использует еще несколько инструкций, конечно, уменьшит количество кода, которое может поместиться в кеш, эффект этого невозможно предсказать.

(Если C++ класс использует несколько присущность то стоимость больше, из-за того, чтобы залатать «этот» указатель. Точно так же интерфейсы в C# добавить еще один уровень перенаправления.)

Answer 2

Стоимость виртуального вызова в C++ - это вызов функции через указатель (vtbl). Я сомневаюсь, что C# можно сделать один быстрее и по-прежнему быть в состоянии определить тип объекта во время выполнения ...

Edit: Как Пит Kirkham отметил, хороший JIT может быть в состоянии встраивать в C# вызов, избегая конвейер; что-то большинство компиляторов C++ не могут (пока). С другой стороны, Ян Ринроуз упомянул о влиянии на использование кеша. Добавив к этому, что JIT сам работает, и (строго лично), я бы не стал беспокоиться, если профилирование на целевой машине при реалистичных рабочих нагрузках оказалось доказанным тем, кто быстрее, чем другой. В лучшем случае это микро-оптимизация.

Answer 3

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

Но это по существу теоретически, и я бы не стал делать ставку на него!

Answer 4

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

Answer 5

Для JIT-компилированных языков (я не знаю, делает ли это CLR или нет, Sun JVM делает это), это общая оптимизация для преобразования виртуального вызова, который имеет только две или три реализации в последовательность тестов по типу и прямые или встроенные вызовы.

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

В предельном случае, когда существует только одна реализация виртуального вызова, а тело вызова достаточно мало, виртуальный вызов сводится к чисто inline code. Этот метод использовался в среде исполнения Self language, от которой развилась JVM.

Большинство компиляторов C++ не выполняют весь программный анализ, необходимый для выполнения этой оптимизации, но такие проекты, как LLVM, рассматривают такие оптимизационные программы, как эта.

Answer 6

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

Answer 7

C# flattens vtable и встроенные вызовы предков, поэтому вы не связываете иерархию наследования, чтобы разрешить что-либо.

Answer 8

Это может быть не совсем ответ на ваш вопрос, но хотя .NET JIT оптимизирует виртуальные вызовы, как и все ранее сказанные, profile-guided optimization в Visual Studio 2005 и 2008 делает предположение о виртуальном вызове, вставляя прямой вызов наиболее вероятному целевому функции, вставляя вызов, поэтому вес может быть одинаковым.

Answer 9

Оригинальный вопрос говорит:

Кажется, я припоминаю где-то читал, что стоимость виртуального вызова в C# не так высока, относительно говоря, как и в C++.

Обратите внимание на акцент. Другими словами, этот вопрос может быть перефразировать:

Кажется, я припоминаю где-то читал , что в C#, виртуальные и не виртуальные звонки одинаково медленно, в то время как в C++ виртуальный вызов медленнее, чем не виртуальный вызов ...

Таким образом, вопросник не утверждает, что C# быстрее, чем C++ при любых обстоятельствах.

Возможно, бесполезная утечка, но это вызвало мое любопытство относительно C++ с/clr: чистым, без использования расширений C++/CLI. Компилятор создает IL, который преобразуется в собственный код JIT, хотя он является чистым C++. Итак, здесь у нас есть способ увидеть, что делает стандартная реализация C++, если она работает на той же платформе, что и C#.

С невиртуальной методой:

struct Plain 
{ 
    void Bar() { System::Console::WriteLine("hi"); } 
}; 

Этого код:

Plain *p = new Plain(); 
p->Bar(); 

... заставляет call опкода, издаваемым с конкретным именем методы, передавая панель неявного аргумента this ,

call void <Module>::Plain.Bar(valuetype Plain*) 

сравнение иерархия наследования:

struct Base 
{ 
    virtual void Bar() = 0; 
}; 

struct Derived : Base 
{ 
    void Bar() { System::Console::WriteLine("hi"); } 
}; 

Теперь, если мы делаем:

Base *b = new Derived(); 
b->Bar(); 

Это излучает calli опкода вместо, который подскакивает к вычисленному адресу - так что есть много от IL до вызова. Повернув его обратно в C# мы можем увидеть, что происходит:

**(*((int*) b))(b); 

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

Мы можем настроить виртуальный пример использования C++/CLI расширения:

ref struct Base 
{ 
    virtual void Bar() = 0; 
}; 

ref struct Derived : Base 
{ 
    virtual void Bar() override { System::Console::WriteLine("hi"); } 
}; 

Base ^b = gcnew Derived(); 
b->Bar(); 

Это производит callvirt опкод, точно так, как это было бы в C#:

callvirt instance void Base::Bar() 

Так при компиляции для нацеливания CLR, текущий компилятор Microsoft C++ не имеет тех же возможностей для оптимизации, что и C# при использовании стандартных функций каждого языка; для стандартной иерархии классов C++ компилятор C++ генерирует код, который содержит жестко закодированную логику для перемещения vtable, тогда как для класса ref он оставляет его в JIT для определения оптимальной реализации.