Чому можна взагалі використовувати модифікатор параметра “in” у C #?

Отже, я (думаю) розумію, що inробить модифікатор параметрів. Але те, що воно робить, видається цілком зайвим.

Зазвичай я вважаю, що єдиною причиною використання a refє модифікація викличної змінної, що явно заборонено in. Тож передача за inпосиланням представляється логічно рівнозначною передачі за значенням.

Чи є якась перевага у виконанні? Я вважав, що з внутрішньої сторони речей refпараметр повинен принаймні копіювати фізичну адресу змінної, яка повинна бути такого самого розміру, як будь-яке типове посилання на об’єкт.

Тоді, чи є перевага просто у більших структурах, чи існує якась закулісна оптимізація компілятора, яка робить її привабливою деінде? Якщо остання, чому б мені не зробити кожен параметр an in?

in нещодавно був представлений мовою C #.

inнасправді є ref readonly. Взагалі кажучи, існує лише один варіант використання, який inможе бути корисним: високопродуктивні програми, що працюють з великою кількістю великих readonly struct.

Припускаючи, що у вас є:

readonly struct VeryLarge
{
    public readonly long Value1;   
    public readonly long Value2;

    public long Compute() { }
    // etc
}

і

void Process(in VeryLarge value) { }

У цьому випадку VeryLargeструктура буде передана за посиланням без створення захисних копій при використанні цієї структури в Processметоді (наприклад, при виклику value.Compute()), а незмінність структури забезпечується компілятором.

Зверніть увагу, що передача непрочитаного лише structз inмодифікатором призведе до того, що компілятор створить захисну копію під час виклику методів struct та доступу до властивостей у Processнаведеному вище методі, що негативно вплине на продуктивність!

Є справді хороший запис у блозі MSDN, який я рекомендую уважно прочитати.

Якщо ви хочете отримати більше історичної inдовідки про -представлення, ви можете прочитати це обговорення у сховищі GitHub мови C #.

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

передача за inпосиланням здається логічно рівнозначною передачі за значенням.

Правильно.

Чи є якась перевага у виконанні?

Так.

Я вважав, що з внутрішньої сторони речей refпараметр повинен принаймні копіювати фізичну адресу змінної, яка повинна бути такого самого розміру, як будь-яке типове посилання на об’єкт.

Немає вимоги, щоб посилання на об'єкт і посилання на змінну мали однаковий розмір, і немає вимоги, щоб будь-який з них був розміром машинного слова, але так, на практиці обидва це 32 біти на 32 розрядні машини та 64 біти на 64-розрядних машинах.

Мені незрозуміло, яке відношення до вас має "фізична адреса". У Windows ми використовуємо віртуальні адреси , а не фізичні адреси в коді користувацького режиму. За яких можливих обставин ви могли б уявити, що фізична адреса має значення у програмі на C #, мені цікаво знати.

Також не вимагається, щоб будь-яке посилання було реалізоване як віртуальна адреса сховища. Посилання можуть бути непрозорими дескрипторами таблиць GC у відповідній реалізації специфікації CLI.

чи перевага лише у більших конструкціях?

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

Зауважте, що немає жодної гарантії, що inробить будь-яку програму насправді швидшою, і вона може робити програми повільнішими. На всі питання щодо результативності слід відповісти емпіричним дослідженням . Дуже мало оптимізацій, які завжди є перемогами ; це не оптимізація "завжди перемагай".

чи є якась закулісна оптимізація компілятора, яка робить її привабливою в іншому місці?

Компілятору та середовищу виконання дозволено робити будь-яку оптимізацію, яку вони обрали, якщо це не порушує правила специфікації C #. Наскільки мені відомо, ще не така оптимізація inпараметрів, але це не виключає такої оптимізації в майбутньому.

чому б мені не зробити кожен параметр вхідним?

Ну, припустимо, ви зробили intпараметр замість in intпараметра. Які витрати покладаються?

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

Припустимо, це a, doubleі ви змінили його на an in double. Знову ж таки, тепер змінну неможливо зареєструвати у високоефективному регістрі з плаваючою комою. Це не тільки впливає на продуктивність , але і може змінити поведінку програми! C # дозволено робити арифметику з плаваючою системою з точністю вище 64-бітової, і зазвичай це робиться лише за умови, що плаваючі можна зареєструвати.

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

Є. При пропущенні struct, то inключове слово дозволяє оптимізувати , де компілятор потрібно тільки передати покажчик, без ризику методу зміни змісту. Останнє є критичним - воно дозволяє уникнути операції копіювання. Для великих конструкцій це може змінити світ.

Це робиться завдяки підходу функціонального програмування. Одним з головних принципів є те, що функція не повинна мати побічних ефектів, а це означає, що вона не повинна змінювати значення параметрів і повинна повертати деяке значення. У C # не було можливості передати структури (і тип значення), не скопіювавши лише посилання, що дозволяє змінювати значення. У swift існує хакерський алгоритм, який копіює struct (їх колекції є структурою BTW) до тих пір, поки метод починає змінювати свої значення. Люди, які швидко використовують, не всі знають про копіювання. Це приємна функція c #, оскільки вона ефективна і явна. Якщо ви подивитесь, що новогоВи побачите, що все більше і більше матеріалів робиться навколо структур і масивів у стеку. І в заяві просто необхідні ці особливості. Існують обмеження, згадані в інших відповідях, але це не так важливо для розуміння того, куди прямує .net.

в ній читається лише посилання на c # 7.2

це означає, що ви не передаєте цілий об'єкт у функціональний стек, подібно до випадку ref, ви передаєте лише посилання на структуру

але спроба змінити значення об'єкта видає помилку компілятора.

Так, це дозволить вам оптимізувати роботу коду, якщо ви використовуєте великі структури.