Чому в C ++ чому і як віртуальні функції повільніші?

Чи може хтось детально пояснити, як саме працює віртуальна таблиця та які покажчики пов’язані, коли викликаються віртуальні функції.

Якщо вони насправді повільніші, чи можете ви показати час, який віртуальна функція потребує на виконання, більше, ніж звичайні методи класу? Легко простежити, як / що відбувається, не бачачи якогось коду.

Віртуальні методи зазвичай реалізуються за допомогою так званих таблиць віртуальних методів (короткі vtable), в яких зберігаються покажчики функцій. Це додає непрямості до фактичного виклику (треба отримати адресу функції для виклику з vtable, а потім зателефонувати - на відміну від просто виклику його вперед). Звичайно, на це потрібно певний час і ще якийсь код.

Однак це не обов'язково є основною причиною повільності. Справжня проблема полягає в тому, що компілятор (як правило / зазвичай) не може знати, яка функція буде викликана. Таким чином, він не може вбудовувати його чи виконувати будь-які інші подібні оптимізації. Це одне може додати десяток безглуздих інструкцій (підготовка регістрів, виклик, потім відновлення стану) і може перешкоджати іншим, здавалося б, не пов'язаним оптимізаціям. Більше того, якщо ви розгалужуєтесь як божевільний, викликаючи безліч різних реалізацій, ви страждаєте одними і тими ж зверненнями, які ви будете страждати від розгалуження, як божевільні, іншими способами: кеш-пам'ять і передбачувач гілок вам не допоможуть, гілки займуть більше часу, ніж ідеально передбачувана відділення.

Великий, але : Ці хіти на виставу зазвичай занадто крихітні, щоб мати значення. Вони варто розглянути, якщо ви хочете створити високоефективний код і розглянути можливість додавання віртуальної функції, яка б викликалася з тривожною частотою. Тим НЕ менше, також мати на увазі , що заміна викликів віртуальних функцій з іншими засобами розгалуження ( if .. else, switch, покажчики на функції і т.д.) не вирішує основне питання - це дуже добре може бути повільніше. Проблема (якщо вона взагалі існує) полягає не у віртуальних функціях, а у (непотрібній) непрямості.

Редагувати: Різниця в інструкціях про дзвінки описана в інших відповідях. В основному, код для статичного ("нормального") дзвінка:

• Скопіюйте деякі регістри в стек, щоб дозволена функція використовувала ці регістри.
• Скопіюйте аргументи у заздалегідь задані місця, щоб викликана функція змогла їх знайти незалежно від місця її виклику.
• Натисніть зворотну адресу.
• Відділення / перехід до коду функції, який є адресою компіляції та, отже, компілятором / посилачем жорстко кодується у двійковій формі.
• Отримати повернене значення із заздалегідь визначеного місця та відновити регістри, які ми хочемо використовувати.

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

• Отримайте вказівник vtable, який вказує на масив функціональних покажчиків (адреси функцій), по одному для кожної віртуальної функції, від об'єкта.
• Отримайте потрібну адресу функції з vtable в регістр (індекс, де зберігається правильна адреса функції, визначається під час компіляції).
• Перейти до адреси в цьому реєстрі, а не переходити на жорстко кодовану адресу.

Що стосується гілок: гілка - це все, що переходить до іншої інструкції, а не просто дозволяти виконувати наступну інструкцію. Це включає if, switchчастини різних циклів, виклики функцій тощо, а іноді компілятор реалізує речі, які, здається, не розгалужуються таким чином, що насправді потребує гілки під кришкою. Див. Чому обробка відсортованого масиву швидша, ніж несортований масив? чому це може бути повільним, що робити процесори, щоб протистояти цьому сповільненню, і як це не все для лікування.

Ось кілька фактично розібраних кодів з виклику віртуальної функції та невіртуального виклику відповідно:

mov    -0x8(%rbp),%rax
mov    (%rax),%rax
mov    (%rax),%rax
callq  *%rax

callq  0x4007aa

Видно, що для віртуального дзвінка потрібні три додаткові інструкції для пошуку правильної адреси, тоді як адреса невіртуального виклику може бути зібрана в.

Однак зауважте, що більшу частину часу цей додатковий час пошуку можна вважати незначним. У ситуаціях, коли час пошуку був би значним, як у циклі, значення зазвичай може кешуватися, виконуючи перші три інструкції перед циклом.

Інша ситуація, коли час пошуку стає значущою, якщо у вас є колекція об'єктів і ви перебираєтеся через виклик віртуальної функції на кожному з них. Однак у цьому випадку вам знадобляться певні засоби для вибору функції, яку потрібно викликати в будь-якому випадку, і пошук віртуальної таблиці є настільки ж хорошим засобом, як і будь-який. Справді, так як віртуальні таблиці код пошуку настільки широко використовується вона в значній мірі оптимізований, тому намагається працювати навколо нього вручну має хороші шанси в результаті гіршій продуктивності.

Повільніше, ніж що ?

Віртуальні функції вирішують проблему, яку неможливо вирішити за допомогою прямих викликів функцій. Загалом ви можете порівняти лише дві програми, які обчислюють одне і те ж. "Цей відслідковувач променів швидше, ніж цей компілятор" не має сенсу, і цей принцип узагальнює навіть такі дрібні речі, як окремі функції або конструкції мови програмування.

Якщо ви не використовуєте віртуальну функцію для динамічного переключення на фрагмент коду на основі даних, наприклад типу об'єкта, тоді вам доведеться використовувати щось інше, наприклад, switchзаяву, щоб виконати те саме. Щось ще має свої накладні витрати, плюс наслідки для організації програми, які впливають на її ремонтопридатність та глобальну ефективність.

Зауважте, що в C ++ виклики віртуальних функцій не завжди є динамічними. Коли дзвінки здійснюються на об'єкті, точний тип якого відомий (тому що об'єкт не є вказівником чи посиланням, або тому, що його тип може інакше статично виводитися), то виклики - це лише звичайні виклики функцій учасників. Це не тільки означає, що немає накладних витрат, але й те, що ці дзвінки можна вказувати так само, як і звичайні дзвінки.

Іншими словами, ваш компілятор C ++ може працювати, коли віртуальні функції не потребують віртуальної розсилки, тому зазвичай немає причин турбуватися про їхню ефективність відносно невіртуальних функцій.

Нове: Також ми не повинні забувати спільні бібліотеки. Якщо ви використовуєте клас, який знаходиться у спільній бібліотеці, виклик звичайної функції учасника не буде просто приємною послідовністю інструкцій, як callq 0x4007aa. Він повинен пройти через кілька обручів, як-от опосередкування через "таблицю посилань на програму" чи якусь таку структуру. Тому опосередкована бібліотека може дещо (якщо не повністю) нівелювати різницю у вартості між (справді непрямим) віртуальним викликом та прямим викликом. Таким чином, міркування про компроміси віртуальних функцій повинні враховувати спосіб побудови програми: чи монолітний клас цільового об'єкта пов'язаний з програмою, яка здійснює виклик.

тому що віртуальний дзвінок еквівалентний

res_t (*foo)(arg_t);
foo = (obj->vtable[foo_offset]);
foo(obj,args)

де за допомогою невіртуальної функції компілятор може постійно складати перший рядок, це відновлення додавання і динамічний виклик, перетворений на просто статичний виклик

це також дозволяє вбудувати функцію (з усіма наслідками оптимізації)