Mono – wolna implementacja .NET jest już w wersji 2.0
- Dodano: 6 października 2008
- Wprowadził: init.d
- Komentarze: 36
Zespół twórców Mono – wolnej implementacji frameworka .NET dla Linuksa, BSD, MacOS X, a także Windows – poinformował o wydaniu stabilnej wersji 2.0 swojego projektu. Teraz programistom będzie o wiele łatwiej przenosić aplikacje pisane dla Windows na inne systemy operacyjne.
Wersja 2.0 jest ważnym kamieniem milowym w rozwoju tej alternatywy dla .NET-u. Wprowadza obsługę wielu nowych API, zarówno Microsoftu jak i własnych interfejsów Mono. W nowej edycji pojawiły się m.in:
- ADO.NET 2.0 – mechanizmy dostępu do baz danych,
- ASP.NET 2.0 – do pisania aplikacji webowych,
- Windows.Forms 2.0 – do tworzenia aplikacji desktopowych,
- System.XML 2.0 – do manipulowania danymi w XML-u,
- System.Core – zapewniający obsługę LINQ (Language Integrated Query),
- System.Xml.Linq – dostarczający LINQ dla XML-a,
- System.Drawing 2.0 – przenośne API do renderowania grafiki.
Warto też zwrócić uwagę na integrację nowego Mono z Gtk+ i GNOME, interfejsy dla biblioteki graficznej Cairo, wbudowaną obsługę SQLite i możliwość łączenia się z najważniejszymi bazami danych – w tym Oracle, PostgreSQL, MySQL, Firebird i SQL Server.
Wydanie zawiera kompilatory C# 3.0 i Visual Basica 8 oraz assembler i disassembler IL. Wszystko to jest dostarczone wraz z zestawem narzędzi do debuggowania, linkowania i zarządzania kodem.
Więcej informacji: http://www.mono-project.com/Release_Note...s_Mono_2.0
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
36 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
W jaki sposób zaimplementowane jest Windows.Forms pod GNU/Linuksem?
Jak wejdziesz na mono-project.com to w opisie zmian w wersji 2.0 masz zrzuty ekranu. Wygląda bardzo dobrze.
W wersji 1.x WinForms w Mono były bardzo kiepskie (sporo migania, wolne, itp). Ciekawe czy poprawili.
Chodziło mi bardziej, czy jest to np. binding go GTK+.
System.Windows.Forms w Mono nie korzysta z GTK+, zamiast tego implementuje własne widgety na podstawie libgdi++.
Ciekawe, jak jest z wydajnością. Ktoś ma może dostęp do jakiś rzetelnych benchmarków nowej wersji MONO? Z tego co widziałem, implementacja MS .NET na Windows jest już prawie tak szybka jak Java 6 (mniej więcej w tym sensie jak Java 6 jest "prawie" tak samo szybka jak C++), ale Mono było zawsze kilka razy wolniejsze. Ale może już teraz to nieprawda i się wyrównało?
Hmm, od kiedy pamiętam to Java generalnie ustępowała .NET-owi pod względem szybkości wykonania kodu, niekiedy nawet dwukrotnie. Byłbym zdziwiony, gdyby się to w ostatnim czasie zmieniło, zwłaszcza że programy .NET-owe, w przeciwieństwie do Javowych, zawsze są kompilowane do kodu natywnego _przed_ wykonaniem. Od wersji 2.0 jest też bardzo dobrze wspierany kod 64-bitowy, który jest generowany transparentnie jeśli mamy 64-bitowego OS-a (tzn. aplikacja napisana w czystym kodzie zarządzanym może być 32- lub 64-bitowa w zależności od tego na jakim systemie zostanie uruchomiona, a użytkownik nie musi o niczym wiedzieć – owszem Java też na to pozwala, ale w przypadku Javy narzut pamięciowy JVM-a jest często znacznie większy)
Wydajność CLR-a jest oczkiem w głowie Microsoftu, szczególnie teraz, gdy promuje XNA jako uniwersalną platformę do pisania gier na Windows i XBoksa.
fakt. jesli .niet w wydaniu ms ustepowal javie, to nie w wydajnosci, a w ilosci dostepnych bibliotek.
.NET jest kompilowany __przed__ wykonaniem i to właśnie powoduje, że startuje już z gorszej pozycji niż Java. JVM robi coś takiego jak profile-driven-compilation, zanim skompiluje kod, obserwuje jak jest wykonywany i zbiera statystyki, więc w ostateczności ma szanse produkować dużo lepszy kod. Poza tym JVM nie musi kompilować całego kodu, przez co może lepiej skompilować fragmenty, które są wąskim gardłem. .NET bywa szybszy jak się go porównuje z JVM w trybie -client, a nie -server (częsty błąd w benchmarkach). Od Javy 7 te tryby będą zintegrowane i wydajność aplikacji klienckich będzie tak szybka jak obecnie -server.
Java traci natomiast na czasie pierwszego uruchomienia i sprawia wrażenie powolnej, ponieważ musi załadować i zweryfikować multum kodu do pamięci na starcie. Kodu, który dla .NET jest natywny, jest częścią Windows i jest już dawno załadowany. Stąd też większa pamięciożerność Javy. W momencie jednak, gdy kod jest w pamięci (z poprzedniego uruchomienia), aplikacje Javy startują porównywalnie szybko. Tzn. ja nie widzę problemu – czas startu w okolicach 1 sekundy dla prostej apl. okienkowej i 6-7 sekund dla rozbudowanego IDE Eclipse mnie w zupełności zadowala.
w przypadku javy serwerowej, gdzie ten sam kod wykonywany jest wielokrotnie – rzeczywiscie daje to kopa
w przypadku javy klienckiej – uruchamiany co chwile ant, co chwile ma zbierane statystyki i grzyba mu to daje…
Racja. Jednak, wbrew pozorom, nie to głównie odpowiada za powolność anta i krótko-działających aplikacji. Duzy narzut jest na samo rozpakowywanie, ładowanie, weryfikację i linkowanie klas. Taki ant na starcie, zanim w ogóle cokolwiek zacznie robić, ładuje chyba kilka jak nie kilkanaście tysięcy klas
Na to jest też niezłe rozwiązanie: NailGun.
Miejmy nadzieję, że kiedyś Sun zrobi porządny MVM i tego typu technika, tylko z uwzględnieniem aspektów bezpieczeństwa, będzie stosowana standardowo.
ant byl tylko przykladem, ktorego problem bardzo latwo rozwiazac – marven
chodzilo mi o aplikacje, uruchamiane w trybie klienckim, ale wielokrotnie – we w miare krotkim czasie.
generalnie pod tym wzgledem aplikacje javowe nie pasuja kompletnie do filozofii unixa – wiele malych narzedzi, pracujacych wspolnie przy uzyciu potokow.
efektywniejsza praca z nimi – polega na podejsciu promowanym przez "system operacyjny emacs", czyli wlacz raz, uzywaj tygodniami bez opuszczania…
Mylisz się, te całe statystyki nie mają nic wspólnego z optymalizacją kodu, a jedynie pokazują JIT-owi które części kodu warto przekompilować jako natywne. Takie podejście sprawia, że aplikacja jawowa ma tendencję do przyśpieszania po pewnym czasie od uruchomienia (szybciej w przypadku jvm serwera), co raczej nie wystepuje w przypadku aplikacji dotnetowych.
Co do ew. optymalizacji generowanego kodu, to niestety sprawy mają jeszcze gorzej, ponieważ bytecode sam w sobie reprezentuje już na tyle niskopoziomowy kod, że trudno go analizować np. pod względem funkcjonalnym (bloki, przepływ sterowania, itp.).
.NET ma tu kolejną przewagę, ponieważ zamiast bawić się we wróżkę podczas wykonania programu, korzysta z gotowych metadanych wygenerowanych podczas kompilacji do "managed code" i może pozwolić sobie na znacznie wyższy poziom abstrakcji przy optymalizacji, wiedząc o strukturze programu znacznie więcej.
W przypadku Javy jej zachowanie niestety wynika z przyczyn historycznych, i nie jest najefektywniejszym podejściem.
Te statystyki służą do tego co opisałeś ORAZ do optymalizacji kodu.
Optymalizacje korzystające z informacji zbieranych w trakcie wykonania:
- method / virtual method inlining
- branch prediction hints
- lock elision / biased locking / adaptive locking
- register allocation
Mylisz się odnośnie trudności analizy bytecodu. Informacja o strukturze programu jest zachowywana na poziomie bytecodu, a jej analiza nie jest trudniejsza. Skompiluj kod Javy i zdekompiluj, zdziwisz się ile zostało bez zmian. Dlatego nie ma powodu aby optymalizować na poziomie kodu źródłowego – właśnie taka optymalizacja była stosowana w pierwszych wersjach Javy, później się z tego wycofano.
Nie będę się upierał przy wyższości AOT nad JIT, w rzeczywistości każda z tych technik ma swoje mocne i słabe strony. Jeśli chodzi o aplikacje okienkowe to jednak AOT sptawdza się lepiej:
http://dotnet.sys-con.com/node/46901
natomiast duże i długotrwałe procesy obliczeniowe, mogą bardziej zyskać dzięki JIT. Ten artykuł to dość ładnie opisuje:
http://www.ibm.com/developerworks/java/library/j-…
Przy czym warto zaznaczyć, że CLR korzysta także z JIT-a, tylko nie pozostawia mu całej roboty do zrobienia.
Co do samej analizy bytecode'u to pamiętaj, że większość optymalizacji statycznej została już wykonana przez kompilator, tak więc JIT może się skupić (i to jest jego główne zadanie) na optymalizacjach lokalnych.
Jakkolwiek, proces odtworzenia struktury programu na podstawie analizy bytecodu Javy jest w dużej mierze wykonalny dzięki specyficznej właściwości zapisywania wszystkich klas w osobnych plikach (w ogólności to dość karkołomne zadanie, o czym przekonał się każdy kto bawił się takimi narzędziami jak np. IDA, które i tak potrafią bardzo wiele), to jednak nie jest to wykorzystywane i prawdopodobnie przyniosło by JIT-owi więcej szkody (zasoby i wydajność) niż pożytku.
To była tylko ilustracja, że analiza kodu na poziomie bajtkodu jest wykonalna. Oczywiście JIT nie dekompiluje do źródeł, a operuje na bajtkodzie. Nic nie stoi na przeszkodzie, żeby w Javie zapisywać skompilowany i zoptymalizowany kod na dysk do ponownego wykorzystania, zyskując wszystkie zalety AOT – jest to tylko kwestia czasu i przeznaczenia odpowiednich zasobów ludzkich, żeby to zaimplementować. Podobnie można współdzielić załadowane klasy w pamięci pomiędzy różnymi aplikacjami, tak jak to robi NailGun (CDS w JVM na Windows jest tylko namiastką tego). Tak czy inaczej na pewno jest jeszcze dużo do zrobienia.
Na razie jednak developerzy skupiają się na innych rzeczach, które mogą przynieść większe korzyści, jak np. Tiered Compilation, odśmiecacz G1 (powinien mieć dużo lepsze parametry, zwłaszcza jeśli chodzi o przestoje, niż odśmiecacze generacyjne stosowane obecnie w Javie i C#), czy automatyczna alokacja obiektów na stosie.
BTW. Zrobił się mały offtop, a ja chciałem się tylko dowiedzieć, jak się ma jakość JITa w Mono do implementacji MS.
Ponawiam pytanie.
Pierwszy cytowany tekst jest nieco nieaktualny, bo porównują Javę 1.4 z Excelsior JET. Kliencka Java 1.4 to powolna krowa w porównaniu z kliencką Javą 6. Różnice wydajności rzędu 50-300% miałem okazje doświadczyć osobiście, a i wielu innych użytkowników ma podobne odczucia. Responsywność GUI w ogóle wychodzi poza skalę wszelkich porównań, zwłaszcza na nowym silniku Java2D w wersji 6u10, używającym sprzętowej akceleracji.
Serio, odpaliłem Swingową aplikację okienkową w trybie -server i nie czułem różnicy względem -client. Wcześniej w -server przez pierwsze kilkanaście kliknięć nie dawało się normalnie pracować, dopóki silnik graficzny się nie rozpędził.
Inna sprawa, że Excelsior JET jest projektem komercyjnym i jest naprawdę dobry. Oni skupiają się głównie na wydajności, natomiast w OpenJDK wydajność to tylko jeden z wielu aspektów. JET wymiata też w benchmarkach serwerowych, więc to nie jest tylko kwestia AOT kontra JIT, ale też po prostu jakości optymalizatorów.
AOT jest właśnie po to, żeby tego nie robić i generować optymalny kod w zależności od potrzeb i architektury bez rekompilacji całego programu.
Podejście które zastosowano w .NET-cie czyli:
kompilacja i statyczna optymalizacja -> lekki AOT -> lekki JIT
wydaje się bardziej optymalne od obecnego podejścia Javy:
kompilacja i statyczna optymalizacja -> ciężki JIT. Prawdopodobnie Java prędzej czy później również przejdzie na ten model.
Artykuł, który przytoczyłem wcześniej wydaje się sugerować, że JIT na dłuższą metę generuje najbardziej optymalny kod co jednak nie jest to do końca prawdą, są problemy przy np. przy większych metodach, rozwijaniu funkcji czy przeciążonych operatorach, nieco światła rzuca na ten temat ta prezentacja:
http://www.microsoft.com/Downloads/details.aspx?F…
Macie u mnie plusa, ze tą dyskusję !
Jeśli chodzi o serwerowa JVM, to ja doświadczyłem takiego przypadku na Windows gdy JVM 5 była szybsza od 1.4.2 o jakieś 35% a 6 od 1.4.2 o jakieś 150%. JVM 1.3 nie mała JIT więc wypadła by bardzo blado – mit wolnej Java natomiast pozostaje.
Ponoć JVM od Sun nie jest pisana typowo pod x86, tylko raczej uniwersalnie, tak żeby niewiele się różniła od tej pod Spark – brak fastcall'i (czyli użycia rejestrów na maxa, zamiast stosu do przekazywania argumentów) – jest więc pole do popisu.
Jak dla mnie .NET 2.0 i Java 6 maja podobna wydajność – moim zdaniem Java 6 jest nawet szybsza. Zużycie pamięci jest natomiast po stronie .NET, ale pamiętajmy o sztuczkach jakie MS może robić na Windows. .NET ma agresywniejszy GC drabinowy (bodajże), JIT działa inaczej, cześć bibliotek jest podnoszona przez systemowe myki (Java zadowala się jedynie cache jar'ow).
Sorry, ale .NET jak dla mnie klapnie – monolit i do tego brzydki w środku, brak standaryzacji, harmonijnego rozwoju, dużo bajerów może się podobać do czasu gdy ich działanie nie stanie się magią ponad zmysł poznawczy, no i ta niepewność: co Microsoft knuje i kiedy zrobi z tego użytek.
@wojtekm
"ponieważ bytecode sam w sobie reprezentuje już na tyle niskopoziomowy kod"
Tak jak napisał Kólik: bytekod Java można zdekompilować – traci się jedynie komentarze i czasami deklaracje stałych. Ściągnij sobie JAD (Java Decompiler) i zdekompiluj sobie jakiś plik *.class.
Zobacz też jak działa AOP (Aspect Oriented Programming) – opisujesz w języku XML lib coś a'la Java, co ma być gdzie podpięte pod już skompilowny kod (jaki aspekt/metoda pod wywołanie jakiej metody Java) a enhancer bytecodu, wie gdzie grzebać w bytecode'zie żeby go zenhancować.
Wszystko jest PRAWIE tak samo szybkie jak kod natywny. Ale jak te PRAWIE zbierze sie do kupy to wychodzi wolna i ociężała aplikacja. Taka jest prawda. Na codzień np. uzywam Sybase Central w wersjach pisanej w Javie i natywna dla Windows. Różnica w wydajności jest kolosalna. A to nie jedeyny przypadek.
Za wolne i ociężałe aplikacje odpowiadają głównie kiepscy programiści.
Java i C# wydają się łatwiejsze niż C++ i cierpią trochę na syndrom PHP, zwłaszcza jeśli chodzi o aplikacje okienkowe – piszą je studenci za głodowe pensje, którzy w większości nie nauczyli się C++ czy Pythona "bo za trudne", a projekty zaliczyli przez przeklejanie gotowców z Internetu.
Ale nie oznacza to, że nie ma wielu wymiataczy w C# i Java, którzy potrafią pisać szybkie aplikacje, i że takowych aplikacji nie da się pisać. Popatrz sobie np. na system baz danych H2, napisany w całości w Javie, a wydajnością rozwala MySQL (C++) i PostgreSQL (C).
Nie wiem jak teraz, ale kiedyś w teście wyszło mi że .NET przy tym samym kodzie (ładnie opakowana w klasę sieć neuronowa) był 200x wolniejszy od C++ (kod był niemal identyczny, wiadomo nieco się składnia zmieniła). To taka ciekawostka, od tego czasu pewnie trochę poprawili wydajność, bo to daaaawno temu było.
Co do niechlujności programistów to masz rację ale nie powiesz chyba ze to studenci piszą narzędzia dla Sybase.
Drugi przykład: SQL Server Management Studio 2005 napisany pod .NET. Mozliwości ma ale szybkość jego działania nie poraża, widać nawet powolne odświeżanie UI. Uruchamiany jest na szybkich komputerach z Core2Duo i 2GB RAM. Cos tu jest jednak nie tak.
Ale skąd pewność, że nie piszą ich studenci?
Czemu studenci (niekoniecznie ci najzdolniejsi) piszący magisterki u mnie mi znikają i odnajdują się później w firmach typu Google czy Microsoft? Do Sybase też pewnie trafiają. Aplikacje narzędziowe są najprostsze do pisania, zatrudnia się do tego byle klepaczy kodu. Wymiatacze piszą silniki.
@Magnes: z Javą było kiedyś podobnie, choć może 200 to trochę przesadzona liczba. Java 1.1 pamiętam była jakieś 10x wolniejsza niż natywne odpowiedniki. Wtedy nie było jednak HotSpotu. Możesz teraz ten tryb interpretowany sobie wymusić dodając -Xint.
Od tamtego czasu obie platformy zrobiły b. duży postęp. Widziałem prosty kod Javy, który udało się pokonać w C++ dopiero po zastosowaniu "sprytnych hacków" z napisaniem dedykowanego alokatora i wykonaniu profilowanej kompilacji pod konkretny procesor, a i tak ostateczna różnica była jedynie jakieś 20% na korzyść C++.
BTW. Powolne odświeżanie GUI to ja mam też na Viście, w aplikacjach pisanych w C++, zwłaszcza jak system jeszcze do końca się nie rozpędził (czyt. 2 minuty od zalogowania). Core2Duo z 2GB RAM.
@Krolik
Ja ostatnio załamałem się, biorąc na warsztat framework U++ o którym miałem dobre zdanie, zastosowałem jego input streama wywołując readline na XML (parsowanie przyrostowe XML robiłem) – przeraziłem się jak się okazało, że zaimplementowane w C++ stream z U++ jest 5 razy wolniejszy od Java 6 i 6 razy wolniejszy od mocno zszytego z Windows .NET 2.0. Szkoda że nie chciało mi się już STL maltretować w tym porównaniu (pewnie było by dużo lepiej).
Niestety C++ przez swoją skomplikowaność staje się coraz bardziej zaniedbywane, bo twórcy bibliotek nie silą się na kosztowną i ryzykowną optymalizację.
Wszystko fajnie, a microsoft ma już wersję 3.5. Tak czy siak życzę powodzenia dla mono i tego żeby nowe wersje od ms były niechętnie witane przez programistów.
Hmm… ale to nie jest tak, że Mono 2.0 = .NET 2.0. Mono 2.0 obsługuje podzbiór aktualnych API Microsoftu – tych które dla twórców były najważniejsze.
Tak, ale to jest podobnie jak z Wine – też obsługuje podzbiór API Windows. Problem w tym, że zawsze będzie to podzbiór, bo .NET jest bardzo silnie zintegrowany z platformą Windows i wiele rzeczy trzeba w Mono po prostu od zera zaimplementować. To kosztuje czas. W tym czasie MS wprowadza nowe funkcjonalości i tak się kółko zamyka. Nie wydaje mi się, aby kiedykolwiek przenośność .NET pomiędzy Windows i Linux była taka jak przenośność Javy, gdzie dostajesz kompletną wersję w tym samym czasie, na *nix i Windows.
Sun wybrał lepszą drogę, bo zamiast ściśle integrować Javę z Solarisem poprzez wykorzystanie natywnych bibliotek (przecież mógł to zrobić), napisał większość w Javie, a tylko JVM + niewielki trzon jest napisany natywnie i wymaga portowania. Spowodowało to oczywiście inne problemy (np. historyczna powolność Swinga), ale, po ich rozwiązaniu, w ostatecznym rozrachunku wyszło na dobre.
sun wybral lepsza droge od kogo? ms?
przeciez ms zalezy na tym, aby aplikacje byly pisane pod ICH system…
mono, to ronwnie niezalezna implementacja .dniet, jak classpath implementacja wolnych bibliotek javowych.
tu tez sporo czasu musialo minac, by dojsc do "standardow" wyznaczonych przez suna – przez dlugi czas gnu classpath byl ciagle bardzo, bardzo w tyle za wzorcowa implementacja sunowska.
widze ze niedawne uwolnienie kodu przez suna, zacmiewa obraz, jaki towarzyszyl javie wczesniej…
Lepszą z punktu widzenia użytkowników i popularności platformy.
Otwarcie implementacji Javy i projekty taie jak OpenJDK było kolejnym dobrym krokiem dla społeczności użytkowników.
Eclipse SWT "naprawia" "błąd" poczyniony w JVM/Swing. Niestety natywne swt.jar odwala czarną robotę za dll/so/sl, tak że swt-win32.jar swt-*nix.jar i parę jar silnie zależy od OS'a a co gorsza Eclipse nie kładie nacisku na pokazywanie najmniejszego subsetu bibliotek specyficznych dla konkretnego OS'a.
Co do Mono – fajnie że jest na wypadek jakby .NET miał zgarnąć kawał tortu, tyle że Microsoft ma politykę milionów pomysłów i uciekania przed innymi, więc Mono zawsze będzie niedoimplementowane.
Od siebie powiem tyle: mam wyzuty sumienia ilekroć biorę się za .NET.
Wszystko fajnie, a microsoft ma już wersję 3.5. Tak czy siak życzę powodzenia dla mono i tego żeby nowe wersje od ms były niechętnie witane przez programistów.
Mono i .NET mają różne numeracje. Mono 2.0 zawiera trochę rzeczy z nowszych netów, jak np. kompilator C#. Znaczna część .NET 2.0 była już zaimplementowana w Mono 1.2
Może dla tego, że .NET 3.0 i 3.5 to CLR z .NET-a 2.0 (z SP1) plus nowe klasy i biblioteki.
Tak – tylko zauważ że Mono wie co zaimplementować gdy MS to opublikuje. A publikuje AFAIK wraz z platformą.