Po tym jak Xamarin przejął Mono od Novella, zaczął pracować nad projektem – XobotOS. Wyniki eksperymentu wskazują na to, że .NET i C# mogłyby zastąpić Javę w Androidzie, uwalniając tym samym Google od sporów patentowych i poprawiając wydajność tworzonych aplikacji.
Idea zastosowania C# zamiast Javy pojawiła się już u samych początków Androida. Zdecydowano się jednak na drugą opcję. Dzisiaj Xamarin stara się przekonać deweloperów Androida do korzystania z platformy Mono, jako lepszej i wydajniejszej, charakteryzującej się rónież mniejszym zużyciem baterii. Platforma Mono jest produktem open-source’owym wdrażającym .NET framework, pozwalającym deweloperom na pisanie kodu przy użyciu C#, podczas pracy w opartym na Javie systemie. W ramach projektu XobotOS przeniesiono Androida 4.0 z platformy Java/Dalvik na C#. Tłumaczenie kodu Javy na C# przeprowadzono przy pomocy open-source’owego konwertera Sharpen. Część kodu przetłumaczono ręcznie.
1 maja Xamarin udostępnił ulepszony Sharpen wraz z kodem do systemu XobotOS na licencji Apache.
Obok poprawy wydajności, za zmianami przemawiają szczególnie kwestie prawne. Microsoft zapewnia o braku ewentualnych roszczeń patentowych. Wprawdzie Xamarin rozwijał XobotOS tylko po to by przystosowac Mono do Androida, ale całe przedsięwzięcie pokazuje alternatywy i nowe perspektywy dla Google.
Więc pozwy od M$ są lepsze od pozwów od Oracle? O ile z Oracle Google ma jeszcze szanse wygrać, to M$ ma za dobrych prawników. Po za tym Mono jest sto lat za murzynami – spróbujcie odpalić appkę korzystającą z XNA i .NET 4.0
A te zapewnienia M$ można sobie o kant d.. potłuc. Dopóki nie będzie tego na piśmie i zpotwierdzeniem notarialnym, oczywiście.
Czytat z orginalengo artykułu.
"Warto dodsać, że .NET framework jest objęty prawnie wiążącym zapewnieniem Microsoftu o braku ewentualnych roszczeń patentowych."
W artykule autor może sobie pisać nawet, że istnieją krasnoludki.
FAQ Mono http://www.mono-project.com/FAQ:_Licensing#Patent… jawnie kłamie na temat patentów.
Microsoft, w swoim Community Promise, pozwala rzekomo używać ich patentów do implementacji ich standardów. Owszem, ale tylko tych, które, jak to ujmuje, są *niezbędne* do implementacji tych standardów:
1) Mono narusza tym samym setki (bzdurnych, ale istniejących) patentów dotyczących optymalizacji i rozszerzeń, bez których jednak Mono nie nadawałoby się do użytku i nie spełniało podstawowych funkcji.
2) Nie wszystko w .NET i C# jest standardem ECMA, a więc Obietnica tego nie obejmuje.
Jednym słowem: Microsoft posiada patenty, które mogą posłużyć do pozwania Mono i zniszczenia tego projektu.
Więcej: http://www.fsf.org/news/2009-07-mscp-mono
Dlatego nie należy *uzależniać* programów i środowiska open-source od takie zaminowanej technologii:
„Why free software shouldn’t depend on Mono or C#”: http://www.fsf.org/news/dont-depend-on-mono
"Jednym słowem: Microsoft posiada patenty, które mogą posłużyć do pozwania Mono i zniszczenia tego projektu. "
Microsoft posiada patenty, które mogą posłużyć do pozwania i zniszczenia dowolnego projektu, którego właściciel nie posiada patentów mogących posłużyć do odstraszenia Microsoftu.
C# jest ECMA, część bibliotek .NET nie jest
Poza tym nie wiadomo czy Community Promise microsoftu jest w ogóle prawnie wiążąca, ponieważ nie ma drugiej strony tej umowy.
Nie licencjonujesz tych patentów od microsoftu.
Nie da się zawrzeć umowy "z całym światem".
To jest tylko publikacja microsoftu. Warta tyle co obietnice tuska.
"Poza tym nie wiadomo czy Community Promise microsoftu jest w ogóle prawnie wiążąca, ponieważ nie ma drugiej strony tej umowy. "
Prawnie wiążące są nie tylko umowy, ale także różne publiczne deklaracje, oferty itd.
Uśmiałem się jak norka tym co napisałeś. W przypadku Microsoft jedyna droga aby przetrwać to … unikać Microsofta. Nie widzicie jak Microsoft "pomógł " Nokii?
Ej, ale co to ma do rzeczy? Community Promise jest wiążąca, bezwartościowa jest akurat z innych powodów, o których zresztą kolega, którego nicka nie lubią moderatorzy napisał wyżej.
Obietnice polityków także? Ba, nawet ich programy wyborcze i inne deklaracje są publikowane. I co? Strasznie wiążące?
P.
A co to ma do CP? Nic, tak sobie chciałeś pobredzić.
BTW, w procesie Oracle z Google jednym z ważniejszych argumentów Google był post Schwartza na blogasku; argument upadł, ale nie dlatego, że to był post na blogasku, tylko dlatego, że udowodniono, że w Google nie potraktowali tego poważnie.
Jest dokładnie tak samo wiążące prawnie jak GPL.
Nie. GPL jest licencją, której zastosowanie do oprogramowania przewiduje prawo (w tym polskie). Tak samo jak innych licencji, w tym EULA microsoftu.
Natomiast opublikowanie czegoś na swojej stronce internetowej jeszcze nie oznacza, że ma to jakąkolwiek moc prawną.
W żaden sposób nie jesteś powiązany z tymi patentami i prawami do nich. Nawet reklama w telewizji ma większą moc prawną, bo jest ofertą i w momencie zakupu stajesz się stroną umowy, a więc oferta i reklama nabierają mocy prawnej w stosunku do tej umowy.
A tu co masz?
Nie licencjonujesz tych patentów od microsoftu. Nie jesteś w żaden sposób stroną.
Na wniosek microsoftu sąd na 100% orzeknie, że naruszasz ich patenty (fakt).
I co powiesz? Że gdzieś tam było napisane, że możesz? Możesz jako kto? Gdzie jest umowa? Gdzie są podpisy uprawnionych osób? Sąd nawet nie przyjmie ci takiej sprawy do rozpatrzenia.
"Sąd nawet nie przyjmie ci takiej sprawy do rozpatrzenia. "
WOW, bywalec sądów się znalazł.
Budyń ma rację, jest bardzo podobnie. W GPL też nie masz podpisów. Tutaj pobierasz ze strony MS specyfikację razem z MCP i jak najbardziej możesz tego użyć w sądzie.
Przy GPL masz redystrybucję, czyli umowę. I licencja jest jej częścią.
"redystrybucję, czyli umowę"
??? Nie bardzo rozumiem ten tok myślenia, ale niech będzie, że masz specyfikację czyli umowę i Community Promise jest jej częścią.
Na desktopie Mono jest znacznie powolniejsze od Javy. Jeśli na Androidzie jest odwrotnie, to gratuluję Google'owi ewelacyjnej szybkości Dalvika… 😀
A jeszcze jedno: czy Mono uporało się już z wyciekami pamięci? Czy na Androidzie też używa zachowawczego Boehm GC, który cieknie czasem nawet w skrajnie prostych przypadkach? http://flyingfrogblog.blogspot.com/2009/01/mono-2… http://flyingfrogblog.blogspot.com/2010/07/mono-2…
O ile wiem Dalvik też jest szybszy od Javy. Po to powstał, bo Java się nie nadawała.
Więc mamy jakąś dziwną sprzeczność.
Mono > Dalvik > Java > Mono
Dalvik nie powstał by być szybszym generalnie od Sun Java tylko po to żeby na określonym rodzaju sprzętu (ARM) chodził znacznie lepiej niż uwczesne implementacje javy które w tamtym czasiechyba istniały tylko w wersji full (x86) lub J2ME (arm) + żeby było to niezależne od firmy trzeciej (w stosunku do autora androida czyli google).
Ty i ta Twoja "wiedza" :>
Nie jest. I dlatego Dalvik m.in. nie wykorzystuje obecnej w niektórych ARMach technologii Jazelle.
Dalvik powstał dlatego, że Google nie chciał płacić opłat licencyjnych za Javę ME. Ot, cała prawda.
I łatwiej było okraść umierającego Suna niż Microsoft, który by Google'owi nie odpuścił. Tyle że Suna z Javą wykupił Oracle, który teraz zrobi porządki.
A Google – ze swoimi zasobami – mógł spokojnie albo wrzucić tam Pythona, D, albo skorzystać z C++/Qt (o? trzeba by płacić?) albo nawet wrzucić tam coś własnego (np. Scalę własnej wirtualnej maszynie HLVM czy podobnego). Chociaż, patrząc na "sukcesy" Wielkiego G. takie jak "Go" (nieużywane) czy choćby Unleaden Swallow (niby przyspieszenie Pythona)…. cóż, zrzynać gotowce najłatwiej.
Od kiedy za C++/Qt miałbyś płacić? Chyba żyjesz w latach 90-tych.
Google niczego nie ukradł.
Chyba, że Vistual Studio to też efekt kradzieży przez microsoft języka C++ i innych?
Co do powodów stworzenia Dalvika było właśnie tak jak pisze jarek.
x86 nie pasowało, a j2me to było, mówiąc wprost, gówno.
Na blogu Xamarin wyczytałem, że lepsza wydajność wynika z faktu, że Google nie używa pełnego mechanizmu HotSpot. Z tego co wiem to od androida 2.2 albo 2.3 Dalvik ma JIT, ale być może nie jest zrobiony tak dobrze jak w wersji Oracla. Poza tym w benchmarku testują głównie wydajność generics, które jest w C# wydajniejsze niż w Javie. Tak więc czysta manipulacja.
" Tak więc czysta manipulacja." nie po prostu java jest do dupy – gdzie w tym mnipulacja ?
Generalnie, to CLR powstał od zera 10 lat później niż JVM i siłą rzeczy miał przewagę 10 lat badań, rozwoju i doświadczeń w teorii która stoi za całym interesem.
Fanboje oczywiście tego nie zrozumieją, ale C# jest b. dobrze zaprojektowanym językiem, na dobrej maszynie wirtualnej.
I CLR/C# był od poczatku robiony pod zastosowania Desktop / Mobile, a nie tak jak Java / Oak – która miała służyć do programowania urządzeń, i tam zasadniczo mimo olbrzymiej inercji poniosła porażkę.
Hahahaha. C# na desktop 😀 Dobre sobie. Jak lubisz tragicznie wolne pamięciożerne programy pisane przez nieuków, których język prowadzi za rączkę, więc program prawie nigdy się nie wywali, za to prawie zawsze gdy powinien się wywalić zadziała nieprawidłowo i dostaniesz idiotyczne wyniki… to proszę bardzo.
Szczerze wolę, żeby program zrobił czasem coś źle, np. nic nie zrobił, niż się wywalił. Tak przynajmniej dam radę zapisać bieżący dokument i nie stracę danych, a nie jak Inkscape, OpenOffice czy Gimp, które ni z tego ni z owego robią segfault i mogę sobie pożegnać ostatnie kilka minut pracy.
"nie po prostu java jest do dupy – gdzie w tym mnipulacja "
Nie to MONO jest do dupy, co widać w normalnych nie manipulowanych benchmarkach
Java nie jest bardziej do dupy niż C#. Oba siebie warte.
Więc o ile Javy nie lubię, to nie zakłamujmy rzeczywistości.
wszystko jest do dupy ! Asembler niech rzadzi na wieki !!!
Asembler jest bardzo szybki. Ale niewygodny.
Java i C# są strasznie wolne, ale wygodne.
A C++ jest szybki i wygodny.
Jeśli nie rozumiesz tak oczywistych rzeczy to współczuję.
Wygodne to może być krzesło. Java i C# obrosły w takie ilości różnych frameworków, bibliotek i innych niezbędników, że są wygodne jak krzesło w czterdziestoma nogami. Siedzi się znośnie, ale wymaga sporo miejsca.
😀
Błąd. C++ jest albo szybki albo wygodny (i to raczej średnio wygodny, bo do języków takich jak OCaml / Scala / Haskell / D to wygodą kodowania jeszcze długo nie podskoczy). Ale nie równocześnie.
Możesz pisać niskopoziomowo w C++, traktować go jak C z klasami – wtedy jest szybki, ale mało wygodny i kodu dostajesz tylko troszkę mniej niż w czystym C.
Możesz pójść w drugą stronę, wciskając wszędzie szablony, obiekty funkcyjne, inteligentne wskaźniki, kolekcje, stringi, wyjątki z ładnym stacktrace, wywołania wirtualne, ba nawet jakoś GC da się zrobić, pierdyliard bibliotek i warstw abstrakcji, silnik skryptów, plugin Flasha itp. Będzie wtedy nieco zwięźlejszy i wygodniejszy ale pod względem szybkości to dostaniesz coś w rodzaju oficjalnego klienta GG.
C++/Qt – wygodny i szybki
Wygodny? Kolejny framework wprowadzający własne klasy dla napisów (no tak jakby było ich za mało). Nie, dziękuję.
Na szczęście w PyQt (API 2) można korzystać ze zwykłych "pythonowych" ciągów znaków. Podobnie w PySide.
"Kolejny framework wprowadzający własne klasy dla napisów "
Może dlatego, że te ze standardowej biblioteki są słabe? To jest jedna ze słabości C++, ciągle szukasz jakiś bibliotek, kombinujesz bo standardowe są kiepskie, ale częściej mało czym dysponujesz i szukasz czegoś. Jak się przyzwyczaisz do QStringów, ale zachcesz napisać coś Witty to musisz się przestawić na WStringi 🙂
Assembler nie jest szybki, co najwyzej niskopoziomowy.
Nieznajac dobrze architektury procesora mozesz w assemblerze napisac duzo wolniejszy kod niz to, co wypluwa z siebie kompilator c/c++.
Od początku mówimy o optymalnym kodzie.
Jeśli ktoś nie umie pisać optymalnego kodu to niech idzie zmywać garnki.
Optymalny kod w assemblerze jest szybszy od optymalnego kodu w C++, który z kolei jest znacznie szybszy od optymalnego kodu w Javie czy C#.
Tyle, że w assemblerze trudno się pisze, a w C++, Javie czy C# łatwo.
Wybór jest więc prosty.
Wybór nie jest prosty, bo coś takiego jak kod optymalny istnieje tylko w teorii. Kod nie jest optymalny i nie musi być wcale optymalny. Optymalne mają być krytyczne fragmenty. Dlatego tandem { wygodny wysokopoziomowy język + C / asm } jest IMHO lepszym wyborem niż rozwiązanie pośrednie czyli C++, który nie jest ani tak wysokopoziomowy jak choćby nawet Java, ani nie daje takiej kontroli jak asm.
a co powiecie o pythonie? ma biblioteki w C/C++ = ma jego szybkosc w newralgicznych miejscach + jest wygodny i wysokopoziomowy przez co jest bardzo produktywny [efekty/czas] wydajnosc jest tez wystarczajaca do takich zastosowan. do tego wszystkie Cythony czy pypy albo psycho.
Tak zrobiono MyPaint, bardzo fajny program.
Python napisany w C = GIL. Epic fail.
Python w innej implementacji -> brak biblioteki standardowej Pythona (IronPython) albo to samo + dwa lata za liderami + żenująca wydajność i pamięciożerność (Jython).
Python dobrze zrobiony -Stackless Python -> nie lubiany przez "Community" Epic Fail.
Nie mówiąc o tym, że Pythona w normalnych zastosowaniach, C# i Java zjadają na śniadanie, choćby ze względu na lepsze maszyny wirtualne i garbage collectory.
Ba, nawet w Hello World Python inny niż CPython dostaje zauważalnie w dupę 😀
Swoją drogą, ciekawe kiedy OSnewsowi mistrze zaczną rozróżniać projekt języka (składnię, implementowane paradygmaty) od jego implementacji.
sam jestes epic fail.
nie uzywaj tak mocnych slow, jesl nie pasuja do rzeczywistosci.
gil z pythona ma zniknac z tego co wiem.
co do predkosci działania.. myslisz ze od czego sa biblioteki w C? widac, nie uzywales pythona nigdy w praktyce. znasz tylko wykresiki w ktorych ktos probuje na sile wynajdowac kolo na nowo zaczynajac od kwadratowych scianek.
"Dlatego tandem { wygodny wysokopoziomowy język + C / asm } jest IMHO lepszym wyborem niż rozwiązanie pośrednie czyli C++"
Ale chyba projekt w którym używa się i miesza kilka języków jest trudniejszy do prowadzenia?
@mikolajs
Nie, dlaczego ? Trzeba umieć i mieć kadry. Spokojnie się da.
Zresztą, każdy większy projekt niż aplikacja do pierdzenia zwykle korzysta z co najmniej kilku języków, i często nie z tego samego domu.
C# od mono szybszy od javy -> http://shootout.alioth.debian.org/u64q/which-prog…
a teraz popatrz na zużycie pamięci
Java nie musi zajmować tyle pamięci, możesz ograniczyć jej użycie.
i wtedy będzie proporcjonalnie wolniejsza od mono
Nie wiem czy będzie wolniejsza. Za to Mono nie potrafi wykorzystać pamięci, które dzisiejsze komputery i mają sporo.
Mają jej sporo nie po to, żeby programik do pierdzenia pozwalał sobie zużyć jej 1GB.
Wara od nie twojej pamięci! Zapłaciłeś za nią na komputerze użytkownika, że tak nią szastasz? Może jest dostarczana w pudełku z twoim programem?
Wyjdzie na to, że "pamięci jest sporo", odpalisz kilka programów napisanych z tym hasłem na ustach i nagle pamięci brakuje.
Ot dzisiejsza fuszerska deweloperka. Byle szybko, byle tanio, a użytkownik niech sobie wymieni komputer. Tfu!
@o_O
[quote]
Ot dzisiejsza fuszerska deweloperka. Byle szybko, byle tanio, a użytkownik niech sobie wymieni komputer. Tfu!
[/quote]
To nie fuszerka developerów tylko wymagania rynku – dodatkowa kość 4GB RAM kosztuje grosze – zatrudnienie programisty żeby się pobawił w optymalizacje kosztuje krocie.
Devil
Duże zużycie pamięci to jest wina programisty lub użytej konfiguracji, a nie języka. Pisałem aplikacje w Javie, które zamykały się w 500 kB RAMu.
Poza tym byle aplikacja do pierdzenia na desktopie, niezależnie od języka potrzebuje kilkaset MB RAMu – na załadowanie systemu operacyjnego. W przypadku Windows może być to nawet 1GB. W tym kontekście zużycie dodatkowych kilkunastu MB RAMu przez JVM jest śmieszne.
To prawda. Ale już od dawna nie jesteś w stanie robić wszystkiego sam. Korzystasz z pracy innych ludzi. Niestety java (i podobne) tak rozleniwia, że ci inni ludzie nie dbają o takie szczegóły jak zajętość pamięci.
To niestety prawda. Ale to nie jest specyficzne dla Javy, bo programy w C++ (i wszystkich innych językach) jakimś cudem ostatnio też zajmują coraz więcej RAMu. Teraz jak komunikator tekstowy zjada tylko 20 MB, to jest uważany za "lekki". Kiedyś przeglądarki internetowe chodziły w 32 MB, teraz potrzebują 10x tyle.
Zauważ, że obsługują 100x tyle nikomu nie potrzebnych gadżetów takich jak zmiana skórki czy dodatków
"Wara od nie twojej pamięci! Zapłaciłeś za nią na komputerze użytkownika, że tak nią szastasz? Może jest dostarczana w pudełku z twoim programem? "
Swoje aplikacje piszę w Scali i uruchamiam je na swoim serwerze, więc nikomu nie wciskam pudełek z programem, ani też nie używam pamięci użytkowników.
Już widzę jak piszesz aplikację webową w C++
Poza tym, programy pisane specjalnie dla danej firmy też często pisze się w Javie. Jak sobie skalkulujesz ile musiałbyś zapłacić za napisanie takiej aplikacji w C++ to wolisz dokupić trochę pamięci i bierzesz Javę. Jak ktoś pisze aplikację dla masowego użytkownika na desktop to nie używa Javy.
Zrobić wsparcie dla Python i tyle. Po cholerę Java, C# wielkie i wolne kobyły.
Albo najlepiej superszybki C++.
Dokładnie. QT jest do zagospodarowania, jak Nokia go nie chce.
z tego co się orientuję, jest Qt na androida od jakiegoś roku więc droga wolna. Na szybko anwet parę aplikację w playu znalazłem.
Eee tam. C++ jest powolne i kobylaste. Najlepiej pisać wprost w czystym kodzie maszynowym.
0/10
C++ jest strasznie szybkie w porównaniu do Javy i C#.
Co do kodu maszynowego to tak uskrajnaijąc po prostu się ośmieszasz.
Asembler jest bardzo szybki. Ale niewygodny.
Java i C# są strasznie wolne, ale wygodne.
A C++ jest szybki i wygodny.
No jeśli lubisz Pointer Hell, to twoja sprawa.
Co Ty, on nie ma żadnego pointer hell. On koduje pewnie wszystko na Boost shared_ptr i kolekcjach STLa. I myśli, że to jest szybkie, bo w C++. 😀
Czyli że pisanie własnych rozwiązań, zamiast korzystanie z czyichś bibliotek jest lepsze? W każdej publikacji jaką znam takie podejście piętnują jako nieefektywne. Z reguły biblioteki są znacznie lepsze od tego co sami jesteśmy w stanie wyklepać.
Oczywiście biblioteki mogą być monstrualne (.nety) ale czy akurat stl czy boost do takich się zalicza?
P.
Oczywiście, że korzystanie z bibliotek jest lepsze. Problem w tym, że w C++ pewne rzeczy masz dostępne tylko jako biblioteka (np. wątki, automatyzacja zarządzania pamięcią), co powoduje, że ma to znaczny narzut w porównaniu z tym gdyby było to wbudowane w język, jak w Javie/C#.
Narzut to jest oczywiście organizacyjny, bo jak nie ma biblioteki standardowej, to pojawiają się biblioteki na różnych licencjach, w równych wersjach, ten programista zna to a tamten tamto… itd.
Ale jak czytam twoją wypowiedź, to mam wrażenie, że masz na myśli większy narzut wydajnościowy i to "znacznie większy". Na jakiej podstawie takie twierdzenie?
1. W Javie automatyczne wskaźniki zajmują 32 bity na 32 bitowych systemach, 32 bity lub 64 bity na 64 bitowych (w zależności od wielkości sterty – do 64 GB możesz mieć tylko 32 bity). W C++ automatyczne wskaźniki zajmują 64 bity na 32 bitowych systemach i odpowiednio więcej na 64 bitowych, a dodatkowo ich tworzenie / przypisanie / zwalnianie to całkiem pokaźny kawałek kodu, w porównaniu z jedną instrukcją w Javie. Podsumowując – w Javie wskaźniki są automatyczne, ale działają tak samo szybko jak surowe wskaźniki z Cpp.
2. Stringi. W Javie stringi można przekazywać bezpiecznie wszędzie przez wskaźnik, bo są niemutowalne. Możesz sobie np. trzymać je w wektorach, mapach itp. W C++ masz mutowalne stringi, więc poza prostymi przypadkami lokalnego "użyczenia" innej funkcji – wymagają kopiowania, albo opakowania w shared_pr, ale to jest kiepskie z powodu 1. Akurat to jes w sumie bardziej feler biblioteki standardowej niż języka, no ale dość denerwujący.
3. Obsługa wątków. Kompilator kompletnie nic o niej nie wie. W ten sposób odpada wiele optymalizacji, które mógłby zrobić (np. biased locking, eliminacja blokad, scalanie blokad itp.)
4. Inlining kodu bibliotecznego, w tym wywołań wirtualnych. C++ standardowo tego nie umie, a już na pewno nie w przypadku dynamicznego ładowania bibliotek. Stąd takie zamiłowanie koderów C++ do kodu w nagłówkach – rozwiązują ten problem poświęcając produktywność (długi czas kompilacji).
5. Uboga biblioteka standardowa – efekt jest taki, że wielu programistów korzysta tylko z tego co jest pod ręką, bo użycie dodatkowych bibliotek często wiąże się z kłopotem (choćby przenośność). Przykład – długo nieobecne w standardzie unordered maps. Stąd jest całe mnóstwo kodu korzystającego z nieoptymalnego map.
ok, dzięki. o to mi chodziło.
Głównie Qt, choć boost czy STL też nie są złe.
A w czym Java koduje swojego GC i resztę ciężkiego syfu? 😉
Czyżby w C/C++? Owszem!
Ale całego tak ogromnego frameworka stworzonego nad C++ nie traktujesz jako ogromny narzut na wydajność C++?
A głupie guerded pointery tak?
Ciekawe podejście…
Inteligentne wskaźniki mają kilka razy większy narzut niż referencje w Javie, a i tak są mniej funkcjonalne, bo np. nie radzą sobie z cyklami. Przypisanie wskaźnika w Javie to jest jedna instrukcja CPU. Przypisanie guarded pointera w C++ to jest kilkanaście, wliczając w to interlocked inc / dec, który kosztuje masakrycznie dużo na wieloprocesorowcach.
STL i Boost powodują kosmiczny code-bloat. Nie ma to jak generować kilka razy ten sam *cały* kod dla klasy kolekcji tylko dlatego że typ generyczny się nieco zmienił. Do tego wszędzie stosują kopiowanie przez wartość, co jest szybkie tylko dla małych obiektów.
Stosują przenoszenie które jest szybkie również dla dużych obiektów o ile mają poprawny move ctor. Nie wspominając o optymalizacjach kompilatorów C++, które są naprawdę dobre jeśli chodzi o usuwanie zbędnego kopiowania.
Racja, ale to działa tylko w *niektórych* przypadkach i tylko wtedy jeśli faktycznie nie musisz kopiować. Czyi programując i tak musisz myśleć o tym, co zrobi kompilator i czy faktycznie zrobi optymalizację czy nie. Też mi wygoda. Jak mam sprawdzać na każdym kroku co zrobił kompilator, to równie dobrze mogę pisać w C. Przynajmniej będę miał pewność jak działa mój kod.
Programując musisz pamiętać o kilku prostych zasadach (np. dla każdego obiektu z nietrywialnym copy ctor trzeba napisać move ctor, używać odpowiednio referencji i wartości w parametrach itp.). Da się to zmieścić w niedużym coding standard. A jeśli rzeczywiście jest problem z wydajnością to profilujesz szukając tych 20% które warto przyspieszać.
A pisz sobie w C(zym) chcesz, co mi do tego.
Może i Python jest całkiem fajnym językiem, ale daleko mu do wydajności Javy i C#.
Raczej nie tak daleko jeśli do porównania dorzucimy C++.
Wtedy Python, Java i C# lądują razem w jednej grupie wolnych języków na drugim końcu skali co C++.
jkl już Ci niżej napisał, że Twoje super szybkie C++ dostało bęcki od Javy w dwóch benchmarkach, a w wielu innych nie jest lepsze o więcej niż 25%.
W testach stworzonych tak, żeby akurat wykorzystać ten 0.1% sytuacji, gdzie Java wypada lepiej.
Odpal sobie jakiś rzeczywisty program stworzony w Javie/C# i odpowiedni w C++ i porównaj wydajność. Rzeczywistość po prostu tych sfałszowanych wyników nie potwierdza.
Tak. Odpaliłem. Cassandra vs MongoDB. Mongo zostało zmiażdżone w teście szybkości zapisów.
O, a tu ktoś zrobił jeszcze porównanie z HBasem (który jest IMHO cienki): http://www.cubrid.org/blog/dev-platform/nosql-ben…
Widzisz, tak się dziwnie składa, że w zastosowaniach wymagających dużej przepustowości i obsługi dużej ilości danych (petabajty) liczą się głównie rozwiązania Javowe. Trudno szukać równie rozwiniętych i zarazem tak szybkich odpowiedników systemów jak DSE/ Cassandra / HBase / Hadoop, które zostałyby napisane w Cpp . Owszem ktoś tam próbował z Hypertablem (Cpp ) ale się nie przyjęło na taką skalę. Chyba był za powolny. 😀
No, patrz, bazka napisana w C++ nie poradziła sobie zbyt dobrze bo dane się w pamięci nie mieściły? Buhaha.
"Raczej nie tak daleko jeśli do porównania dorzucimy C++.
Wtedy Python, Java i C# lądują razem w jednej grupie wolnych języków na drugim końcu skali co C++. "
Chyba nie widziałeś nigdy żadnych benchamarków. Więcej realizmu, mniej fanbojstwa 🙂
wielkie i wolne kobyły w porównaniu do pythona -> http://shootout.alioth.debian.org/u64q/benchmark…. jak widać i to nie jest prawdą. Java jest szybsza a nie zabiera owiele wiecej pamieć (nie raz nawet mniej).
Ale równać z C++ się Java nie może. Nawet nie ma co próbować. Tak samo C#.
Jak się nie może? W 2 testach jest szybsza. Poza tym porównaj sobie czas napisania głupiej aplikacji okienkowej w C++ i Javie.
A odkąd Minecraft (na badziewnym Opengl 1.0 i generowaniu części efektów przez procek) ALE JEDNAK pokazał, że w Javie się da. 😉 Ciekawe co by było gdyby jego autor wiedział jak się używa OpenGLa.
Procesory graficzne w procesorach mobilnych do demonów szybkości nie należą. Aplikacje okienkowe w C++ za pomocą bardzo wielu bibliotek pisze się naprawdę szybko. ARM ze swą maszyną Javy Jazelle nie ma zaimplementowanych sprzętowo wszystkich operacji. Niewielką część trzeba robić kodem. A to nie sprzyja szybkości aplikacji.
Tak się dziwnie składa, że nikt, podkreślam nikt, no może poza akademickimi "artykułowymi" rozwiązaniami nie stosuje Javy tam gdzie niezbędna jest integralność czasowa aplikacji. Nawet gdy rozwiązanie jest oparte o spore zasoby sprzętowe. Zapewne w tym coś jest?! W testach to telefon komórkowy na baterii 1000mAh zapewnia 420min. nieprzerwanej rozmowy a towarzysze Radzieccy wysłali psa Łajkę w kosmos…
Minecraft to pokazał jak nie należy pisać gier. Tnie się tragicznie na prostej grafice nawet na najlepszym sprzęcie. To jest dno programistyczne, a wiele ze swojej badziewiaści zawdzięcza właśnie Javie.
No, jasne Ty byś napisał lepszy, w C++ oczywiście. Czekamy…. 😀
Minetest, coraz szybciej goni Minecraft jeżeli chodzi o funkcjonalność.
Mój syn dodaje do Minecrafta plugin (napisany w Javie) który mocno poprawia wydajność gry, co tylko świadczy o umiejętnościach programistycznych twórcy Minecrafta.
W mobilnych rozwiązaniach mamy ciekawą sytuację. Jeśli chodzi o wydajność w końcu dużo słabszych maszyn jakimi są komórki i tablety to nie w językach kompilowanych pisze się aplikacje. Tymczasem na Desktopie króluje C/C++, który łatwiej by pociągnął aplikacje Java. Paradoks? Gdyby nie produkowano tak wielu telefonów z wykorzystaniem różnorodnych podzespołów to języki kompilowane miałby większą szansę.
A Java i C# niby nie są kompilowane ?
JIT to nie to samo. Kompilacja w trakcie uruchamiania czy działania musi zużywać zasoby sprzętowe. Ma to swoje zalety. ale lepiej jest dobrze skompilować kod wcześniej.
1. Kompilować można też do kodu pośredniego, niekoniecznie maszynowego, a nawet można kompilować do innego języka.
2. Podział na języki kompilowane i niekompilowane jest umowny i bardziej wynika z tego co jest na rynku niż cech samego języka.
3. Polska wikipedia polskiemu hasłu "Kompilacja" przypisuje angielskie hasło "Software build" mimo, że to są zupełnie różne kwestie. Skompilować a zrobić "execa" to nie to samo. Polskiemu hasłu "kompilacja" z grubsza odpowada hasło "Compiler".
Nie wiem kto Budyniowi tak ponaparzał w minusa. Widać jacyś wielcy znawcy.
Miałem na myśli kompilowanie do kodu maszynowego, nie wyraziłem się precyzyjnie.
Bo to jest nieprecyzyjne słowo w naszym środowisku, więc spoko. Mnie tylko zniesmaczyło zaminusowanie gościa na śmierć za coś co chyba nie było nonsensem. A i tak za Budyniem na tym forum nie przepadam. Coś mi tam kiedyś dogryzał albo herezje głosił 🙂
Od naprawdę długiego czasu i to nie tylko w aplikacjach tego typu dostrzegam pewną, niestety smutną, prawidłowość. Problemem nie jest "ileśtam" procesorów czy innych podzespołów. Zauważ, że jądro Linuxa radzi sobie z przeogromną liczbą sprzętu a nie jest po skompilowaniu takie wielkie.
Problemem są, w moim przekonaniu ludzie. Ogólnie "specjaliści" dzielą się zawsze na 3 kategorie. Tych, którym się wydaje, że potrafią coś zrobić. Tych, którzy potrafią coś zrobić. Wreszcie tych którzy wiedzą co robią. Niestety tych ostatnich jest najmniej 🙁 . Ogólny tręd do "upraszaczania" i tworzenia "klocków" spowodował, że nawet najprostsze rzeczy zaczynają być skomplikowane same z siebie. Dlatego zapomnijmy o eleganckich aplikacjach a przytłaczająca większość tego co jest i niestety będzie napisane będzie tchnęła ociężałością. Bo ociężałość jest możliwie głupotoodporna. To tak jakby porównywać budowlę romańską przypominającą stodołę z kamienia z gotyckimi strzelistymi świątyniami opartymi o łuki i podpory z zatykającymi dech w piersiach witrażami. Jak zwykle wszystko już było… . Na początku, z powodu skromnych zasobów sprzętowych i złożoności prymitywnych narzędzi programy pisali ci, którzy wiedzieli co robią. Teraz mamy styl romański czyli "g… szopy" i tylko gdzie niegdzie ktoś "postawi" jakąś strzelistą gotycką świątynię. Dlatego nie dziwmy się, że "ciągną" potem do niej tłumy. To jest okrutna prawda o całym rynku inżynieryjnym, nie tylko związanym z IT. W oprogramowaniu jest o tyle lepiej, że nic się nie zawali od razu a odpowiedzialność za "g… szopę" jest znikoma. Już większa jest choćby za pękającą od samego patrzenia autostradę. Dlatego tak wielu się "garnie".
Smutna prawda.
Chyba niepotrzebnie obarczasz odpowiedzialnością inżynierów. To są decyzje strategiczne wynikające z polityki firm. np. zmieniać co chwila rodzaj ładowarki by w razie jej uszkodzenia użytkownik musiał kupować nowy telefon. To samo tyczy się kodu. Po częśći odpowiada za to ekonomia (katedra gotycka kosztuje dużo i nie wiem czy ty byś chciał za nią płacić). Z drugiej strony mamy faktyczny spisek producentów (temat filmu "Spisek żarówkowy"). A z trzeciej.. głupotę konsumentów, którzy np. zezwalają na istnienie takiego kuriuozum jak "rower za 400zł" (skoro kupują to zezwalają) albo wypisują po forach, że WieśVagen jest mniej awaryjny do Alfy Romeo – bo tak znajmomy znajomego powiedział a wyników raportów Tuva albo Dekry nie jest geniusz w stanie sam wyszukać. Ech marność 🙂
Za utrzymanie gotyckich katedr jestem gotów płacić i płacę. A chwile spędzone w ciszy wewnątrz nich uważam za najbardziej produktywne. Płacę nawet za te w stylu romańskim! Choćby po to by została zachowana i przetrwała ta różnica, która czegoś uczy.
Wymieniając trzy grupy i obarczając je odpowiedzialnością pisałem także o sobie. Bez wyjątku! Nie zwalajmy na kogoś, to my to tworzymy i za to odpowiadamy. Tak samo jak za samokształcenie. Za to właśnie cenię Linuxa, że uświadomił mi, że moje "doskonałe" programy nie są takie doskonałe i będę potrzebował sporo czasu by pisać tak jak to robią inni dużo lepsi w tamtym momencie. I nie ma znaczenia, że nie jestem inżynierem oprogramowania. Skoro coś robię to mam to robić porządnie bo za to odpowiadam. Skoro się podjąłem to odpowiadam. To ostatnie słowo wypadło ostatnimi czasy wogóle ze sfery języka i pojęć.
"Spece" od marketingu i ekonomii narzucają nam swój sposób postrzegania problemów bo na to większość nas pozwala. Nikt się nie przeciwstawia i potem zarywa noce a na końcu i tak całość jest g… warta a na poprawki trzeba bedzie wydać przynajmniej 50% więcej poieniędzy i czasu jak w przypadku normalnej pracy.
Jak masz oddać kod na wczoraj to nie masz czasu rzeźbić. Katedry budowało wiele pokoleń jak chcesz postawić daczę to nie będziesz stawia wielkiego gmachu z głębokimi fundamentami. Ważne tylko aby ciągle się rozwijać bo nawet w pośpiechu można pisać coraz lepiej.
Problem w tym, że obecnie większość kodu jest "na wczoraj". A to zapewne z powodów braku właściwego prowadzenia projektu. A potem nie tylko autostrady pękają od samego patrzenia 🙁 . Umówmy się, że istnieje pewna nieprzekraczalna "prędkość" tworzenia czegokolwiek kiedy jeszcze wszystko trzyma się kupy. A potem? Nie będę się wypowiadał gdyż jest to mi obce cywilizacyjnie ipojęciowo. Wiedzą to zapewne "Stachanowcy" co wyrabiali 210% "normy" a efekty tego "wyścigu" z czasem można zupełnie za darmo obserwować na codzień.
A po co równać w dół ?
Równasz w dół to ty poziom rozmowy.
nie ma to jak rzeczowy argument
Nie ma to jak układ forum chronologiczno wcięciowy z płytkimi wcięciami i wypowiedzi w 100% kontekstowe :).
Oj, może może. W Javie/C# (a szczególnie w Scali/F#) pisze się złożone aplikacje szybciej i w ten sposób pozostaje więcej czasu na optymalizację wysokopoziomową, której żaden kompilator automatycznie nie przeprowadzi. To jest taki sam paradoks jak z pisaniem wszystkiego w asmie. Teoretycznie w asmie powinno dać się napisać najszybszy możliwy kod, jednak w praktyce, przy ograniczonym budżecie i czasie i normalnej wielkości aplikacji (a nie benchmarku na 20 linijek), jest to nierealne.
Konkretny przykład z praktyki: Mercurial vs Git. Ten pierwszy napisany w Pythonie, powinien być teoretycznie powolny jak żółw. Tymczasem średnia wydajność obu jest bardzo podobna, ale zdarza się że Mercurial jest od Gita znacznie szybszy.
Tak jest, uskrajniaj pisząc o asemblerze.
C++, Java, C#, … to języki o podobnym stopniu skomplikowania i czasochłonności pisania aplikacji.
Gdzie to w ogóle porównywać do asemblera?
Natomiast o ile C++ jest szybki, to Java i C# są już tragicznie powolne.
I do C++ nie potrzeba żadnych optymalizacji kompilatora, żeby przebić Javę czy C#. One po prostu mają taki narzut, że chociażbyś 10 lat poświęcił na optymalizację, to i tak będą wolne.
W C++ programuje się bardzo szybko i wydajnie. O ile się umie.
Ale lepiej zatrudnić niedouczonych studentów do klepania w frameworkach Javowych czy .net prowadzących ich za rączkę i pokazującym gdzie wstawić ich kod w gotowy schemat i dodających tym samym jeszcze dodatkowy narzut do powolności samych języków.
Teraz przeginasz w drugą stronę. C++ jest faktycznie wydajniejszy, czego dowodzą benchmarki, jednak w praktyce różnie to bywa. Teoretyczna wydajność języka/środowiska to nie wszystko.
Mierząc względem asemblera, owszem.
Oczywiście.
A mierząc względem Javy i C# programuje się tak samo szybko i wygodnie.
Nie, nie tak samo. Może same okienka klepie się tak samo szybko, bo to i tak się w XMLu czy jakim kreatorze robi. Ale pokaż mi choćby dobry ORM, kontener IoC, framework webowy dla C . Nie ma? A wiesz dlaczego nie ma? Bo się nie da napisać tego w taki sposób aby było tak wygodne w użyciu jak w jest w C#/Javie. Nawt Qt to już lepienie z taśmy i sznurka – np. moc. 😀
Przecież C++ nie ma nawet systemu modułów / pakietów, więc o jakiej wygodzie pisania Ty mówisz? Przecież toż to nawet Pascal miał.
A tu masz przykład, że nie tylko ja uważam, że większość libów w C nie jest ani wygodna, ani łatwa, ani dobrze zaprojektowana:
http://www.johndcook.com/blog/2011/06/14/why-do-c…
"C++, Java, C#, … to języki o podobnym stopniu skomplikowania i czasochłonności pisania aplikacji. "
Widocznie niczego nie pisałeś w innym języku niż C++.
W Androidzie nie ma Javy
W Androidzie jest Java-język i pewna część standardowej biblioteki Java (o którą zresztą Oracle się przyczepił, że Google nie miał do niej prawa – w tej części sprawy chodzi o copyright, nie patenty). Natomiast JVM jest własne, napisane przez Google.
Nie wiem jak jest z szybkością Dalvika, ale te "benchmarki" udowadniające, że Android na C# to 8 cud świata są śmieszne. Test, mniej więcej wygląda tak:
for(int i=1; i<=780000; ++i) {
hashtable.put(i, 1.0f / i);
}
czyli autoboxing na całego vs C# bez autoboxingu… Dalej nawet nie chce sprawdzać.
Źródełka: https://github.com/zanew/MonovsDalvik/blob/master…
Co mi po (być może) szybszym i lepszym c# jeśli interfejs i tak zrobię w kreatorku generującego XML-a i przy obracaniu ekranu system musi ponownie parsować co najmniej połowę tego interfejsu. Moim zdaniem właśnie xml jest największym problemem wydajnościowym Androida. Oczywiście można wszystkie łidżety zrobić w kodzie, ale to już trzeba umieć więcej i jest to sporo pracy.
Tak czy inaczej xml pozostaje w kodzie i się tego nie przeskoczy, bo Android już taki jest. Chociażby preferowany sposób wstawiania tekstu do łidżetów to xml i rzeczywiście jest to wygoda przy tworzeniu różnych wersji językowych.
Jeszcze jednym z argumentów przeciw mieszaniu w "developmemtcie" Androida jest fakt, że plugin do Eclipse, jakby go nie kląć, jako tako działa. Kreatorek to ściągania SDK też jest w porządku i sporo konsolowych narzędzi jest całkiem przydatnych (np. logcat, mksdcard).
Z tego co wiem proces z Oracle układa się dla Google pomyślnie i wielkiej awantury z tego nie będzie. Dajcie Javie spokój, bo Android pokazał, że się da i market pusty nie jest.
Po prostu marketing 🙂
to warto sprawdzić resztę – zwłaszcza scimark – gdzie jest miedzy innymi obliczanie FFT, wyliczanie PI metodą MonteCarlo, itp.
No, i tu już Mono dostaje w d* dosyć solidnie. http://flyingfrogblog.blogspot.com/2009/01/mono-2…
Ten blog jest z 2009 roku chętnie bym zobaczył benchmarki z mono 2.11 gdzie domyslnym GC jest SGEN – tak samo koncowka serwerowa koncowka llvm pewnie jest szybsza niz java.
Też bym chciał zobaczyć. Jeżeli poprawili te wycieki w Mono, to dobrze, bo rozważamy kompilować naszą aplikację również do mono za pomocą kompilatora Scala -> .NET.
Test ten był przeprowadzany na Windows ( tak zakładam bo .NET gdzieś indziej nie występuje ) co się przekłada na wyniki MONO bo Windows nie jest natywnym środowiskiem jego działania
W komentarzach autor napisał w odpowiedzi na podobne spekulacje:
"Your claim that our tests were performed under Windows is wrong. We used Linux for all tests except F# on .NET."
Nie wiem nie czytałem komentarzy . Z tekstu to nie wynikało, tak jak wersja NET-a
Tym razem zrobią konwerter z dotNIET na Dalvika, który tak czy tak musi zostać ? Co z tego, że wprowadzą nowy język programowania+VM, jak nikt nie będzie się pozbywał tysięcy aplikacji z Marketu, a utrzymywanie Javy+C# równolegle będzie wymagało sporo pracy i jeszcze więcej miejsca w ROMie.
Spokojnie zrobią nowe, lepsze, wydajniejsze "komputerofony" które ogarną temat 😛
Ja myślę że wykorzystają Goo lub inny swój język. To byłoby naturalne. I wyszłoby Androidowi na dobre. Wystarczy tylko odpowiednie API zrobić by symulować na początku Javę. A od wersji 10.0 wywalić resztki Javy.
Jak już to Dart w planach uniwersalny język do prawie wszystkiego. Oprócz zastąpienia JavaScript ma też umożliwiać pisanie na Androida. Tyle, że od planów do realizacji daleka droga, a poza tym nie każdy będzie chciał od razu rzucić się na nowy język. Jak zostanie zmuszony do rezygnacji z Javy to najpierw zastanowi się czy przypadkiem jak już musi się przestawić na jakieś inne rozwiązanie nie spróbować Objective-C, czy C#.
Jako użytkownik C# mogę powiedzieć że Dart jest nawet fajniejszy niż C# i życzę im jak najlepiej.
To może się udać bo:
a) język ma składnie która jest łatwa do ogarnięcia przez programistów javy i c#
b) Dart od początku jest pomyślany jako język do którego jest porządny tooling (mają swój edytor już teraz z działającym intellisense)
c) Google zatrudnił najlepsze mózgi poza Microsoftem od VM i budowy języków (jak choćby Gilad Bracha)
Perl, Python, Javascript, C++, C++0x, Ruby, PHP … Jest mnóstwo otwartych i wolnych (od freedom) języków z dobrymi frameworkami, więc najwyższy czas olać to co komercyjne, zamknięte i opatentowane czyli Jave i C#(.Net)
Powodzenia w pisaniu aplikacji na Androida w php!
To że coś jest otwarte nie znaczy, że nie narusza patentów (często absurdalnych). Akurat Java i C# nie są mniej otwarte niż PHP. Jak ktoś zrobi równie szybką maszynę wirtualną dla PHP lub Pythona, to się zaraz okaże, że znowu jakaś firma wyskoczy z patentami.
Po co w ogóle maszyna wirtualna? Nie można po prostu napisać natywnej aplikacji?
Jeśli ktoś uważa, że jakieś rozwiązanie jest wolne, ponieważ język jest wysokopoziomowy to proszę zapoznać się z gotowym rozwiązaniem, które działa i nie jest ani benchmarkiem ani teoretycznym wywodem. W wielu miejscach językiem jaki jest wybrany to Python. http://tmblr.co/ZElL-wCjaDmU
Bardzo dobra informacja. Jeśli ktoś dobiera sobie oprogramowanie na zasadzie "religii", albo nie rozumie, że technologię dobiera się do potrzeb i czasem opłaca się wybierać rozwiązania wolniejsze lecz wygodniejsze, to sam sobie czyni szkodę. Alternatyw nigdy dość. A C# zasługuje spokojnie na to, by być równoważnym językiem na platformach uniksowych, ponieważ ma wiele ciekawych możliwości, łatwo się w nim pisze i może z powodzeniem być alternatywą dla Javy. Jak ktoś nie umie programować to i w assemblerze nic nie zdziała. Chyba, że dla kogś liczą się miliksekundy w uruchamianiu i działaniu softu i zrobił sobie z tego religię. W aplikacjach korporacyjnych, gdzie najwięcej zabiera wymiana informacji po webserwisach, wczytywanie setek XMLi czy odpytywanie wielu baz danych i chmur, a wszystko trwa jakiś czas, te milisekundy nie mają znaczenia. Ba, nawet sekundy. Miejmy nadzieję, że Linuksowi użytkownicy będą mieć niebawem kolejne pełnowartościowe narzędzie. Wtedy już żaden Microsoftowy fanboy nie będzie męczył, że na Linuksie nie chodzi .NET 🙂 🙂