Майбутнє скриптів в Unity 3D

      Нещодавно ми написали статтю про підтримку WebGL в Unity . У ній ми коротко розповіли про те, як працюватимуть скрипти в WebGL з використанням нової технології IL2CPP. Однак IL2CPP — це щось набагато масштабніше, ніж просто нове рішення для скриптів в WebGL, це наша власна, високопродуктивна реалізація. Net Runtime, яка буде випущена на багатьох платформах.
 
Але перед зануренням у майбутнє варто поговорити про сьогодення.
 
 

Скрипти в Unity сьогодні

Ми використовуємо Mono WinRT для додатків Windows Store і Windows Phone) щоб привнести в Unity простоту використання C #, доступ до сторонніх бібліотекам і практично двійкове швидкодію. Але є кілька складнощів:
 
 - Швидкодія середовища виконання C # все ще поступається C / C + +
 - Останні і кращі можливості мов і середовища виконання. Net не підтримується версією Mono, використовуваної зараз в Unity
 - З приблизно 23 платформами і варіантами архітектури потрібно дуже багато зусиль на перенесення коду і підтримку його якості на однаковому рівні
 - Збірка сміття може викликати затримки при виконанні
 
 
 
Останні кілька років ми постійно думали про те, як впоратися з усім цим. Одночасно йшли дослідження в галузі підтримки скриптів для WebGL. У міру просування в обох напрямках вони злилися в один підхід.
 
Усвідомивши масштаб проблеми, ми почали експериментувати з різними шляхами її вирішення. Деякі з них були багатообіцяючими, деякі ні. Але в результаті ми знайшли новаторський шлях вирішення наших проблем.
 
Це IL2CPP.
 
 

IL2CPP: швидке і коротке введення

IL2CPP складається з двох частин: Ahead of Time (AOT) компілятора і віртуальної машини (VM)
 
Вони є нашою реалізацією Common Language Infrastructure , схожою з. Net і Mono. Вона сумісна з поточною реалізацією скриптів в Unity.
 
Її основна відмінність від поточної реалізації в тому, що IL2CPP компілятор перетворює збірки у вихідний код C + +. Потім він використовує стандартний компілятор C + + для даної платформи, щоб створити рідні двійкові файли.
 
Код виконується одночасно з додатковими службами (на кшталт збирача сміття, метаданих, специфічних для платформи ресурсів), які забезпечує IL2CCP VM.
 
 

Переваги IL2CPP

Давайте розглянемо кожну з вищезазначених складнощів і те, як як з нею справляється IL2CPP.
 
 

Продуктивність

У IL2CPP ми прагнемо поєднати простоту використання і швидкість написання коду зі продуктивністю C + +.
 
З ним ми можемо зберегти швидкість поточного процесу написання скриптів і доповнити її моментальним підвищенням продуктивності. Ми бачили 2-3-кратне збільшення швидкості виконання деяких наших тестів зі складними скриптами. Такий приріст продуктивності виникає з кількох причин:
 
 - Компілятори та компоновщики C + + дають нам велику кількість раніше недоступних методів оптимізації.
 - Ваш код піддається статичному аналізу і на швидкість і на розмір
 - Unity-орієнтовані оптимізації середовища виконання скриптів
 
І хоча робота над IL2CPP ще далека від завершення, цей ранній приріст продуктивності однозначно вказує на велике майбутнє нашого проекту.
  
 

Оновлення. Net

Ми дуже часто отримуємо запити на оновлення середовища виконання. В останні роки. Net дуже швидко розвивався, а Unity на даний момент підтримує тільки функціонал епохи. NET 2.0/3.5 як для компілятора C # так і для сторонніх бібліотек. Багато користувачів запитували доступ до нових можливостей як для свого коду так і для сторонніх бібліотек.
 
У міру дорослішання IL2CPP ми будемо оновлювати версії компілятора Mono C #, базових бібліотек класів і середовища виконання для редактора (редактор не переводитися на IL2CPP, щоб зберегти швидкість розробки скриптів). Поєднання цих двох процесів привнесе сучасну версію. Net в Unity.
 
Варто відзначити, що ми співпрацюємо з Microsoft , щоб гарантувати якість і стабільність при додаванні поточних і майбутніх можливостей. Net в Unity.
 
 

Переносимість та підтримка

Хоча це може здатися внутрішніми проблемами Unity, вони так само стосуються і вас. Віртуальна машина Mono містить величезну кількість коду, специфічного для конкретної платформи і архітектури. При перенесенні Unity на нову платформу ми витрачаємо дуже багато сил на перенесення і підтримку Mono VM для цієї платформи. Деякі особливості (і помилки) можуть існувати тільки на окремих платформах. Це зачіпає ті цінності, які намагається забезпечити для вас Unity — простоту перенесення контенту між платформами.
 
IL2CPP вирішує цю проблему декількома шляхами:
 
 - Код конвертується в C + +, а не специфічний для даної архітектури машинний код. Вартість перенесення і підтримки генерації коду для кожної конкретної архітектури помітно знижується
 - Розробка нових можливостей і виправлення помилок помітно прискорюються. Для нас дні колупання в архітектурно-специфічному коді замінюються хвилинами правки C + +. Нові можливості та виправлення помилок відразу доступні для всіх платформ. Нинішній варіант IL2CPP дуже швидко переноситься на нові платформи.
 
На додаток до цього, специфічні для платформи чи архітектури компілятори зазвичай оптимізуються набагато краще, ніж один-єдиний генератор коду. Це дозволить нам повторно використовувати всі ті зусилля, які пішли на розробку C + + компіляторів, які не переізобретая їх заново всередині компанії.
 
 

Збірка сміття

IL2CPP не прив'язаний до якогось конкретного збирачеві сміття, натомість він підключає їх через спеціальний API. Нинішній варіант IL2CPP використовує вдосконалену версію libgc , хоча ми розглядаємо різні варіанти. Одночасно з цим ми досліджуємо можливості скорочення тиску з боку GC за допомогою аналізу, виконуваного в компіляторі IL2CPP.
 
Хоча на даний момент нам нема чого більше розповісти, дослідження тривають. Ми знаємо, що це важливо для вас, так що продовжимо роботу і будемо інформувати вас про неї в майбутніх записах. У контексті збірки сміття варто зауважити, що незалежно від IL2CPP, в Unity 5 ви побачите набагато більше вільних від виділення API (allocation free API).
 
 

Чим не є IL2CPP

IL2CPP не є спробою відтворити всю середу. Net або Mono. Ми продовжимо використовувати компілятор C # з Mono (а в майбутньому можливо і Roslyn ). Ми продовжимо використовувати бібліотеки класів Mono. Усі наявні на даний момент можливості і сторонні бібліотеки, сумісні з Mono AOT будуть працювати і з IL2CPP. Ми збираємося замінити тільки Mono VM і AOT компілятор, продовжуючи використовувати чудовий проект Mono.
 
 

Коли я зможу спробувати IL2CPP?

Ми сподіваємося, що до даного моменту можливість спробувати IL2CPP хвилює вас так само сильно як і нас, і ви ставите питанням — коли ви зможете випробувати його особисто? Рання версія IL2CPP буде частиною підтримки WebGL в Unity 5.
 
Після WebGL ми продовжимо розробку IL2CPP для інших платформ. Насправді у нас вже є реалізації для цілого ряду підтримуваних нами платформ. Ми розраховуємо випустити як мінімум ще одну платформу цього року. На даний момент ми плануємо зробити iOS наступній платформою з підтримкою IL2CPP.
 
Заплановане оновлення середовища Mono відбудеться після того, як IL2CPP буде підтримуватися на більшій кількості платформ і трохи подорослішає.
 
Єдина платформа, яка ніколи не буде підтримувати IL2CPP — це WebPlayer, через обмеження, пов'язаних з безпекою. Як і було зазначено раніше, редактор продовжить працювати на Mono.
 
Ви можете побачити середовище виконання IL2CPP в дії прямо зараз. Дві демонстрації WebGL, які ми розміщували раніше, працюють саме на ньому.
 
 

Що далі?

Ми продовжуємо старанно працювати над IL2CPP: додаємо нові можливості, оптимізуємо генерацію коду, виправляємо помилки і додаємо підтримку нових платформ. Ми будемо публікувати більш докладні статті в міру просування нашої роботи і продовжимо обговорювати її з вами на форумах.
 
Команда скриптів Unity.
 
 Невелике доповнення з відповідей розробників на питання в англомовних коментарях і спеціальній темі на форумі Unity :
 
Термін «віртуальна машина» може бути трохи оманливим. Насправді не буде ніякої справжньої віртуальної машини, все буде в двійковому коді, але буде ряд функцій, доступних під час виконання і реалізують функціональність, необхідну керованого коду, начебто системних служб або збірки сміття, які ми і називаємо в даному випадку віртуальною машиною.
 
***
 
Написання скриптів на C + + не є офіційною метою IL2CPP і найближчим часом нічого подібного не з'явиться, хоча це і може статися коли-небудь в майбутньому як побічний наслідок прийнятих рішень.
 
***
 
Вихідні коди поки не будуть відкриватися, ми довго обговорювали подібну можливість і поки не прийняли подібного рішення. У відкритті початкових кодів є як переваги для нас, так і недоліки, так що для прийняття такого серйозного рішення мають бути вагомі причини.
 
***
 
Обмеження на динамічну генерацію коду повністю аналогічні обмеженням в Mono AoT , сумісний з ним код буде працювати з IL2CPP. Reflection буде працювати. Речі начебто System.Reflection.Emit немає. Ніякої динамічної генерації коду під час виконання.
 
***
 
iOS буде першою платформою з підтримкою IL2CPP тому, що там вже використовується AoT, так що перехід буде більш плавним. Потім буде підтримка інших платформ включаючи PC, Mac і Linux.
 
***
 
Через AoT і обмежень LGPL ми не можемо використовувати Mono на iOS, що не дає нам оновити версію Mono для редактора та інших платформ
 
***
 
Я не юрист. Точно не юрист. Але з приводу юридичних обмежень пов'язаних з Mono і LGPL можу сказати наступне. Проблема не в компонуванні, можна зробити компоновку забезпечивши користувачів додатковими даними (object files). Проблема в тому, що обмеження торкнуться всіх наших клієнтів, що роблять ігри та програми на Unity. Вони теж потраплять під обмеження LGPL будуть змушені надавати обьектно файли усім своїм клієнтам. Ще раз зазначу що я не юрист, це не є офіційною позицією Unity і всього лише відображає моє розуміння ситуації як програміста і все в такому дусі.
 
***
 
З Mono нам доводилося тримати команду фахівців для кожної нової платформи. Якщо Mono не підтримував цю платформу, нам доводилося виконувати просто величезний обсяг роботи, тому що по суті справи нам доводилося з нуля писати свої власні кошти JIT для кожної платформи. Для деяких платформ ми витрачали на перенесення Mono в три рази більше сил, ніж на всю іншу роботу. З IL2CPP замість написання коштів JIT ми зможемо просто використовувати існуючий компілятор C + +, це набагато простіше.
 
***
 
Я працював над Mono 9 років і можу з упевненістю сказати, що для перенесення Mono на нову платформу потрібно приблизно рік роботи справжнього експерта і по Mono і по даній платформі, якщо ви взагалі зможете такого знайти і утримати його для додавання всіх можливостей, що вимагають реалізації, специфічною для даної платформи. Складно описати словами, як раді наші фахівці по платформах нової технології. Вони торгуються за право генерувати, налагоджувати і підтримувати код збірок в С + +. У записі повинні були згадати, що портування тепер займає дні, замість місяців і років. Як мені здається багато рухаються в цьому напрямку. Ми почали роботу до того, як Microsoft анонсувала. Net Native, але це тільки підтверджує вірність обраної нами стратегії. Трохи обмеживши можливості під час виконання (ніякої динамічної генерації) ви отримуєте масу переваг. Ніхто не змушує вас використовувати це для самостійних додатків на PC. Вони отримають оновлену версію Mono разом з редактором, як тільки IL2CPP стане досить стабільним на платформах з AoT. Головна мета IL2CPP — це ті платформи, де AoT дійсно має сенс.
 
***
 
Ми розуміємо, що зовсім не скрипти зазвичай є вузьким місцем в плані продуктивності, зазвичай проблеми виникають у разі неправильних або поганих скриптів. Нам ще ніхто не скаржився не надто повільне виконання методів C #. Збірка сміття окрема розмова, залишимо його на потім. Але люди люблять обговорювати продуктивність. Як мені здається IL2CPP в багатьох випадках зробить осмисленим використання скриптів для тих речей, які раніше вважалися занадто важкими і виконувалися в C + +. ШІ, фізика і все в такому дусі прискориться найсильніше і з'являться нові, цікаві можливості.
 
Особисто я можу відразу згадати наступні оптимізації
 - Відмова від перевірки кордонів масивів
 - Усунення підтримки винятків (навантаження від них розрізняється залежно від платформи)
 - Усунення статичної ініціалізації, зараз при кожному створенні екземпляра або зверненні до статичного методу / властивості потрібно потрібно перевірити, що для всіх типів зі статичним конструктором він був виконаний
 - Підтримка SIMD
 - Оптимізація взаємодії між двійковим і керованим кодом. Ми постараємося виконати її по максимуму і швидше за все дамо вам можливість посилювати її, добровільно погодившись на додаткові обмеження
 
Все це випадковий список того, що згадалося мені просто зараз. Пізніше ми опублікуємо більш детальну інформацію.
 
***
 
 
Unity не підтримує можливість створення модов до гри і не підтримує можливість створення патчів. Зараз у нас є сторонні рішення, що дозволяють нам довантажувати моди з додаткових. Net dll (правда патчі так все одно не зробиш). Але з IL2CPP ми не зможемо робити і це.
 
На Mac / Linux / Windows і в редакторі ми підтримуватимемо Mono як один з варіантів ще дуже і дуже довго і через якийсь час оновимо його на нову версію. Так що якщо ви робите гру з підтримкою модов для цих платформ, то зможете і далі використовувати Mono. Ніяких проблем. Перехресна публікація для Mac / Linux / Win так само продовжить працювати без змін.
 
На інших платформах на зразок iOS і приставок Unity вже використовує Mono AoT, таким чином завантаження dll і так неможлива і ніколи не стане можливою через обмеження самих платформ. Тут ви нічого не втратите.
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.