Wydajność C++ a Java/C#

JIT vs. statyczny kompilator

Jak już wspomniano w poprzednich postach, JIT może skompilować IL / bytecode do kodu natywnego w czasie wykonywania. Koszt tego został wymieniony, ale nie do jego wniosku:

JIT ma jeden ogromny problem polega na tym, że nie może skompilować wszystkiego: kompilowanie JIT wymaga czasu, więc JIT skompiluje tylko niektóre części kodu, podczas gdy statyczny kompilator wytworzy pełną natywną binarną: dla niektórych programów, statyczny kompilator będzie po prostu łatwo przewyższać wyniki kompilatora. JIT.

Oczywiście, C# (lub Java, lub VB) jest zwykle szybsze do wytworzenia realne i solidne rozwiązanie niż C++ (choćby dlatego, że C++ ma złożoną semantykę, a biblioteka standardowa C++, podczas gdy interesująca i potężna, jest dość słaba w porównaniu z pełnym zakresem biblioteki standardowej Z. NET lub Java), więc zwykle różnica między C++ i. NET lub Java JIT nie będzie widoczna dla większości użytkowników, a dla tych binariów, które są krytyczne, cóż, nadal można wywoływać przetwarzanie C++ z C# lub Java JIT. Java (nawet jeśli tego rodzaju połączenia natywne mogą być dość kosztowne same w sobie)...

C++ metaprogramowanie

Zauważ, że zazwyczaj porównujesz kod środowiska wykonawczego C++ z jego odpowiednikiem w C # lub Javie. Ale C++ ma jedną cechę, która może przewyższyć Java/C# po wyjęciu z pudełka, to jest metaprogramowanie szablonu: przetwarzanie kodu będzie wykonywane w czasie kompilacji (co znacznie wydłuża czas kompilacji), co skutkuje zerowym (lub prawie zerowym) uruchomieniem.

I have yet so see a real life effect na to (grałem tylko z pojęciami, ale do tego czasu różnica była sekundy wykonania dla JIT, a zero dla C++), ale warto o tym wspomnieć, obok faktu metaprogramowanie szablonu nie jest trywialne...

Edit 2011-06-10: W C++ zabawa z typami odbywa się w czasie kompilacji, co oznacza tworzenie kodu generycznego, który wywołuje kod nie-generyczny (np. generyczny parser od string do type T, wywołujący standardowe API bibliotek dla typów t it jest to bardzo proste i bardzo wydajne, podczas gdy odpowiednik w Javie lub C# jest bolesny w najlepszym przypadku do pisania, i zawsze będzie wolniejszy i rozwiązany w czasie wykonywania, nawet gdy typy są znane w czasie kompilacji, co oznacza, że jedyną nadzieją {27]} jest dla JIT do inline całość.

...

Edytuj 2011-09-20: drużyna stojąca za Blitz++ (Strona główna, Wikipedia ) poszedł w ten sposób, i najwyraźniej, ich celem jest osiągnięcie wydajności FORTRAN w obliczeniach naukowych poprzez przeniesienie jak największej ilości z wykonania runtime do czasu kompilacji, poprzez metaprogramowanie szablonów C++. Tak więc" widzę jeszcze prawdziwy wpływ na to " część, którą napisałem powyżej, najwyraźniej istnieje w prawdziwym życiu.

Natywne Wykorzystanie Pamięci C++

C++ ma inne wykorzystanie pamięci niż Java / C#, a więc ma inne zalety/wady.

Bez względu na optymalizację JIT, nic nie pójdzie ma szybko jak bezpośredni dostęp wskaźnika do pamięci (zignorujmy na chwilę pamięci podręcznej procesora, itp.). Tak więc, jeśli masz w pamięci sąsiadujące ze sobą dane, uzyskaj do nich dostęp za pomocą wskaźników C++ (np. C pointers... Dajmy Cezarowi jego należność) pójdzie razy szybciej niż w Javie / C#. A C++ ma RAII, co znacznie ułatwia przetwarzanie niż w C# czy nawet w Javie. C++ nie potrzebuje using, aby określić istnienie swoich obiektów. Oraz C++ nie posiada klauzuli finally. To nie jest błąd.

:-)

I pomimo prymitywnych struktur c#, obiekty C++ "na stosie" nie będą nic kosztować przy alokacji i niszczeniu, i nie będą potrzebować GC do pracy w niezależnym wątku do czyszczenia.

Jeśli chodzi o fragmentację pamięci, alokatory pamięci w 2008 roku nie są starymi alokatorami pamięci z 1980 roku, które są zwykle porównywane z GC: alokacja C++ nie może być przenoszona w pamięci, prawda, ale wtedy, jak na Linuksie system plików: kto potrzebuje defragmentacji dysku twardego, gdy fragmentacja nie ma miejsca? Używanie odpowiedniego alokatora dla właściwego zadania powinno być częścią zestawu narzędzi programisty C++. Teraz pisanie alokatorów nie jest łatwe, a potem większość z nas ma lepsze rzeczy do zrobienia, a dla większości zastosowań RAII lub GC jest więcej niż wystarczająco dobre.

Edytuj 2011-10-04: przykłady o wydajnych alokatorach: na platformach Windows, od Visty, sterta małej fragmentacji jest domyślnie włączone. W przypadku poprzednich wersji LFH może być aktywowany przez wywołanie funkcji WinAPI HeapSetInformation ). W przypadku innych systemów operacyjnych dostępne są alternatywne alokatory (patrz https://secure.wikimedia.org/wikipedia/en/wiki/Malloc na Listę)

Mimo to nowy standard C++0x narzuci kompilatorom C++ prosty model pamięci, który ustandaryzuje (a tym samym uprości) efektywny multiprocessing/parallel / threading kodu w C++, i dokonać optymalizacji łatwiejsze i bezpieczniejsze dla kompilatorów. Ale za kilka lat zobaczymy, czy jego obietnice będą prawdziwe.

C++ / CLI vs. C# / VB. NET

Uwaga: w tej sekcji mówię o C++ / CLI, czyli C++ hostowanym przez. Net, a nie natywnym C++.

W zeszłym tygodniu miałem szkolenie na temat optymalizacji. NET i odkryłem, że statyczny kompilator jest bardzo ważny. Równie ważne niż JIT.

Ten sam kod skompilowany w C++ / CLI (lub jego przodek, Managed C++) może być razy szybszy niż ten sam kod wyprodukowany w C # (lub VB.NET, którego kompilator wytwarza ten sam IL niż C#).

Ponieważ kompilator statyczny C++ był dużo lepszy do wytworzenia już zoptymalizowanego kodu niż C#.

Na przykład funkcja inlining w. NET jest ograniczona do funkcji, których kod bajtowy jest mniejszy lub równy 32 bajtom. Więc jakiś kod w C# wytworzy 40 bajtowy accesor, który nigdy nie będzie wmieszany w JIT. Ten sam kod w C++/CLI wytworzy 20 bajtowy accesor, który będzie inlined przez JIT.

Innym przykładem są zmienne tymczasowe, które są po prostu kompilowane przez kompilator C++, a jednocześnie są wymienione w IL wytwarzanym przez kompilator C#. Optymalizacja kompilacji statycznej C++ spowoduje mniej kodu, a tym samym autoryzuje bardziej agresywną optymalizację JIT, ponownie.

Powodem tego był fakt, że kompilator C++ / CLI skorzystał z ogromnych technik optymalizacji z rodzimego kompilatora C++.

Podsumowanie

Ale z tego co widzę, C # czy Java są lepsze. Nie dlatego, że są szybsze niż C++, ale dlatego, że po zsumowaniu ich cech, stają się bardziej produktywne, wymagają mniej szkolenia i mają bardziej kompletne biblioteki standardowe niż C++. I jak w przypadku większości programów, ich różnice prędkości (w taki czy inny sposób) będą / align = "left" / ..

Edit (2011-06-06)

Moje doświadczenie w C#/. Net

Mam teraz 5 miesięcy prawie ekskluzywnego profesjonalnego kodowania C# (co dodaje się do mojego CV już pełnego C++ i Javy oraz odrobiny C++ / CLI).

Grałem z WinForms (Ahem...) i WCF (cool!), oraz WPF (Cool!!!! Zarówno przez XAML jak i raw C#. WPF jest tak proste, że wierzę, że Swing po prostu nie może się z nim równać), A C# 4.0.

Wniosek jest taki, że o ile łatwiej/szybciej jest stworzyć kod to działa w C# / Javie niż w c++, o wiele trudniej jest stworzyć silny, bezpieczny i solidny kod w C# (a jeszcze trudniej w Javie) niż w C++. Powody są liczne, ale można je podsumować przez:

1. Generyki nie są tak potężne jak szablony (aby zrozumieć problem, spróbuj napisać efektywną, generyczną metodę parsowania (od string do T) lub wydajny odpowiednik boost::lexical_cast w C#.]}
2. RAII pozostaje niezrównany (GC nadal może przeciek (tak, musiałem poradzić sobie z tym problemem) i będzie obsługiwać tylko pamięć. Nawet C# ' S using nie jest tak łatwe i potężne, ponieważ pisanie poprawnych implementacji Dispose jest trudne)
3. C# readonly i Java final nigdzie nie są tak przydatne jak C++const ( nie ma mowy, aby można było ujawnić tylko złożone dane (na przykład drzewo węzłów) w C# bez ogromnej pracy, podczas gdy jest to wbudowana funkcja C++. Dane niezmienne to ciekawe rozwiązanie, ale nie wszystko może być niezmienne, więc to nie wystarczy, zdecydowanie ).

Java jest jeszcze bardziej frustrująca, ponieważ ma te same problemy niż C#, i więcej: bez odpowiednika słowa kluczowego C#, mój bardzo wykwalifikowany kolega spędził zbyt dużo czasu upewniając się, że jego zasoby są prawidłowo uwolnione, natomiast odpowiednik w C++ byłby łatwy (używając destruktorów i inteligentnych wskaźników).

Więc chyba wzrost produktywności C# / Javy jest widoczny dla większości kodu... aż do dnia, w którym potrzebujesz kodu, aby być jak najdoskonalszym. Tego dnia poznasz ból. (nie uwierzysz, o co pytamy z naszego serwera i aplikacji GUI...).

O Javie i C++po stronie serwera

Utrzymywałem kontakt z zespołami serwerowymi (pracowałem między nimi 2 lata, zanim wróciłem do zespołu GUI), w po drugiej stronie budynku i nauczyłem się czegoś ciekawego.

...Do czasu, aż problem niskiej latencji wychował swoją brzydką głowę w ostatnich miesiącach. Następnie Aplikacje Java server, bez względu na optymalizację próbowaną przez nasz wykwalifikowany zespół Java, po prostu i czysto przegrali wyścig ze starym, Nie naprawdę zoptymalizowany serwer C++.

Podsumowanie

Nic nie jest tak proste, jak oczekiwano.

Java, a jeszcze więcej C#, to fajne języki, z rozbudowanymi standardowymi bibliotekami i frameworkami, gdzie można koduj szybko i uzyskaj wynik bardzo szybko.

Ale kiedy potrzebujesz surowej mocy, potężnych i systematycznych optymalizacji, silnego wsparcia kompilatora, zaawansowanych funkcji językowych i absolutnego bezpieczeństwa, Java i C# utrudniają zdobycie ostatniego brakującego, ale krytycznego procentu jakości, którego potrzebujesz, aby pozostać ponad konkurencją.

To tak, jakbyś potrzebował mniej czasu i mniej doświadczonych programistów w C# / Java niż w C++, aby stworzyć kod średniej jakości, ale z drugiej strony, moment, w którym potrzebowałeś doskonały do doskonałej jakości Kod, nagle łatwiej i szybciej uzyskać wyniki w C++.

Ale nadal tak się dzieje, zarówno w zespołach GUI, jak i zespołach po stronie serwera.

Oczywiście zaktualizuję ten post, jeśli wydarzy się coś nowego.

Edit (2011-06-22)

"okazuje się, że jeśli chodzi o wydajność, C++ wygrywa przez duży margines. Jednak to wymagały również najszerszego Tuning, z których wiele zostało wykonanych na poziomie zaawansowania to nie byłoby dostępne dla przeciętnego programisty.

[...] Wersja Java była prawdopodobnie najprostsza do wdrożenia, ale najtrudniejsza do analizy pod kątem wydajności. Szczególnie efekty związane ze zbiórką śmieci były skomplikowane i bardzo trudne do tune."

Źródła:

• https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
• http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests

Edit (2011-09-20)

"głównym słowem na Facebook jest to, że' rozsądnie napisany kod C++ działa szybko, ', co podkreśla ogromny wysiłek poświęcony na optymalizację kodu PHP i Java. Paradoksalnie kod C++ jest trudniejszy do napisania niż w innych językach, Ale efektywny kod jest o wiele łatwiejszy [do napisania w C++ niż w innych językach]."

– Herb Sutter at / / build / , cytując Andrei Alexandrescu

Źródła:

• http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T
• http://video.ch9.ms/build/2011/slides/TOOL-835T_Sutter.pptx

Za każdym razem, gdy mówię o wydajności zarządzanej vs. niezarządzanej, chciałbym zwrócić uwagę na serię, którą Rico (i Raymond) zrobili porównując wersje C++ i C# chińskiego / angielskiego słownika. To Google search pozwoli Ci przeczytać dla siebie, ale podoba mi się podsumowanie Rico.

Więc wstydzę się mojej miażdżącej porażki? Raczej nie. Zarządzany kod dostał bardzo dobry wynik za mało wysiłku. Na pokonanie Managed Raymond musiał:

• napisać własny plik i / o rzeczy
• Napisz własną klasę string
• napisz własny alokator
• napisać własne międzynarodowe mapowanie

Oczywiscie uzywal dostepnych nizszych poziom bibliotek, aby to zrobić, ale to wciąż dużo pracy. Możesz zadzwonić co pozostało z programu STL? Nie wiem. myślę, że tak. std:: Klasa vector, która ostatecznie została nigdy nie było problemu i zatrzymał znalezisko funkcja. Prawie wszystko inne zniknął.

Więc, tak, można definitywnie beat the CLR. Raymond może uruchomić swój program chyba jeszcze szybciej.

Co ciekawe, czas na analizę plik zgłoszony przez oba programy wewnętrzne timery są mniej więcej takie same -- 30ms dla każdego. Różnica polega na nad głową.

Dla mnie najważniejsze jest to, że potrzeba było 6 poprawek dla wersji niezarządzanej, aby pokonać wersję zarządzaną, która była prostym portem oryginalnego niezarządzanego kodu. Jeśli potrzebujesz każdego kawałka wydajności (i masz czas i doświadczenie, aby go uzyskać), będziesz musiał przejść niezarządzane, ale dla mnie, wezmę rząd wielkości przewagę mam na pierwszych wersjach nad 33% zyskam, jeśli spróbuję 6 razy.

Kompilacje dla konkretnych optymalizacji CPU są zwykle przereklamowane. Po prostu weź program w C++ i skompiluj z optymalizacją dla pentium PRO i uruchom na pentium 4. Następnie przekompiluj za pomocą optimize for pentium 4. Spędziłem długie popołudnia robiąc to z kilkoma programami. Ogólne wyniki?? Zwykle mniej niż 2-3% wzrost wydajności. Więc teoretyczne zalety JIT są prawie żadne. Większość różnic wydajności można zaobserwować tylko przy użyciu skalarnych funkcji przetwarzania danych, coś, co w końcu będzie wymagało ręcznego precyzyjnego strojenia, aby osiągnąć maksymalną wydajność. Optymalizacje tego rodzaju są powolne i kosztowne, dzięki czemu czasami i tak nie nadają się do JIT.

W realnym świecie i rzeczywistych aplikacjach C++ jest nadal zwykle szybszy niż java, głównie ze względu na lżejsze zużycie pamięci, co skutkuje lepszą wydajnością pamięci podręcznej.

Ale aby wykorzystać wszystkie możliwości C++, programista musi ciężko pracować. Możesz osiągnąć lepsze wyniki, ale ty musisz użyć do tego mózgu. C++ jest językiem, który postanowił zaprezentować Ci więcej narzędzi, pobierając cenę, że musisz się ich nauczyć, aby móc dobrze posługiwać się tym językiem.

JIT (Just In Time Compiling) może być niesamowicie szybki, ponieważ optymalizuje platformę docelową.

Oznacza to, że może on wykorzystać każdą sztuczkę kompilatora, którą może obsługiwać Twój procesor, niezależnie od tego, na jakim procesorze programista napisał kod.

Podstawowe pojęcie JIT. NET działa tak (mocno uproszczone):

Wywołanie metody po raz pierwszy:

• Twój kod programu wywołuje metodę Foo ()
• CLR patrzy na typ, który implementuje foo() i pobiera metadane z nią związane
• z metadanych wynika, że CLR wie, w jakim adresie pamięci przechowywany jest IL (pośredni kod bajtowy).
CLR przydziela blok pamięci i wywołuje JIT.
• JIT kompiluje IL do kodu natywnego, umieszcza go w przydzielonej pamięci, a następnie zmienia wskaźnik funkcji w metadanych typu Foo (), aby wskazać ten kod natywny.
• rodzimy kod jest uruchamiany.

Wywołanie metody po raz drugi:

• Twój kod programu wywołuje metodę Foo ()
• CLR patrzy na typ implementujący foo () i znajduje wskaźnik funkcji w metadanych.
• rodzimy kod w tym miejscu pamięci jest uruchamiany.

Jak widać, za drugim razem jest to praktycznie ten sam proces co C++, z wyjątkiem zalet optymalizacji w czasie rzeczywistym.

To powiedziawszy, są jeszcze inne problemy, które spowalniają zarządzany język, ale JIT bardzo pomaga.

Podoba mi się ODPOWIEDŹ Oriona Adriana, ale jest jeszcze inny aspekt.

To samo pytanie padło kilkadziesiąt lat temu na temat języka asemblacji a "ludzkich" języków, takich jak FORTRAN. I część odpowiedzi jest podobna.

Tak, program C++ jest w stanie być szybszy od C# na dowolnym (nietrywialne?) algorytmu, ale program w C# będzie często tak szybki lub szybszy niż" naiwna " implementacja w C++, a zoptymalizowana wersja W C++ zajmie więcej czasu i może wciąż pokonaj wersję C# O bardzo mały margines. Naprawdę warto?

Będziesz musiał odpowiedzieć na to pytanie na zasadzie jeden po drugim.

To powiedziawszy, jestem od dawna fanem C++ i uważam, że jest to niesamowicie ekspresyjny i potężny język, czasami niedoceniany. Ale w wielu" realnych " problemach (dla mnie osobiście oznacza to "taki, za który mi płacą"), C# zrobi to szybciej i bezpieczniej.

Największa kara jaką płacisz? Wiele programów. NET i Java to wieprze pamięci. Widziałem, jak aplikacje. NET i Java zabierają "setki" megabajtów pamięci, podczas gdy programy C++ o podobnej złożoności ledwo drapią "dziesiątki" MBs.

Nie jestem pewien, jak często okaże się, że kod Javy będzie działał szybciej niż C++, nawet z Hotspotem, ale postaram się wyjaśnić, jak to może się stać.

Pomyśl o skompilowanym kodzie Javy jako zinterpretowanym języku maszynowym dla JVM. Gdy procesor Hotspot zauważy, że niektóre fragmenty skompilowanego kodu będą używane wiele razy, wykonuje optymalizację kodu maszynowego. Ponieważ montaż ręczny jest prawie zawsze szybszy niż skompilowany kod C++, można się domyślić ten programowo dostrojony kod maszynowy nie będzie zbyt zły.

Więc, dla bardzo powtarzalnego kodu, mogłem zobaczyć, gdzie byłoby możliwe, aby Hotspot JVM uruchamiał Javę szybciej niż C++... dopóki nie pojawi się śmieciarka. :)

Ogólnie rzecz biorąc, algorytm twojego programu będzie znacznie ważniejszy dla szybkości Twojej aplikacji niż język . Możesz zaimplementować słaby algorytm w dowolnym języku, w tym w C++. Mając to na uwadze, na ogół będziesz w stanie pisać kod szybciej w języku, który pomoże Ci zaimplementować bardziej wydajny algorytm.

Języki wyższego poziomu robią to bardzo dobrze, zapewniając łatwiejszy dostęp do wielu wydajnych wstępnie zbudowanych struktur danych i zachęcając praktyki, które pomogą Ci uniknąć nieefektywnego kodu. Oczywiście czasami mogą również ułatwić pisanie bardzo powolnego kodu, więc nadal musisz znać swoją platformę.

Ponadto, C++ dogania "nowe" (zwróć uwagę na cudzysłowy) funkcje, takie jak kontenery STL, automatyczne wskaźniki itp. - zobacz na przykład bibliotekę boost. I czasami może się okazać, że najszybszy sposób wykonania jakiegoś zadania wymaga techniki, takiej jak arytmetyka wskaźnikowa, która jest zabroniona w język wyższego poziomu-chociaż typowo pozwalają na wywołanie biblioteki napisanej w języku, który może ją zaimplementować zgodnie z życzeniem.

Najważniejsze jest znać język, którego używasz, powiązane z nim API, co może zrobić i jakie są jego ograniczenia.

Nie wiem either...my Programy Java są zawsze wolne. :- ) Nigdy nie zauważyłem, że programy C# są szczególnie powolne.

Oto kolejny ciekawy benchmark, który możesz wypróbować samodzielnie na własnym komputerze.

Porównuje ASM, VC++, C#, Silverlight, aplet Java, Javascript, Flash (AS3)

Roozz plugin speed demo

Należy pamiętać, że szybkość javascript różni się znacznie w zależności od tego, jaka przeglądarka go wykonuje. To samo dotyczy Flasha i Silverlight, ponieważ te wtyczki działają w tym samym procesie, co przeglądarka hostingowa. Ale wtyczka Roozz działa standardowo .pliki exe, które działają we własnym procesie, a więc na szybkość nie ma wpływu przeglądarka hostingowa.

Powinieneś zdefiniować " wykonaj lepiej niż..". Wiem, pytałeś o szybkość, ale to nie wszystko się liczy.

• Czy maszyny wirtualne wykonują więcej zadań związanych z uruchomieniem? Tak!
Czy jedzą więcej pamięci roboczej? Tak!
• czy mają wyższe koszty uruchamiania (inicjalizacja runtime i kompilator JIT)? Tak!
• czy wymagają zainstalowania ogromnej biblioteki? Tak!

I tak dalej, to stronnicze, tak;)

Z C# i Java płacisz cenę za to, co get (szybsze kodowanie, automatyczne zarządzanie pamięcią, duża biblioteka i tak dalej). Ale nie masz zbyt wiele miejsca na targowanie się o szczegóły: weź kompletny pakiet lub nic.

Nawet jeśli te języki potrafią zoptymalizować część kodu, aby wykonać go szybciej niż skompilowany kod, całe podejście jest (IMHO) nieefektywne. Wyobraź sobie, że codziennie jeździsz 5 mil do swojego miejsca pracy, ciężarówką! Jest wygodny, czuje się dobrze ,jesteś bezpieczny (ekstremalna Strefa zgniotu), a po tym, jak przez jakiś czas staniesz na gazie, nawet Bądź szybki jak standardowy samochód! Dlaczego wszyscy nie mamy ciężarówki do jazdy do pracy? ;)

W C++ dostajesz to, za co płacisz, nie więcej, nie mniej.

Cytując Bjarne Stroustrupa: "C++ jest moim ulubionym językiem zbieranym ze śmieci, ponieważ generuje tak mało śmieci" link text

Kod wykonywalny wytworzony z kompilatora Javy lub C# nie jest interpretowany - jest kompilowany do kodu natywnego" just in time " (JIT). Tak więc, gdy pierwszy kod w programie Java/C# zostanie napotkany podczas wykonywania, istnieje pewien narzut, ponieważ "kompilator uruchomieniowy" (aka kompilator JIT) zamienia kod bajtowy (Java) lub kod IL (C#) w natywne instrukcje maszynowe. Jednak następnym razem, gdy ten kod zostanie napotkany, gdy aplikacja jest nadal uruchomiona, kod macierzysty jest wykonywany natychmiast. To wyjaśnia, w jaki sposób niektóre programy Java/C# wydają się początkowo wolne, ale potem działają lepiej im dłużej działają. Dobrym przykładem jest ASP.Net strona www. Przy pierwszym wejściu na stronę WWW może być nieco wolniej, ponieważ kod C# jest kompilowany do kodu natywnego przez kompilator JIT. Kolejne wejścia skutkują znacznie szybszym buforowaniem strony internetowej-serwera i klienta.

Kilka dobrych odpowiedzi na konkretne pytanie, które zadałeś. Chciałbym się cofnąć i spojrzeć z szerszej perspektywy.

Należy pamiętać, że na postrzeganie prędkości pisanego przez użytkownika oprogramowania wpływa wiele innych czynników, niż tylko optymalizacja codegen. Oto kilka przykładów:

• Ręczne zarządzanie pamięcią jest trudne do zrobienia poprawnie (brak przecieków), a jeszcze trudniejsze do zrobienia skutecznie(wolna pamięć wkrótce po zakończeniu z nim). Korzystanie z GC jest, w ogólnie rzecz biorąc, bardziej prawdopodobne jest stworzenie programu, który dobrze zarządza pamięcią. Czy jesteś gotów bardzo ciężko pracować i opóźniać dostarczanie swojego oprogramowania, próbując przebić się do GC?

• Mój C# jest łatwiejszy do odczytania i zrozumienia niż mój C++. Mam też więcej sposobów, aby przekonać się, że mój kod C# działa poprawnie. Oznacza to, że mogę zoptymalizować moje algorytmy z mniejszym ryzykiem wprowadzenia błędów (a użytkownicy nie lubią oprogramowania, które ulega awarii, nawet jeśli robi to szybko!)

• Mogę twórz moje oprogramowanie szybciej w C# niż w C++. Pozwala to zaoszczędzić czas na pracę nad wydajnością i nadal dostarczać moje oprogramowanie na czas.

• Łatwiej jest napisać dobry interfejs użytkownika w C# niż C++, więc jestem bardziej prawdopodobne, że będę w stanie wypchnąć pracę w tle, podczas gdy interfejs pozostaje responsywny, lub zapewnić postęp lub hearbeat UI, gdy program musi zablokować na chwilę. To nie czyni niczego szybszym, ale sprawia, że użytkownicy są szczęśliwsi z czekania.

Wszystko co powiedziałem O C # jest prawdopodobnie prawda dla Javy, po prostu nie mam doświadczenia, aby powiedzieć na pewno.

Jeśli jesteś programistą Java / C# uczącym się C++, będziesz miał ochotę myśleć w kategoriach Java/C# i przetłumaczyć dosłownie na składnię C++. W takim przypadku dostajesz tylko wspomniane wcześniej zalety kodu natywnego vs. interpretowanego/JIT. Aby uzyskać największy wzrost wydajności w C++ vs. Java / C#, musisz nauczyć się myśleć w C++ i projektować kod specjalnie po to, aby wykorzystać mocne strony C++.

Parafrazując Edsger Dijkstra : [twój pierwszy język] okalecza umysł ponad powrót do zdrowia.
Parafrazując Jeff Atwood : możesz napisać [swój pierwszy język] w każdym nowym języku.

Jedną z najważniejszych optymalizacji JIT jest metoda inlining. Java może nawet wbudowywać metody wirtualne, jeśli gwarantuje poprawność działania. Tego typu optymalizacja zwykle nie może być wykonywana przez standardowe Kompilatory statyczne, ponieważ wymaga analizy całego programu, co jest trudne z powodu oddzielnej kompilacji (w przeciwieństwie do JIT ma cały program dostępny dla niego). Metoda inlining poprawia inne optymalizacje, dając większe bloki kodu do optymalizacji.

Pamięć Standardowa alokacja w Javie / C# jest również szybsza, a dealokacja (GC) nie jest dużo wolniejsza, ale tylko mniej deterministyczna.

Języki maszyn wirtualnych są mało prawdopodobne, aby przewyższyć języki skompilowane, ale mogą zbliżyć się na tyle, że nie ma to znaczenia, z (przynajmniej) następujących powodów(mówię tu w imieniu Javy, ponieważ nigdy nie robiłem C#).

1 / środowisko Java Runtime Environment jest zwykle w stanie wykryć często uruchamiane fragmenty kodu i wykonać kompilację just-In-time (JIT)tych sekcji, aby w przyszłości mogły działać z pełną prędkością kompilacji.

2/ biblioteki są kompilowane tak, że wywołując funkcję biblioteczną, wykonujesz skompilowany kod, a nie zinterpretowany. Możesz zobaczyć kod (w C) pobierając OpenJDK.

3 / chyba, że robisz masowe obliczenia, przez większość czasu twój program jest uruchomiony, czeka na wejście od bardzo powolnego (stosunkowo) człowieka.

4 / ponieważ Walidacja kodu bajtowego Javy jest wykonywana w czasie ładowania klasy, normalny narzut kontroli runtime jest znacznie zmniejszona.

5 / w najgorszym przypadku, wydajnościowy kod może być wyodrębniony do skompilowanego modułu i wywołany z Javy (patrz JNI), aby działał z pełną prędkością.

Podsumowując, kod bajtowy Javy nigdy nie przewyższy natywnego języka maszynowego, ale istnieją sposoby, aby to złagodzić. Dużą zaletą Javy (jak widzę) jest ogromna biblioteka standardowa oraz charakter wieloplatformowy.

Orion Adrian , pozwól, że odwrócę twój post, aby zobaczyć, jak bezpodstawne są Twoje uwagi, ponieważ wiele można powiedzieć również o C++. I mówienie, że kompilator Java/C# optymalizuje puste funkcje naprawdę sprawia, że brzmisz jakbyś był a nie moim ekspertem w optymalizacji, ponieważ a) dlaczego prawdziwy program powinien zawierać puste funkcje, z wyjątkiem naprawdę złego kodu, b) to naprawdę nie jest optymalizacja czarnych i krwawych krawędzi.

Poza tym frazą, krzyczałeś rażąco o wskaźnikach, ale czy obiekty w Javie i C# w zasadzie nie działają jak wskaźniki C++? Czy mogą się nie pokrywać? Czy nie mogą być zerowe? C (i większość implementacji C++) ma słowo kluczowe restrict, oba mają typy wartości, C++ ma odniesienie do wartości z gwarancją non-null. Co oferują Java i C#?

>>>>>>>>>>

Ogólnie Rzecz Biorąc, C i C++ mogą być równie szybkie lub szybsze, ponieważ kompilator AOT - kompilator, który kompiluje kod przed wdrożeniem, raz na zawsze, na wysokiej pamięci wielu core build server -- może tworzyć optymalizacje, których skompilowany program C# nie może, ponieważ ma na to mnóstwo czasu. Kompilator może określić, czy komputer jest Intel lub AMD; Pentium 4, Core Solo lub Core Duo; lub czy obsługuje SSE4, itp., a jeśli twój kompilator nie obsługuje wysyłania w trybie runtime, możesz rozwiązać to samodzielnie, instalując kilka wyspecjalizowanych plików binarnych.

Program C# jest zwykle kompilowany po uruchomieniu go tak, że działa przyzwoicie dobrze na wszystkich maszynach, ale nie jest zoptymalizowany na tyle, na ile to tylko możliwe dla pojedynczej konfiguracji (np. procesora, zestawu instrukcji, innego sprzętu), a musi najpierw poświęcić trochę czasu. Funkcje takie jak rozszczepienie pętli, inwersja pętli, automatyczna wektoryzacja, optymalizacja całego programu, rozszerzenie szablonu, IPO i wiele innych, są bardzo trudne do rozwiązania w sposób, który nie denerwuje użytkownika końcowego.

DODATKOWO pewne cechy języka pozwalają kompilatorowi w C++ lub C na kod, który pozwala na optymalizację pewnych części, które po prostu nie są bezpieczne dla kompilatora Java/C#. Gdy nie masz dostępu do pełnego identyfikatora typów leków generycznych lub gwarantowanego przepływu programu, istnieje wiele optymalizacji, które po prostu nie są bezpieczne.

Również C++ i C robią wiele przydziałów stosu na raz z tylko jednym przyrostem rejestru, co z pewnością jest bardziej efektywne niż przydziały Java i C#, jeśli chodzi o warstwę abstrakcji między garbage collector a Twoim kodem.

Teraz Nie mogę mówić w imieniu Javy w tym następnym punkcie, ale wiem, że kompilatory C++ rzeczywiście usuwają metody i wywołania metod, gdy wie, że ciało metody jest puste, eliminuje typowe podwyrażenia, może próbować ponownie znaleźć optymalne użycie rejestru, nie wymusza sprawdzania granic, będzie autowektoryzować pętle i pętle wewnętrzne i odwróci wewnętrzne do zewnętrznych, przesuwa warunkowe z pętli, dzieli i rozdziela pętle. Rozszerzy std:: vector do natywnego zera macierze napowietrzne, jak byś zrobił drogę C. Będzie to między procesowe optymalizacje. Będzie konstruować wartości zwrotne bezpośrednio w miejscu wywołującym. Będzie składać i propagować wyrażenia. Zmieni kolejność danych w sposób przyjazny dla pamięci podręcznej. To zrobi skok threading. Pozwala na zapisywanie znaczników czasu kompilacji z zerowym obciążeniem czasowym. Spowoduje to bardzo kosztowne optymalizacje oparte na wykresach. Zmniejszy siłę, jeśli zastąpi pewne kody składniowo całkowicie nierówne, ale kod semantycznie równoważny (Stary "XOR foo, foo" jest najprostszą, choć przestarzałą optymalizacją tego typu). Jeśli o to poprosisz, możesz pominąć standardy zmiennoprzecinkowe IEEE i włączyć jeszcze więcej optymalizacji, takich jak ponowne zamawianie operandów zmiennoprzecinkowych. Po zmasakrowaniu i zmasakrowaniu kodu może on powtórzyć cały proces, ponieważ często pewne optymalizacje stanowią fundament dla jeszcze bardziej pewnych optymalizacji. Może również po prostu spróbować ponownie z parametrami tasowanymi i zobaczyć, jak Inne wyniki wariantowe w swoim wewnętrznym rankingu. I będzie używać tego rodzaju logiki w całym kodzie.

Więc jak widzisz, istnieje wiele powodów, dla których niektóre implementacje C++ lub C będą szybsze.

Teraz to wszystko powiedziane, wiele optymalizacji może być wykonane w C++, które zdmuchnie wszystko, co można zrobić z C#, zwłaszcza w liczbie crunching, realtime I close-to-metal sfery, ale nie tylko tam. Nie musisz nawet dotykać ani jednego wskaźnika, aby przyjść długo sposób.

W zależności od tego, co piszesz, wybrałbym jedno lub drugie. Ale jeśli piszesz coś, co nie jest zależne od sprzętu (sterownik, gra wideo itp.), nie martwiłbym się o wydajność C# (znowu nie mogę mówić o Javie). Będzie dobrze.

Ogólnie rzecz biorąc, niektóre uogólnione argumenty mogą brzmieć fajnie w konkretnych postach, ale generalnie nie brzmią na pewno wiarygodnie.

W każdym razie, aby zawrzeć pokój: AOT jest świetnie, tak jak JIT . Jedyną poprawną odpowiedzią może być: to zależy. A prawdziwi mądrzy ludzie wiedzą, że można korzystać z najlepszych z obu światów tak czy inaczej.

Może się to zdarzyć tylko wtedy, gdy interpreter Javy tworzy kod maszynowy, który jest w rzeczywistości lepiej zoptymalizowany niż kod maszynowy generowany przez kompilator dla kodu C++, który piszesz, do tego stopnia, że kod C++ jest wolniejszy niż Java i koszt interpretacji.

Jednak szanse na to są dość niskie-chyba że Java ma bardzo dobrze napisaną bibliotekę, a Ty masz własną źle napisaną bibliotekę C++.

Właściwie, C# tak naprawdę nie działa na maszynie wirtualnej jak Java. IL jest kompilowany do języka assembly, który jest w całości kodem natywnym i działa z taką samą prędkością jak kod natywny. Możesz pre-JIT aplikacji. NET, która całkowicie usuwa koszt JIT, a następnie uruchamiasz całkowicie natywny kod.

Spowolnienie z. NET nastąpi nie dlatego, że kod. NET jest wolniejszy, ale dlatego, że robi o wiele więcej za kulisami, aby robić rzeczy takie jak garbage collect, sprawdź referencje, przechowuj kompletne ramki stosu itp. Może to być dość potężne i pomocne podczas budowania aplikacji, ale wiąże się również z kosztami. Zauważ, że wszystkie te rzeczy możesz robić również w programie C++ (większość podstawowej funkcjonalności. NET to tak naprawdę kod. NET, który możesz przeglądać w ROTOR). Jeśli jednak ręcznie napisałeś tę samą funkcjonalność, prawdopodobnie skończyłbyś z znacznie wolniejszym programem, ponieważ środowisko wykonawcze. NET zostało zoptymalizowane i precyzyjnie dostrojone.

To jedna z mocnych stron zarządzanego kodu jest to, że może być w pełni weryfikowalne, tj. możesz sprawdzić, czy kod nigdy nie uzyska dostępu do pamięci innych procesów lub nie zrobi niczego, zanim go wykonasz. Microsoft ma prototyp badawczy w pełni zarządzanego systemu operacyjnego, który zaskakująco pokazał, że środowisko zarządzane w 100% może działać znacznie szybciej niż jakikolwiek nowoczesny system operacyjny, korzystając z tej weryfikacji, aby wyłączyć funkcje zabezpieczeń, które nie są już potrzebne w zarządzanych programach (mówimy o jak 10x w niektórych przypadkach). SE radio ma świetny odcinek mówiący o tym projekcie.

W niektórych przypadkach kod zarządzany może być w rzeczywistości szybszy niż kod natywny. Na przykład algorytmy zbierania śmieci typu "mark-and-sweep" pozwalają środowiskom takim jak JRE lub CLR na zwolnienie dużej liczby krótkotrwałych (Zwykle) obiektów w jednym przejściu, gdzie większość obiektów C / C++ jest zwalniana pojedynczo.

From wikipedia :

W wielu praktycznych celach algorytmy alokacji / dealokacji zaimplementowane w językach zbieranych ze śmieci mogą w rzeczywistości być szybsze niż ich odpowiedniki przy użyciu ręcznego przydziału sterty. Głównym powodem tego jest to, że garbage collector pozwala systemowi uruchomieniowemu amortyzować operacje alokacji i dealokacji w potencjalnie korzystny sposób.

To powiedziawszy, napisałem dużo C# i dużo C++, i uruchomiłem wiele benchmarków. Z mojego doświadczenia wynika, że C++ jest dużo szybszy od C#, na dwa sposoby: (1) jeśli weźmiesz jakiś kod, który napisałeś w C#, przenieś go do C++ macierzystego kodu ma tendencję do bycia szybszym. O ile szybciej? Cóż, to bardzo się różni, ale nie jest rzadkością, aby zobaczyć 100% poprawę prędkości. (2) w niektórych przypadkach usuwanie śmieci może masowo spowolnić zarządzaną aplikację. CLR. NET robi straszną robotę z dużymi stosami (powiedzmy > 2GB)i może skończyć się spędzaniem dużo czasu w GC-nawet w aplikacjach, które mają niewiele-lub nawet nie-obiektów o pośrednim okresie życia.

Oczywiście w większości przypadków, z którymi się zetknąłem, języki zarządzane są wystarczająco szybko, na dłuższą metę, a konserwacja i kodowanie kompromisu dla dodatkowej wydajności C++ nie jest po prostu dobry.

Oto ciekawy benchmark http://zi.fi/shootout/

W rzeczywistości HotSpot JVM firmy Sun używa wykonania "mixed-mode". Interpretuje kod bajtowy metody, dopóki nie określi (zwykle za pomocą pewnego rodzaju licznika), że dany blok kodu (metoda, pętla, blok try-catch, itp.) będzie wykonywany bardzo często, potem będzie kompilowany. Czas wymagany do kompilacji metody JIT często trwa dłużej niż w przypadku, gdy metoda miała być zinterpretowana, jeśli jest to metoda rzadko uruchamiana. Wydajność jest zwykle wyższa w przypadku "trybu mieszanego", ponieważ JVM nie marnuje czas JITing kod, który jest rzadko, jeśli w ogóle, uruchomić. C # i. NET tego nie robią. . NET JITs wszystko, co, często razy, marnuje czas.

Idź poczytaj o HP Labs ' Dynamo , interpreterze dla PA-8000, który działa na PA-8000 i często uruchamia programy szybciej niż robią to natywnie. Wtedy nie będzie to wcale zaskakujące!

Nie myśl o tym jako o "pośrednim kroku" - uruchamianie programu obejmuje już wiele innych kroków, w dowolnym języku.

Często sprowadza się do:

• Programy mają hot-spoty, więc nawet jeśli wolniej uruchamiasz 95% kodu, który musisz uruchomić, nadal możesz być wydajność-konkurencyjne, jeśli jesteś szybszy w gorącej 5%

• HLL wie więcej o twoim zamiarze niż LLL jak C / C++, a więc może generować bardziej zoptymalizowany kod (OCaml ma jeszcze więcej, a w praktyce często jest jeszcze szybszy)

• Kompilator JIT zawiera wiele informacji, których kompilator statyczny nie ma (np. rzeczywiste dane, które akurat masz w tym czasie)

• Kompilator JIT może zrobić optymalizacje w czasie wykonywania, że tradycyjne linkery nie są naprawdę dozwolone do (np. zmiana kolejności gałęzi tak, aby zwykły przypadek był płaski, lub inlining wywołań biblioteki)

Podsumowując, C / C++ są dość kiepskimi językami pod względem wydajności: jest stosunkowo mało informacji o typach danych, Brak informacji o danych i brak dynamicznego środowiska wykonawczego, aby umożliwić wiele w drodze optymalizacji czasu pracy.

Gdy Java lub CLR jest szybsze niż C++, możesz uzyskać krótkie serie, ale ogólnie wydajność jest gorsza przez cały okres użytkowania aplikacji: Zobacz też www.codeproject.com/KB/dotnet/RuntimePerformance.aspx dla niektórych wyników za to.

Oto odpowiedź od Cliff Click: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

Rozumiem, że C / C++ tworzy natywny kod do działania na konkretnej architekturze maszyny. Odwrotnie, języki takie jak Java i C# działają na maszynie wirtualnej, która abstrakuje natywną architekturę. Logicznie wydaje się, że Java lub C# nie mogą dopasować prędkości C++ z powodu tego pośredniego kroku, jednak powiedziano mi, że najnowsze Kompilatory ("hot spot") mogą osiągnąć tę prędkość lub nawet ją przekroczyć.

Być może jest to bardziej pytanie kompilatora niż pytanie językowe, ale czy ktoś może wyjaśnić w prostym języku angielskim, w jaki sposób jeden z tych języków maszyn wirtualnych może działać lepiej niż język ojczysty?

Tutaj oto kilka przykładów:

• Maszyny wirtualne z kompilacją JIT ułatwiają generowanie kodu w czasie wykonywania (np. System.Reflection.Emit Na. NET), więc możesz kompilować wygenerowany kod w locie w językach takich jak C # i F# , ale musisz uciekać się do pisania stosunkowo wolnego interpretera w C lub c++. Na przykład, aby zaimplementować wyrażenia regularne.

• Części maszyny wirtualnej (np. bariera zapisu i alokator) są często pisane ręcznie asemblerem, ponieważ C i c++ nie generują wystarczająco szybki kod. Jeśli program podkreśla te części systemu, to może być prawdopodobne, że przewyższy wszystko, co może być napisane w C lub c++.

• Dynamiczne łączenie kodu natywnego wymaga zgodności z ABI, które może utrudniać wydajność i eliminuje optymalizację całego programu, podczas gdy łączenie jest zwykle odroczone na maszynach wirtualnych i może korzystać z optymalizacji całego programu(jak reified generics. NET).

Chciałbym również odnieść się do niektórych problemów z paercebal ' s wysoce upvoted odpowiedź powyżej (bo ktoś ciągle kasuje Moje komentarze na jego odpowiedź), która przedstawia przeciwproduktywnie spolaryzowany widok: {]}

Przetwarzanie kodu zostanie wykonane w czasie kompilacji...

Stąd metaprogramowanie szablonów działa tylko wtedy, gdy program jest dostępny w czasie kompilacji, co często nie ma miejsca, np. nie można napisać konkurencyjnej biblioteki wyrażeń regularnych w vanilla C++, ponieważ nie jest w stanie wygenerować kodu w czasie wykonywania (ważny aspekt metaprogramowania).

...zabawa z typami odbywa się w czasie kompilacji...odpowiednik w Javie lub C# jest co najwyżej bolesny w pisaniu i zawsze będzie wolniejszy i rozwiązany w czasie wykonywania, nawet jeśli typy są znane w czasie kompilacji.

W C# jest to prawda tylko dla typów referencyjnych i nie jest prawdą dla typów wartości.

Bez względu na optymalizację JIT, nic nie pójdzie tak szybko, jak bezpośredni dostęp wskaźnika do pamięci...jeśli masz dane sąsiadujące ze sobą w pamięci, dostęp do niej poprzez wskaźniki C++ (tj. wskaźniki C... Dajmy Cezarowi jego należność) pójdzie razy szybciej niż w Javie / C#.

Ludzie zauważyli , że Java pokonuje C++ W teście SOR z benchmarka SciMark2 właśnie dlatego, że wskaźniki utrudniają optymalizacje związane z aliasingiem.

Warto również zauważyć, że. NET typuje specjalizacje generyczne pomiędzy dynamicznie linkowanymi bibliotekami po połączeniu, podczas gdy C++ nie może, ponieważ szablony muszą być rozwiązane przed linkowanie. I oczywiście dużą przewagą generyków nad szablonami są zrozumiałe komunikaty o błędach.

Poza tym, co powiedzieli inni, z mojego zrozumienia. NET i Java są lepsze w alokacji pamięci. Np. mogą kompaktować pamięć, ponieważ jest ona fragmentowana, podczas gdy C++ nie może (natywnie, ale może, jeśli używasz sprytnego garbage collector).

Dla wszystkiego, co wymaga dużej prędkości, JVM po prostu wywołuje implementację C++, więc jest to pytanie bardziej o to, jak dobre są ich biblioteki niż jak dobre jest JVM dla większości rzeczy związanych z systemem operacyjnym. Garbage collection tnie twoją pamięć o połowę, ale korzystanie z niektórych funkcji fancier STL i Boost będzie miało ten sam efekt, ale z wielokrotnie większym potencjałem błędu.

Jeśli używasz tylko bibliotek C++ i wielu jego funkcji wysokiego poziomu w dużym projekcie z wieloma klasami, prawdopodobnie skończysz wolniej niż przy użyciu JVM. Z wyjątkiem znacznie bardziej podatnych na błędy.

Jednak zaletą C++ jest to, że pozwala na optymalizację siebie, w przeciwnym razie utkniesz z tym, co robi kompilator / jvm. Jeśli tworzysz własne kontenery, piszesz własne zarządzanie pamięcią, które jest wyrównane, używasz SIMD i upuszczasz do montażu tu i tam, możesz przyspieszyć co najmniej 2x-4x razy w porównaniu z tym, co większość kompilatorów C++ zrobi sama. Dla niektórych operacji, 16x-32x. to przy użyciu tych samych algorytmów, jeśli używasz lepiej algorytmy i równoległe, wzrosty mogą być dramatyczne, czasami tysiące razy szybsze niż powszechnie stosowane metody.

Patrzę na to z kilku różnych punktów.

1. biorąc pod uwagę nieskończony czas i zasoby, czy zarządzany lub niezarządzany kod będzie szybszy? Oczywiście odpowiedź jest taka, że kod niezarządzany zawsze może przynajmniej powiązać kod zarządzany w tym aspekcie - tak jak w najgorszym przypadku, po prostu zakodujesz rozwiązanie zarządzanego kodu.
2. jeśli weźmiesz program w jednym języku i przetłumaczysz go bezpośrednio na inny, o ile gorszy będzie on działał? Prawdopodobnie dużo, dla dowolnych dwóch języków. Większość języków wymagają różnych optymalizacji i mają różne Gotcha. Micro-performance często polega na poznaniu tych szczegółów.
3. biorąc pod uwagę skończony czas i zasoby, który z dwóch języków da lepszy wynik? Jest to najciekawsze pytanie, ponieważ o ile język zarządzany może wytwarzać nieco wolniejszy kod (biorąc pod uwagę, że program jest w miarę dobrze napisany dla tego języka), Ta wersja prawdopodobnie zostanie wykonana wcześniej, co pozwoli na więcej czasu poświęconego na optymalizację.

Bardzo krótka odpowiedź: przy ustalonym budżecie osiągniesz lepszą wydajność aplikacji java niż aplikacji C++ (Roi considerations) ponadto Platforma Java ma bardziej przyzwoite profilery, które pomogą Ci szybciej zlokalizować swoje hotspoty