Re: Platforma NET Framework 1.1

Robert Winkler wrote:
[...]
> A jeśli chodzi o wydajnosć .NET'a to miło się ostatnio zaskoczyłem
> gdy porównywałem prędkość działania algorytmu obliczania
> wyznacznika macierzy zamplemetowanego
> w C++ z wykorzystaniem klasy vector z biblioetki STL
> do przechowywania wierszy macierzy
> i w C# z wykorzystaniem klasy System.Array
> Spodziewałem sie iż wersja w C# będzie o kilkadziesiąt procent
> wolniejsza od wersji w C++ Zdziwiłem się jedak kiedy wersja w C#
> okazała sie dwukrotnie szybsza od wesji w C++ pomimo zastowowania w
> C++ wszystkich oferowanych przez kompilator optymalizacji.

Witam!

Wyniki mogą być różne na różnych maszynach. Raz C++ może być szybsze raz
.NET.

Wynika to z dwóch aspektów:
- JIT
- GC

- JIT --- Just In Time Compiler, czyli kompilacja w locie. Przy pierwszym
wywołaniu metody jest ona zamieniana w pamięci na kod natywny, czyli na kod
procesora.
Zalety: Kod zarządzany, bezpieczeństwo, możliwość optymalizacji pod
konkretny procesor, obiecywana lepsza przenośność
Wady: Przy pierwszym odwołaniu marnowany jest dodatkowy czas jednak dla JIT,
kolejne odwołania nie. Oczywiście zamknięcie i uruchomienie programu to
zasadniczo nowa robota dla JIT-a

- GC --- Garbace Collector, czyli automatyczne zwalnianie obiektów, pamięci
przydzielonej dynamicznie.
Zalety: Łatwość pisania tworzenia bezpiecznych aplikacji. Nie ma problemy
wycieków pamięci.
Wady: GC jest bardziej złożony i jeśli często jest wywoływany zajmuje więcej
czasu.

Właściwie to GC jest ważniejszy dla wydajności aplikacji .NET niż JIT. W
.NET jest prawdziwy GC jak w Javie, a nie to co było Visual Basci 6. A VB6
był algorytm reference counting, czyli liczenia odwołań do obiektu.
Natomiast .NET używa algorytmu Mark&Sweap. Normalnie aplikacja przydziela
sobie pamięć nie troszcząc się o jej zwolnienie. Dopiero jak brakuje zasobów
GC dochodzi do wniosku, że trzeba coś z tym zrobić. Podobno jeśli źle się
współpracuje z GC to aplikacja może się przytykać bo wątek GC potrafi ją
przystopować. Aby dowiedzieć się, czy obiekt jest potrzebny GC szuka do tego
obiektu odwołań. Jeśli nie ma to wie, że może go zwolnić. Dodatkowo
następuje defragmentacja sterty (struktury między innymi do dynamicznego
przydzielania pamięci) i poprawa wskaźników do obiektów, które w związku z
tym zmieniają położone. Zatem GC to coś poważnego.

A więc dla czego Twój program działa szybciej w C#. JIT nie ma takiego
znaczenie w pętlach, tylko przy pierwszym wywołaniu metody. A Twój program
wykonywał właśnie pętle. Aktywność GC zależy od ilość pamięci w komputerze.
W przypadku tradycyjnych programów, program nie musiał odczuć większą ilość
pamięci. Odczuwalna ona była tylko dla pliku wymiany. Program zwalniał i
przydzielał pamięć nie zastawiając na jakim komputerze działa. A .NET/Java
prawie zawsze wykorzysta więcej pamięci nie tracąc czasu jej zwalnianie :-)
Dodatkowo aplikacje w C++ muszą być gotowe od razu do uruchomienia na
procesorze, a przypadku .NET-u można liczyć na wykorzystanie rozkazów
konkretnego procesora.

Aktualnie .NET jest jeszcze nie jest całkowicie zoptymalizowany, ze względu
na budowę i czas w jakim musiał być dostarczony. Był pisany prawie od
podstawa. Aktualnie to jest nakładka na Win32 API, coś jak MFC Microsoftu
czy VCL Borlanda, albo inne biblioteki. Wersja 2 ma ominąć Win32 API i
odwoływać się bezpośrednio do jądra systemu. Tak ma być w Longhornie i
WinFX. Nie dokończa wiadomo co będzie ze starymi :-) aplikacjami Win32, z
rozwijanie tego API. Programiści C++ dobrze je znający są zaniepokojeni.
Słyszałem pogłoski, że z kolei w Longhornie Win32 API stanie się nakładką na
WinFX. Trzeba poczekać aż się rozjaśni sytuacja bo raczej dwa standardy nie
będą równo ciągnięte przez Microsoft.

Z punktu widzenia administratorów najważniejsze jest bezpieczeństwo tych
aplikacji. O wiele większa granulacja blokad. Można uruchomić aplikacje .NET
i Javy np. bez dostępu do lokalnego dysku. Tak działają aplety Javy.
Wystarczy porównać do kontrolek ActiveX, czyli kodu niezarządzanego.
Zarządzany kod ponadto obiecuje koniec z błędami typu buffer overflow
(przepełnienie bufora).

Czy różnica będzie widoczna tak jak między DOS-em a Windows z punktu
widzenia użytkowników to nie wiem. Chyba to będzie proces bardziej
ewolucyjny, ale technicznie na pewno się zmieni wiele. Jeśli platforma .NET
będzie zdobywała popularność oczywiście.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_marek@gazeta.pl ]