.NET Native: programujesz w C#, zaś aplikacja działa jakby pisano ją w C – i nie potrzebuje .NET Frameworka
Wśród rozmaitych projektów, którymi Microsoft chwalił siępodczas tegorocznej konferencji BUILD, pojawiło się coś, czegoznaczenie dla normalnego użytkownika Windows łatwo przeoczyć, aleco przyszłościowo patrząc, jest nawet ważniejsze niżprzywracanie przycisku Start. Co powiecie na aplikacje pisane wwygodnym i lubianym C#, które wcale nie potrzebują frameworka .NETi działają z wydajnością porównywalną z aplikacjami pisanymi wC/C++? Poznajcie .NET Native.
Raczej nikt nie ma wątpliwości, że tam gdzie liczy sięwydajność (np. w programowaniu gier czy przeglądarekinternetowych), tam korzystanie z języków, których kod uruchamianyjest w maszynie wirtualnej, takich jak języki rodzin Javy i .NET-u,nie jest najlepszym pomysłem. Wszystkie zalety pisania na .NET,takie jak szybkość tworzenia oprogramowania, przenośnośćaplikacji między wersjami systemu, łatwiejsze unikanie błędów (ioczywiście przyjemniejsze od C++ języki) nie zawsze są w staniezrównoważyć niespecjalnie wydajnego odśmiecania pamięci czyniemożnościwykorzystania takich rozszerzeń instrukcji procesora jak SSE.
Projekt .NET Native otwiera drogę do wysokopoziomowych aplikacji.NET kompilowanych bezpośrednio do kodu maszynowego. Stojący za nimprogramiści Microsoftu Shawn Farkas i Mani Ramaswamy twierdzą, żew wypadku popularnych aplikacji z Windows Store, skompilowanie ich zapomocą .NET Native pozwala na przyspieszenie ich działania o nawet60%, przy jednoczesnym zmniejszeniu zużycia pamięci o 15-20%.
Podczas procesu budowania aplikacji otrzymujemy oczywiścienormalne pakiety CIL, ale to co trafia do końcowego użytkownika tonormalne .exe, nie mające żadnych zależności względem .NETFrameworka czy jego podzbiorów. Ich rozmiar powinien być niewielewiększy, niż w wypadku kodu CIL – statycznie linkowane sąwyłącznie tylko te elementy frameworka, które są wywoływaneprzez programistę. Cały zachodzący w chmurze proces kompilacjiwykorzystuje przy tym optymalizacje standardowego kompilatora C++Microsoftu, zachowując przy tym pełen model obsługi wyjątków C#i bezpieczną typizację.
Przykład z aplikacjami Windows Store nie jest przypadkowy. Narazie to podstawowe ograniczenie .NET Native – może budowaćaplikacje tylko do sklepu z oprogramowaniem dla Windows. Na razie,gdyż projektanci z Microsoftu twierdzą, że w w bliskiejprzyszłości, gdy kompilator będzie już gotów do zastosowańprodukcyjnych, obsłuży szerszą gamę scenariuszy. W ten sposóbbędą mogły być kompilowane normalne aplikacje desktopowe spozaWindows Store, aplikacje serwerowe, a także aplikacje dla WindowsPhone.
Co ciekawe, nie ma żadnych fundamentalnych ograniczeń w kwestiiobsługi przez .NET Native innych niż C# języków tego frameworku.Microsoft twierdzi, że na początek wzięto się za C# tylkodlatego, że właśnie w tym języku jest napisanych większośćaplikacji w Windows Store. Przyjdzie jednak czas, że kompilatorpozwoli na skompilowanie do kodu maszynowego aplikacji pisanych np. wF# czy np. IronPythonie.
Decyzja Microsoftu o podjęciu prac w tym kierunku możesugerować, że zmieniają się mody w branży IT. W minionejdekadzie kompilacja JIT (just-in-time) w maszynach wirtualnych i inneekscytujące akademickie koncepcje w rodzaju przenośności kodu czybezpiecznej typizacji były na ustach wszystkich. To co jednak ładniewygląda na tablicy, podczas wykładu, niekoniecznie musi miećjednak sens „przemysłowy” – czy naprawdę świetnym pomysłemjest uruchamianie wymagającego sporych zasobów procesora i pamięcimechanizmu optymalizacji kompilacji za każdym uruchomieniem przezużytkownika aplikacji na jego zwykle znacznie słabszym niżdeweloperska maszyna komputerze?
Wydanie .NET Native pokazuje, że być może wcale to nie byłotak genialne, jak myśleliśmy jeszcze 10 lat temu. I wartopodkreślić, że przecież nie tylko Microsoft idzie w tę stronę.Prace Google'a nad nowymśrodowiskiem uruchomieniowym Androida (ART) nie mają jedynie nacelu wykręcenia się od problemów patentowych z Javą. Przynosi onohybrydowy model, podczas którego aplikacje są kompilowane jeden razdo kodu natywnego podczas ich instalacji. Jeśli więc i Redmond iMountain View poradzą sobie ze swoimi projektami, to aplikacje dlaAndroida i Windows Phone'a wreszcie może przestaną pod względemwydajności ustępować aplikacjom pisanym na iOS-a (Objective C, wktórym pisane jest większość aplikacji na mobilny system Apple'a,od samego początku było kompilowane przez środowisko Xcode do kodumaszynowego).
Więcej informacji o .NET Native, jak również niezbędneaktualizacje do Visual Studio 2013, możecie znaleźć na stronieprojektu.
