Майбутнє WinRT або Going Native 2.0

Alexandre Mutel – творець самої швидкої і найповнішою. ​​NET обгортки для DirectX, єдиною, що підтримує Windows 8 Metro, працює R & D розробником ігрового движка в SiliconStudio, учасник французької демо-групи FRequency.

Останнім часом ми чуємо багато галасу про повернення ідеї “Going Native” після ери керованих мов, таких як Java і. NET. У минулому році, коли WinRT був тільки представлений, почали з’являтися недалекі коментарі, які стверджували, що що. NET помер, а С + + повертається у всій своїй красі – істинний і єдино вірний спосіб для розробки додатків, в той час, як JIT починає все частіше з’являтися в світі скриптових мов (JavaScript активніше всіх використовує переваги JIT). Будь код так чи інакше стане нативним перед виконанням – різниця лише в довжині шляху, по якому він пройде, щоб стати нативним, і наскільки оптимізованим він буде. Значення слова “native” трохи змінилося і стало нерозривно пов’язане зі словом “продуктивність”. Навіть будучи сильним пропагандистом керованого мови [C #], його продуктивність насправді нижче добре написаного С + + додатки. Виходить, ми повинні просто прийняти цей факт і повернутися до C + +, коли такі штуки як WinRT будуть для нас основою межязикового взаємодії? По правді кажучи, я б хотів, щоб. NET помер, і цей пост про те, чому і навіщо.

Ера керованих мов


Давайте переглянемо недавню історію розробки на керованих мовах і відзначимо поточні проблеми. Пам’ятаєте слоган Java? “Write once runs everywhere”. Це було представлення нової парадигми, коли повністю “Безпечний” мову, заснований на віртуальній машині, пов’язаний з багатим набором API, надасть можливість з легкістю розробляти додатки під будь-яку ОС і платформу. Це був початок ери керованих мов. У той час як Java була досить успішно прийнята в різних галузях розробки, вона також була відкинута багатомі розробниками, які були в курсі особливостей управління пам’яті, недостатньо оптимізованого JIT (хоча з тих пір все значно покращився), величезної кількості поганих архітектурних рішень, на кшталт відсутності підтримки структур, прямого доступу до пам’яті, а виклики нативного коду через JNI були надзвичайно неефективними і трудомісткими (і навітьнедавновони розглядали можливість прибрати всі нативні типи об’єктів та сделть всі object – що за жахлива ідея!).

Також Java не змогла виконати обіцянку, дану в самому слогані – насправді неможливо охопити єдиним API усі можливості кожної платформи, що призвело до таких речей, як Swing – м’яко кажучи не самий оптимальний UI фреймворк. Також, спочатку Java була розроблена в розрахунку на єдиний мову програмування, хоча багато хто побачив в JIT і байткод можливість портувати скриптові мови на Java JVM.

На початку ери керованих мов Microsoft намагалася увійти на ринок Java з власними розширеннями для мови (про закінчення цієї історії знають всі) і в підсумку обзавелася власною платформою для керованих мов, яка в деяких аспектах була краще спроектована і скомпонована: починаючи з байткод, ключового слова unsafe, виклику нативного коду, легковагої але дуже ефективного JIT і NGEN, що швидко розвивається мови C #, C + + / CLI і т. д. Спочатку враховуючи межязиковое взаємодія і без тягаря слогану Java (хоча Silverlight на MacOS або Moonlight були непоганими спробами).

Обидві платформи використовували схожий монолітний стек: метадані, байткод, JIT і збирач сміття – все це тісно пов’язано. Відповідно, з продуктивністю були схожі проблеми: JIT увазі затримку при запуску, а виконання коду не таке швидке, як мало б бути. Основні причини:



Але навіть з такою недостатньою продуктивністю, керована екосистема з універсальним фреймворком – це король продуктивності і межязикового взаємодії, з гідною загальною продуктивністю для всіх підтримуваних мов. Апогеєм ери керованих мов був імовірно запуск WindowsPhone і VisualStudio 2010 (яка використовувала WPF для рендеринга інтерфейсу, хоча сам WPF працював поверх пристойного кількості нативного коду). Керовані мови були єдиним дозволеним способом розробляти додатки в той час. Це було не найкраще, що могло трапитися, беручи до уваги довгий список недозволених проблем з продуктивністю. NET, досить довгий, щоб стимулювати “нативних розробників” завдати удар у відповідь, і вони мали на це повне право.

Так вийшло, що це означає в якомусь сенсі відмова від. NET. Я не так багато знаю про внутрішню кухню Microsoft, але судячи з частим повідомленнями, там спостерігається сильне протистояння між підрозділами. Добре це чи погано, але для. NET в останні роки складається враження, що у Microsoft закінчується запал (наприклад, немає практично ніяких значних поліпшень в JIT / NGEN, безліч невирішених запитів на поліпшення продуктивності, включаючи такі речі, як SIMD, яких розробники чекають вже дуже довго). І мені здається, що всі ці зміни можливі тільки в тому випадку, якщо. NET буде глобальною стратегією і при сильній підтримці та участі всіх підрозділів.

У той же час, Google почав просувати свою технологію NativeClient, що дозволяє запускати нативний код в пісочниці прямо з браузера. У минулому році, слідуючи тренду “Going Native”, Microsoft оголосила, що навіть HTML5, розроблений для наступного IE, буде нативним! Sic.

В “Reader Q&A: When will better JITs save managed code?“Herb Sutter, один з євангелістів” Going Native “, наводить деякі цікаві доводи про те, що філософія” Going Native “думає про JIT (“Can JITs be faster?“Відповідь пост Miguel de Icaza) з безліччю неточних фактів, але давайте просто розглянемо ключовий: навіть якщо JIT в майбутньому стане краще, керовані язики вже зробили вибір між продуктивністю і безпекою на користь безпеки. Тим самим для них уже замовлений шлях у вищу лігу.

І в цей момент з’являється WinRT, який трохи згладжує гострі кути. Використовуючи частина філософії. NET (метадані і деякі загальні типи, такі як рядки і масиви) та стару добру модель COM (як загальний знаменатіль для нативного межязикового взаємодії), WinRT намагається вирішити проблеми взаємодії мов за межами світу CLR (що означає відсутність втрат продуктивності у C + +) і надати більш сучасне API для ОС. Чи є це відповіддю на головне питання життя, всесвіту і всього такого? Не особливо. Для WinRT вибрали курс на явне зближення технологій, який потенційно може призвести до прекрасних речей, але поки що немає упевненості в правильному виборі шляху. Але що може бути цим “правильним шляхом”?


Going Native 2.0 – продуктивність для всіх


Перевірки на безпеку можуть мати негативний вплив на продуктивність, але керований код не приречений все життя запускатися тільки поверх повільного JIT (наприклад, Mono вміє запускати C # код, нативний скомпільований через LLVM на iOS / Linux) і було б досить легко розширити байткод небезпечними інструкціями щоб надати контрольоване поліпшення продуктивності (на зразок відміни перевірки кордонів масиву).

Але самої явною проблемою зараз є відсутність сильної інфрастуктури для межязикових компіляторів. Починаючи з компілятора, використовуваного в IE 10 JavaScript JIT,. NET JIT і NGЕN компілятори, Visual C + + компілятор (і багато інших) – всі вони використовують різний код для практично однієї і тієї ж трудомісткою і складною завдання – генерації ефективного машинного коду. Маючи в розпорядженні єдиний компілятор – це дуже важливий крок для надання високопродуктивного коду, доступного для всіх мов.

Felix9 на Channel9виявив, Що Microsoft в дійсності може працювати над цією проблемою. Це безперечно гарні новини, але проблема “продуктивності для всіх” лише невелика частина від загальної картини. Насправді “вірний шлях “, згадуваний раніше, – це більш широка інтегрована архітектура, не тільки поліпшенийLLVMстек, але підтримана багаторічним досвідом Microsoft в різних областях (компілятор C + +, JIT, збирач сміття, метадані і т. д.) система, яка надаватимеповністю розширювану і модульну “CLR”, Що складається з:



Ідея дуже близька до стеку CLR, проте вона не примушує додатка запускатися поверх JIT компілятора (так, в. NET є NGEN, але він був розроблений для прискорення завантаження, не для прискорення спільної роботи, крім того це чорний ящик і він працює тільки зі збірками, встановленими в GAC) і дозволяє змішані стратегії виділення пам’яті: з використанням збирача сміття і без нього.

У подібній системі межязиковое взаємодія буде більш простим, не жертвуючи продуктивністю заради простоти і навпаки. В ідеалі, сама ОС повинна бути побудована на базі подібної архітектури. Можливо саме ця ідея була (є?) в основі таких проектів, якRedhawk(Це що стосується компілятора) абоMidori(Що стосується ОС). У подібній інтегрованій системі, можливо, тільки драйвери будуть вимагати прямого доступу до заліза.

Felix9 такожрозкопав, Що проміжний байткод, більш низькорівневий, ніж MSIL (байткод. NET), званий MDIL, вже може використовуватися і він може бути саме тим проміжним байткод, описуваним раніше. Хоча, якщо подивитися на відповідний патент “INTERMEDIATE LANGUAGE SUPPORT FOR CHANGE RESILIENCE“, То в специфікації можна знайти x86 інструкції, які не зовсім підпадають під визначення архітектурно незалежного байткод. Можливо вони залишать MSIL без змін і задіють MDIL на більш низькому рівні. Скоро дізнаємося.

Отже, які проблеми з цієї точки зору вирішує WinRT? Метадані, трохи API, що підтримує пісочниці та межязиковое взаємодія в зародковій стадії (хоча є загальні типи даних і метаданих). Як бачимо, не густо, такий собі COM + +. Також очевидно, щоWinRT не надає просунуті оптимізації, коли ми використовуємо його API. Наприклад, нам не дозволено мати структуру зі вбудовуваними методами. Кожен виклик методу в WinRT – це віртуальний виклик, який обов’язковій піде через таблицю віртуальних методів (а в деяких випадках потрібно декілька віртуальних викликів, коли наприклад використовується статичний метод). Найпростіші читання-запис властивості зажадають віртуального виклику. Це явно неефективно. Судячи з усього WinRT націлений тільки на більш високорівневі API, не дозволяючи сценарії, в яких ми б хотіли використовувати високопродуктивний код скрізь, де це можливо, минаючи шар віртуальних викликів і невстраіваемого коду. У результаті ми маємо розширену модель COM – це не зовсім те, що можна було б назвати “Building the Future”.


Продуктивність і продуктивність для C # 5.0


Мова начебто C # був би ідеальним кандидатом для такої модульної CLR системи, і могла б з легкістю переноситися на вже існуючий проміжний байткод. Але щоб ефективно використовувати подібну систему, C # повинен бути поліпшений в декількох аспектах:



Крім продуктивності є й інші не менш важливі області:



Основна ідея в тому, щопотрібно менше додати в C #, ніж прибрати з C + +, щоб повністю задіяти можливості подібної інтегрованої системи, збільшити продуктивність розробника і без супутніх втрат продуктивності. Хтось може посперечатися, що С + + вже пропонує все це і навіть більше, але саме тому С + + такий загромажденний (з точки зору синтаксису) і небезпечний для більшості розробників. Він дозволяє небезпечний код абсолютно скрізь, в той час як у кожному додатку є цілком певні місця, де він дійсно потрібний (що призводить до проблем з пам’яттю, які простіше виправити, якби ці місця були явно позначені в коді, як це зроблено з ключовим словом asm). Набагато простіше і безпечніше відстежувати подібні області в коді, ніж мати їх повсюдно.


Що ж далі?


Ми сподіваємося, що Microsoft вибрала шлях від загального до приватного і почала з випуску WinRT, що надає універсальне API для всіх мов і просте межязиковое взаємодія. І що потім вони представлять всі ці більш просунуті можливості в наступних версіях їх ОС. Але це ідеальна ситуація і буде цікаво спостерігати, чи зможе Microsoft впоратися з цим. Навіть якщо недавно оголосили, що. NET додатки в WP8 матимуть переваги компіляції в хмарі, дотепер ми мало що знаємо про це: це просто адаптований NGEN (який, нагадаю, не орієнтований на продуктивність і генерує код дуже схожий на той, що генерує JIT) або ще не представлений компілятор RedHawk?

У Microsoft напевно щось є в загашнику, враховуючи багато років розробки компіляторів C + +, JIT, збирача сміття і всіх пов’язаних R & D проектів, які у них є …

Підводячи підсумки -. NET повинен померти і поступитися своїм місцем більш інтегрованою, орієнтованої на продуктивність, загального середовища, де б кероване (безпека і продуктивність) і некероване (продуктивність) були б тісно пов’язані. І це повинно бути структурною частиною наступного витка розвитку WinRT.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*