r   e   k   l   a   m   a
r   e   k   l   a   m   a

.NET Native: programujesz w C#, zaś aplikacja działa jakby pisano ją w C – i nie potrzebuje .NET Frameworka

Strona główna AktualnościOPROGRAMOWANIE

Wśród rozmaitych projektów, którymi Microsoft chwalił się podczas tegorocznej konferencji BUILD, pojawiło się coś, czego znaczenie dla normalnego użytkownika Windows łatwo przeoczyć, ale co przyszłościowo patrząc, jest nawet ważniejsze niż przywracanie przycisku Start. Co powiecie na aplikacje pisane w wygodnym i lubianym C#, które wcale nie potrzebują frameworka .NET i działają z wydajnością porównywalną z aplikacjami pisanymi w C/C++? Poznajcie .NET Native.

Raczej nikt nie ma wątpliwości, że tam gdzie liczy się wydajność (np. w programowaniu gier czy przeglądarek internetowych), tam korzystanie z języków, których kod uruchamiany jest 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 (i oczywiście przyjemniejsze od C++ języki) nie zawsze są w stanie zrównoważyć niespecjalnie wydajnego odśmiecania pamięci czy niemożności wykorzystania takich rozszerzeń instrukcji procesora jak SSE.

Projekt .NET Native otwiera drogę do wysokopoziomowych aplikacji .NET kompilowanych bezpośrednio do kodu maszynowego. Stojący za nim programiści Microsoftu Shawn Farkas i Mani Ramaswamy twierdzą, że w wypadku popularnych aplikacji z Windows Store, skompilowanie ich za pomocą .NET Native pozwala na przyspieszenie ich działania o nawet 60%, przy jednoczesnym zmniejszeniu zużycia pamięci o 15-20%.

r   e   k   l   a   m   a

Podczas procesu budowania aplikacji otrzymujemy oczywiście normalne pakiety CIL, ale to co trafia do końcowego użytkownika to normalne .exe, nie mające żadnych zależności względem .NET Frameworka czy jego podzbiorów. Ich rozmiar powinien być niewiele większy, niż w wypadku kodu CIL – statycznie linkowane są wyłącznie tylko te elementy frameworka, które są wywoływane przez programistę. Cały zachodzący w chmurze proces kompilacji wykorzystuje 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. Na razie 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 bliskiej przyszłości, gdy kompilator będzie już gotów do zastosowań produkcyjnych, obsłuży szerszą gamę scenariuszy. W ten sposób będą mogły być kompilowane normalne aplikacje desktopowe spoza Windows Store, aplikacje serwerowe, a także aplikacje dla Windows Phone.

Co ciekawe, nie ma żadnych fundamentalnych ograniczeń w kwestii obsługi przez .NET Native innych niż C# języków tego frameworku. Microsoft twierdzi, że na początek wzięto się za C# tylko dlatego, że właśnie w tym języku jest napisanych większość aplikacji w Windows Store. Przyjdzie jednak czas, że kompilator pozwoli na skompilowanie do kodu maszynowego aplikacji pisanych np. w F# czy np. IronPythonie.

Decyzja Microsoftu o podjęciu prac w tym kierunku może sugerować, że zmieniają się mody w branży IT. W minionej dekadzie kompilacja JIT (just-in-time) w maszynach wirtualnych i inne ekscytujące akademickie koncepcje w rodzaju przenośności kodu czy bezpiecznej typizacji były na ustach wszystkich. To co jednak ładnie wygląda na tablicy, podczas wykładu, niekoniecznie musi mieć jednak sens „przemysłowy” – czy naprawdę świetnym pomysłem jest uruchamianie wymagającego sporych zasobów procesora i pamięci mechanizmu optymalizacji kompilacji za każdym uruchomieniem przez użytkownika aplikacji na jego zwykle znacznie słabszym niż deweloperska maszyna komputerze?

Wydanie .NET Native pokazuje, że być może wcale to nie było tak genialne, jak myśleliśmy jeszcze 10 lat temu. I warto podkreślić, że przecież nie tylko Microsoft idzie w tę stronę. Prace Google'a nad nowym środowiskiem uruchomieniowym Androida (ART) nie mają jedynie na celu wykręcenia się od problemów patentowych z Javą. Przynosi ono hybrydowy model, podczas którego aplikacje są kompilowane jeden raz do kodu natywnego podczas ich instalacji. Jeśli więc i Redmond i Mountain View poradzą sobie ze swoimi projektami, to aplikacje dla Androida i Windows Phone'a wreszcie może przestaną pod względem wydajności ustępować aplikacjom pisanym na iOS-a (Objective C, w którym pisane jest większość aplikacji na mobilny system Apple'a, od samego początku było kompilowane przez środowisko Xcode do kodu maszynowego).

Więcej informacji o .NET Native, jak również niezbędne aktualizacje do Visual Studio 2013, możecie znaleźć na stronie projektu.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.