O ile szybszy jest C ++ niż C #?

Czy jest teraz na odwrót?

Z tego, co słyszałem, jest kilka obszarów, w których C # okazuje się być szybszy niż C ++, ale nigdy nie miałem odwagi przetestować go samodzielnie.

Pomyślałem, że każdy z was może szczegółowo wyjaśnić te różnice lub wskazać mi właściwe miejsce na informacje na ten temat.

Nie ma ścisłego powodu, dla którego język oparty na bajtach, taki jak C # lub Java, który ma JIT, nie może być tak szybki jak kod C ++. Jednak kod C ++ był przez długi czas znacznie szybszy, a także dzisiaj jest w wielu przypadkach. Wynika to głównie z tego, że bardziej zaawansowane są optymalizacje JIT, których wdrożenie jest skomplikowane, a te naprawdę fajne pojawiają się dopiero teraz.

Więc C ++ jest szybszy, w wielu przypadkach. Ale to tylko część odpowiedzi. Przypadki, w których C ++ jest rzeczywiście szybszy, to wysoce zoptymalizowane programy, w których eksperci programiści gruntownie zoptymalizowali kod. Jest to nie tylko bardzo czasochłonne (a przez to kosztowne), ale często prowadzi do błędów z powodu nadmiernej optymalizacji.

Z drugiej strony, kod w tłumaczonych językach przyspiesza w późniejszych wersjach środowiska uruchomieniowego (.NET CLR lub Java VM), bez żadnego działania. Istnieje wiele przydatnych optymalizacji kompilatorów JIT, które są po prostu niemożliwe w językach ze wskaźnikami. Ponadto niektórzy twierdzą, że zbieranie śmieci powinno być na ogół tak szybkie lub szybsze jak ręczne zarządzanie pamięcią, aw wielu przypadkach tak jest. Możesz to wszystko zaimplementować i osiągnąć w C ++ lub C, ale będzie to znacznie bardziej skomplikowane i podatne na błędy.

Jak powiedział Donald Knuth, „przedwczesna optymalizacja jest źródłem wszelkiego zła”. Jeśli naprawdę wiesz na pewno, że twoja aplikacja będzie się składać głównie z arytmetyki krytycznej pod względem wydajności i że będzie wąskim gardłem, a na pewno będzie szybsza w C ++, i masz pewność, że C ++ nie będzie kolidować z innymi wymagania, przejdź do C ++. W każdym innym przypadku skoncentruj się na prawidłowym wdrożeniu aplikacji w języku, który najbardziej Ci odpowiada, a następnie znajdź wąskie gardła wydajności, jeśli działa ona zbyt wolno, a następnie pomyśl o tym, jak zoptymalizować kod. W najgorszym przypadku może być konieczne wywołanie kodu C za pośrednictwem obcego interfejsu funkcji, więc nadal będziesz mieć możliwość pisania krytycznych części w języku niższego poziomu.

Pamiętaj, że stosunkowo łatwo jest zoptymalizować poprawny program, ale znacznie trudniej jest poprawić zoptymalizowany program.

Podanie rzeczywistych procentowych korzyści prędkości jest niemożliwe, w dużej mierze zależy od twojego kodu. W wielu przypadkach implementacja języka programowania nie jest nawet wąskim gardłem. Przyjmij testy porównawcze na stronie http://benchmarksgame.alioth.debian.org/ z dużym sceptycyzmem, ponieważ w dużej mierze testują one kod arytmetyczny, który najprawdopodobniej wcale nie jest podobny do twojego kodu.

C # może nie być szybszy, ale sprawia, że ​​TY / MNIE szybciej. To najważniejsza miara tego, co robię. :)

Jest pięć pomarańczy szybciej. Lub raczej: nie może być (poprawnej) ogólnej odpowiedzi. C ++ jest językiem kompilowanym statycznie (ale jest też optymalizacja kierowana profilem), C # działa wspomagany przez kompilator JIT. Jest tak wiele różnic, że na pytania typu „o ile szybciej” nie można odpowiedzieć, nawet przez podanie rzędów wielkości.

Zacznę od tego, że nie zgadzam się z częścią zaakceptowanej (i dobrze ocenionej) odpowiedzi na to pytanie, stwierdzając:

Istnieje wiele powodów, dla których kod JITted będzie działał wolniej niż odpowiednio zoptymalizowany program C ++ (lub inny język bez narzutów), w tym:

• cykle obliczeniowe spędzone na kodzie JITting w czasie wykonywania są z definicji niedostępne do użycia podczas wykonywania programu.

• wszelkie ścieżki dostępu w JITter będą konkurować z twoim kodem o instrukcje i pamięć podręczną danych w CPU. Wiemy, że pamięć podręczna dominuje pod względem wydajności, a języki rodzime, takie jak C ++, z definicji nie mają tego rodzaju rywalizacji.

• budżet czasowy optymalizatora czasu działania jest z konieczności znacznie bardziej ograniczony niż budżet optymalizatora czasu kompilacji (jak zauważył inny komentator)

Konkluzja: W ostatecznym rozrachunku, to będzie prawie na pewno będzie w stanie stworzyć szybszą realizację w C ++ niż można w C # .

To powiedziawszy, o ile szybciej tak naprawdę nie da się kwantyfikować, ponieważ istnieje zbyt wiele zmiennych: zadanie, dziedzina problemów, sprzęt, jakość implementacji i wiele innych czynników. Przeprowadzisz testy swojego scenariusza, aby określić różnicę w wydajności, a następnie zdecydujesz, czy warto dodatkowy wysiłek i złożoność.

Jest to bardzo długi i złożony temat, ale uważam, że warto wspomnieć ze względu na kompletność, że optymalizator środowiska wykonawczego C # jest doskonały i jest w stanie przeprowadzić pewne dynamiczne optymalizacje w czasie wykonywania, które po prostu nie są dostępne dla C ++ ze względu na czas kompilacji ( statyczny) optymalizator. Mimo to przewaga jest zwykle głęboko w sądzie natywnej aplikacji, ale dynamiczny optymalizator jest przyczyną „ prawie podanego wyżej kwalifikatora pewno”.

-

Jeśli chodzi o względną wydajność, niepokoiły mnie również liczby i dyskusje, które widziałem w innych odpowiedziach, więc pomyślałem, że włączy się i jednocześnie zapewnię wsparcie dla oświadczeń, które wypowiedziałem powyżej.

Ogromną częścią problemu z tymi testami porównawczymi jest to, że nie możesz napisać kodu C ++ tak, jakbyś pisał w C # i spodziewał się uzyskania reprezentatywnych wyników (np. Wykonanie tysięcy alokacji pamięci w C ++ da ci straszne liczby).

Zamiast tego napisałem nieco więcej idiomatycznego kodu C ++ i porównałem go z podanym kodem C # @Wiory. Dwie główne zmiany, które wprowadziłem w kodzie C ++ to:

1) używany wektor :: Reserve ()

2) spłaszczono tablicę 2d do 1d, aby uzyskać lepszą lokalizację pamięci podręcznej (ciągły blok)

C # (.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

Czas pracy (Release): Init: 124ms, Fill: 165ms

C ++ 14 (Clang v3.8 / C2)

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

Czas pracy (wydanie): Init: 398µs (tak, to mikrosekundy), Fill: 152ms

Całkowity czas pracy: C #: 289ms, C ++ 152ms (około 90% szybciej)

Spostrzeżenia

• Zmiana implementacji C # na tę samą implementację tablicy 1d dała Init: 40ms, Fill: 171ms, Total: 211ms ( C ++ był wciąż prawie 40% szybszy ).

• Znacznie trudniej jest zaprojektować i napisać „szybki” kod w C ++ niż napisać „zwykły” kod w dowolnym języku.

• Zadziwiająco łatwo jest uzyskać słabą wydajność w C ++; widzieliśmy to przy niezastrzeżonej wydajności wektorów. I jest wiele takich pułapek.

• Wydajność C # jest raczej niesamowita, jeśli wziąć pod uwagę wszystko, co dzieje się w czasie wykonywania. Ta wydajność jest stosunkowo łatwo dostępna.

• Więcej niepotwierdzonych danych porównujących wydajność C ++ i C #: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

Najważniejsze jest to, że C ++ daje znacznie większą kontrolę nad wydajnością. Czy chcesz użyć wskaźnika? Referencja? Pamięć stosu? Sterta? Dynamiczny polimorfizm czy wyeliminować obciążenie środowiska wykonawczego vtable ze statycznym polimorfizmem (poprzez szablony / CRTP)? W C ++ musisz ... er, dostać się dołożenia wszelkich tych wyborów (i więcej) samemu, najlepiej tak, że najlepsze rozwiązanie odnosi się do problemu jesteś Walka.

Zadaj sobie pytanie, czy naprawdę chcesz lub potrzebujesz tej kontroli, ponieważ nawet w powyższym trywialnym przykładzie widać, że chociaż istnieje znaczna poprawa wydajności, dostęp do niej wymaga głębszej inwestycji.

Z mojego doświadczenia (i dużo pracowałem w obu językach), głównym problemem w C # w porównaniu do C ++ jest wysokie zużycie pamięci i nie znalazłem dobrego sposobu na kontrolowanie tego. To zużycie pamięci ostatecznie spowolniło oprogramowanie .NET.

Innym czynnikiem jest to, że kompilator JIT nie może sobie pozwolić na zbyt wiele czasu na zaawansowane optymalizacje, ponieważ działa w czasie wykonywania, a użytkownik końcowy zauważyłby go, jeśli zajmie to zbyt dużo czasu. Z drugiej strony, kompilator C ++ ma cały czas potrzebny na optymalizacje w czasie kompilacji. Ten czynnik jest znacznie mniej istotny niż zużycie pamięci, IMHO.

Jeden szczególny scenariusz, w którym C ++ nadal ma przewagę (i będzie, przez wiele lat) ma miejsce, gdy decyzje polimorficzne mogą być z góry określone w czasie kompilacji.

Ogólnie rzecz biorąc, enkapsulacja i odroczenie decyzji jest dobrą rzeczą, ponieważ sprawia, że ​​kod jest bardziej dynamiczny, łatwiejszy do dostosowania do zmieniających się wymagań i łatwiejszy w użyciu jako framework. Dlatego programowanie obiektowe w języku C # jest bardzo produktywne i można je uogólnić pod pojęciem „uogólnienie”. Niestety ten szczególny rodzaj uogólnienia wiąże się z pewnym kosztem w czasie wykonywania.

Zwykle koszt ten nie jest znaczny, ale istnieją aplikacje, w których narzut wirtualnych wywołań metod i tworzenia obiektów może mieć znaczenie (zwłaszcza, że ​​metody wirtualne uniemożliwiają inne optymalizacje, takie jak wstawianie wywołań metod). Tutaj C ++ ma ogromną przewagę, ponieważ można użyć szablonów, aby osiągnąć inny rodzaj uogólnienia, który nie ma wpływu na środowisko wykonawcze, ale niekoniecznie jest mniej polimorficzny niż OOP. W rzeczywistości wszystkie mechanizmy składające się na OOP można modelować przy użyciu jedynie technik szablonów i rozdzielczości kompilacji.

W takich przypadkach (i wprawdzie często są one ograniczone do specjalnych domen problemowych), C ++ wygrywa z C # i porównywalnymi językami.

C ++ (w tym przypadku C) daje dokładną kontrolę nad strukturami danych. Jeśli chcesz coś zmienić, masz tę opcję. Duże zarządzane aplikacje Java lub .NET (OWB, Visual Studio 2005 ) korzystające z wewnętrznych struktur danych bibliotek Java / .NET niosą ze sobą bagaż. Widziałem, jak sesje projektantów OWB używają ponad 400 MB pamięci RAM i BIDS do projektowania kostek lub ETL również w setkach MB.

Przy przewidywalnym obciążeniu (takim jak większość testów porównawczych, które powtarzają proces wiele razy), JIT może zapewnić ci kod zoptymalizowany na tyle dobrze, że nie ma praktycznej różnicy.

W przypadku dużych aplikacji IMO różnica polega nie tyle na JIT, ile na strukturach danych, z których korzysta sam kod. Tam, gdzie aplikacja wymaga dużej ilości pamięci, użycie pamięci podręcznej będzie mniej wydajne. Brakujące pamięci podręczne w nowoczesnych procesorach są dość drogie. Tam, gdzie C lub C ++ naprawdę wygrywają, możesz zoptymalizować wykorzystanie struktur danych, aby ładnie grać z pamięcią podręczną procesora.

W przypadku grafiki standardowa klasa grafiki C # jest znacznie wolniejsza niż GDI, do którego można uzyskać dostęp za pomocą C / C ++. Wiem, że nie ma to nic wspólnego z samym językiem, a bardziej z całkowitą platformą .NET, ale grafikę oferuje deweloperowi jako zamiennik GDI, a jego wydajność jest tak zła, że ​​nie odważyłbym się nawet zrobić grafiki z tym.

Mamy prosty test porównawczy, którego używamy, aby zobaczyć, jak szybka jest biblioteka graficzna, a to po prostu rysowanie losowych linii w oknie. C ++ / GDI wciąż jest niezadowolony z 10000 linii, podczas gdy C # / Graphics ma trudności z zrobieniem 1000 w czasie rzeczywistym.

Odśmiecanie jest głównym powodem, dla którego Java # NIE MOŻE być używana w systemach czasu rzeczywistego.

1. Kiedy odbędzie się GC?

2. Jak długo to zajmie?

Jest to niedeterministyczne.

Musieliśmy ustalić, czy C # był porównywalny pod względem wydajności do C ++, i napisałem do tego kilka programów testowych (używając Visual Studio 2005 dla obu języków). Okazało się, że bez wyrzucania elementów bezużytecznych i tylko z uwzględnieniem języka (nie frameworka) C # ma w zasadzie taką samą wydajność jak C ++. Przydział pamięci jest znacznie szybszy w C # niż w C ++, a C # ma niewielką przewagę w determinizmie, gdy rozmiary danych są zwiększane poza granice linii pamięci podręcznej. Jednak wszystko to ostatecznie musiało zostać opłacone i istnieje ogromny koszt w postaci niedeterministycznych trafień wydajności dla C # z powodu wyrzucania elementów bezużytecznych.

Jak zwykle zależy to od aplikacji. Są przypadki, w których C # jest prawdopodobnie nieznacznie wolniejszy, i inne przypadki, w których C ++ jest 5 lub 10 razy szybszy, szczególnie w przypadkach, w których operacje można łatwo SIMD.

Wiem, że to nie jest to, co zostało z prośbą, ale C # jest często szybciej pisać niż C ++, co jest dużą zaletą w otoczeniu komercyjnym.

C / C ++ może działać znacznie lepiej w programach, w których występują albo duże tablice, albo ciężkie zapętlanie / iteracja nad tablicami (dowolnej wielkości). To jest powód, dla którego grafika jest ogólnie znacznie szybsza w C / C ++, ponieważ ciężkie operacje tablicowe leżą u podstaw prawie wszystkich operacji graficznych. .NET jest notorycznie powolny w operacjach indeksowania macierzy ze względu na wszystkie kontrole bezpieczeństwa, a jest to szczególnie prawdziwe w przypadku tablic wielowymiarowych (i tak, prostokątne tablice C # są nawet wolniejsze niż postrzępione tablice C #).

Premie C / C ++ są najbardziej widoczne, jeśli trzymasz się bezpośrednio wskaźników i unikasz wzmocnienia std::vectororaz innych pojemników wysokiego poziomu, a także inlinekażdej możliwej funkcji. W miarę możliwości używaj tablic oldschoolowych. Tak, będziesz potrzebować więcej wierszy kodu, aby osiągnąć to samo, co w Java lub C #, ponieważ unikasz kontenerów wysokiego poziomu. Jeśli potrzebujesz tablicy o dynamicznym rozmiarze, musisz tylko pamiętać o sparowaniunew T[] z odpowiednimdelete[] instrukcją (lub użyćstd::unique_ptr) - cena za dodatkową prędkość polega na tym, że musisz kodować ostrożniej. Ale w zamian możesz pozbyć się narzutu na zarządzaną pamięć / moduł wyrzucania elementów bezużytecznych, który może z łatwością wynosić 20% lub więcej czasu wykonywania mocno zorientowanych obiektowo programów w Javie i .NET, a także tych masowo zarządzanych koszty indeksowania macierzy pamięci. Aplikacje C ++ mogą również korzystać z niektórych fajnych przełączników kompilatora w określonych przypadkach.

Jestem programistą w językach C, C ++, Java i C #. Niedawno miałem rzadką okazję wdrożyć dokładnie ten sam program algorytmiczny w ostatnich 3 językach. Program miał wiele operacji matematycznych i wielowymiarowych. Mocno zoptymalizowałem to we wszystkich 3 językach. Wyniki były typowe dla tego, co zwykle widzę w mniej rygorystycznych porównaniach: Java była około 1,3 razy szybsza niż C # (większość JVM jest bardziej zoptymalizowana niż CLR), a wersja surowego wskaźnika C ++ była około 2,1 razy szybsza niż C #. Zauważ, że program C # używał tylko bezpiecznego kodu - moim zdaniem, równie dobrze możesz go napisać w C ++ przed użyciemunsafe słowa kluczowego.

Aby ktokolwiek pomyślał, że mam coś przeciwko C #, zakończę stwierdzeniem, że C # jest prawdopodobnie moim ulubionym językiem. Jest to najbardziej logiczny, intuicyjny i szybki język programowania, jaki do tej pory spotkałem. Wszystkie moje prototypy wykonuję w języku C #. Język C # ma wiele małych, subtelnych zalet w stosunku do Javy (tak, wiem, że Microsoft miał szansę naprawić wiele wad Javy, wchodząc do gry późno i prawdopodobnie kopiując Javę). Czy Calendarktoś wzniósł toast za klasę Javy ? Jeśli Microsoft kiedykolwiek poświęci prawdziwy wysiłek, aby zoptymalizować CLR i .NET JITter, C # może poważnie przejąć kontrolę. Jestem szczerze zaskoczony, że jeszcze tego nie zrobili - zrobili tak wiele rzeczy w języku C #, dlaczego nie pójść za tym z ciężkimi optymalizacjami kompilatora? Może jeśli wszyscy błagamy.

> Z tego co słyszałem ...

Wydaje się, że masz trudność w podjęciu decyzji, czy to, co usłyszałeś, jest wiarygodne, a trudność ta zostanie powtórzona podczas próby oceny odpowiedzi na tej stronie.

Jak zdecydujesz, czy to, co mówią ludzie, jest mniej lub bardziej wiarygodne niż to, co pierwotnie słyszałeś?

Jednym ze sposobów byłoby poprosić o dowód .

Gdy ktoś twierdzi, że „istnieją obszary, w których C # okazuje się być szybszy niż C ++”, zapytaj go, dlaczego tak mówi , poproś go o pokazanie pomiarów, poproś o pokazanie programów. Czasami po prostu popełniają błąd. Czasami dowiadujesz się, że po prostu wyrażają opinię, a nie dzielą się czymś, co mogą okazać się prawdą.

Często informacje i opinie będą mieszane w tym, co twierdzą ludzie, i będziesz musiał spróbować ustalić, który jest który. Na przykład z odpowiedzi na tym forum:

• „Wykonaj testy na stronie http://shootout.alioth.debian.org/ z dużym sceptycyzmem, ponieważ w dużej mierze testują one kod arytmetyczny, który najprawdopodobniej wcale nie jest podobny do twojego kodu”.

  Zadaj sobie pytanie, czy naprawdę rozumiesz, co oznacza „te w dużej mierze testują kod arytmetyczny” , a następnie zadaj sobie pytanie, czy autor rzeczywiście wykazał, że jego twierdzenie jest prawdziwe.

• „To raczej bezużyteczny test, ponieważ tak naprawdę zależy od tego, jak dobrze poszczególne programy zostały zoptymalizowane; Udało mi się przyspieszyć niektóre z nich o 4-6 razy lub więcej, co wyraźnie pokazuje, że porównanie między niezoptymalizowanymi programami jest raczej głupi."

  Zadaj sobie pytanie, czy autor rzeczywiście pokazał ci, że udało mu się „przyspieszyć niektóre z nich o 4-6 razy lub więcej” - łatwo to zgłosić!

W przypadku problemów „kłopotliwie równoległych” podczas korzystania z Intel TBB i OpenMP na C ++ zaobserwowałem około 10-krotny wzrost wydajności w porównaniu do podobnych problemów (czysta matematyka) z C # i TPL. SIMD jest jednym z obszarów, w którym C # nie może konkurować, ale mam również wrażenie, że TPL ma spore koszty ogólne.

To powiedziawszy, używam C ++ tylko do zadań krytycznych pod względem wydajności, o których wiem, że będę w stanie wielowątkowość i szybko uzyskać wyniki. W przypadku wszystkiego innego C # (i czasami F #) jest w porządku.

To niezwykle niejasne pytanie bez prawdziwych ostatecznych odpowiedzi.

Na przykład; Wolę grać w gry 3D tworzone w C ++ niż w C #, ponieważ wydajność jest zdecydowanie lepsza. (I znam XNA itp., Ale nie zbliża się to do rzeczywistości).

Z drugiej strony, jak wspomniano wcześniej; powinieneś rozwijać się w języku, który pozwala szybko robić to, co chcesz, a następnie w razie potrzeby optymalizować.

Języki .NET mogą być tak szybkie jak kod C ++, a nawet szybsze, ale kod C ++ będzie miał bardziej stałą przepustowość, ponieważ środowisko uruchomieniowe .NET musi wstrzymywać się z GC , nawet jeśli jest bardzo sprytne w kwestii swoich przerw.

Więc jeśli masz jakiś kod, który musi konsekwentnie działać szybko, bez żadnych przerw, .NET wprowadzi w pewnym momencie opóźnienie , nawet jeśli jesteś bardzo ostrożny z GC środowiska wykonawczego.

Teoretycznie w przypadku długo działających aplikacji serwerowych język skompilowany w JIT może stać się znacznie szybszy niż w przypadku kompilacji natywnej. Ponieważ język kompilowany w JIT jest generalnie najpierw kompilowany do dość niskiego poziomu języka pośredniego, możesz i tak przeprowadzić wiele optymalizacji wysokiego poziomu w czasie kompilacji. Dużą zaletą jest to, że JIT może kontynuować rekompilację sekcji kodu w locie, ponieważ otrzymuje coraz więcej danych o tym, jak aplikacja jest używana. Może ustawić najczęstsze ścieżki kodu, aby umożliwić przewidywanie gałęzi tak często, jak to możliwe. Może ponownie rozmieścić osobne bloki kodu, które są często wywoływane razem, aby zachować je oba w pamięci podręcznej. Może poświęcić więcej wysiłku na optymalizację wewnętrznych pętli.

Wątpię, czy robi to .NET lub którykolwiek z JRE, ale badano go już na studiach, więc nie jest nierozsądne sądzić, że tego rodzaju rzeczy mogą wkrótce znaleźć się w prawdziwym świecie .

Aplikacje wymagające intensywnego dostępu do pamięci, np. manipulowanie obrazami jest zwykle lepiej napisane w środowisku niezarządzanym (C ++) niż zarządzanym (C #). Zoptymalizowane pętle wewnętrzne z arytmetyką wskaźników są znacznie łatwiejsze do kontrolowania w C ++. W języku C # konieczne może być użycie niebezpiecznego kodu, aby zbliżyć się do tej samej wydajności.

Testowałem vectorw C ++ i C # odpowiedniku - Listi prostych tablicach 2d.

Używam wersji Visual C # / C ++ 2010 Express. Oba projekty są prostymi aplikacjami konsolowymi, przetestowałem je w standardowym (bez ustawień niestandardowych) trybie wydania i debugowania. Listy C # działają szybciej na moim komputerze, inicjalizacja tablicy jest również szybsza w języku C #, operacje matematyczne są wolniejsze.

Używam Intel Core2Duo [email protected], C # - .NET 4.0.

Wiem, że implementacja wektorowa różni się od listy C #, ale chciałem tylko przetestować kolekcje, których użyłbym do przechowywania moich obiektów (i mogłem korzystać z modułu indeksującego).

Oczywiście musisz wyczyścić pamięć (powiedzmy za każdym razem new), ale chciałem, aby kod był prosty.

Test wektorowy C ++ :

static void TestVector()
{
    clock_t start,finish;
    start=clock();
    vector<vector<double>> myList=vector<vector<double>>();
    int i=0;
    for( i=0; i<500; i++)
    {
        myList.push_back(vector<double>());
        for(int j=0;j<50000;j++)
            myList[i].push_back(j+i);
    }
    finish=clock();
    cout<<(finish-start)<<endl;
    cout<<(double(finish - start)/CLOCKS_PER_SEC);
}

Test listy C #:

private static void TestVector()
{

    DateTime t1 = System.DateTime.Now;
    List<List<double>> myList = new List<List<double>>();
    int i = 0;
    for (i = 0; i < 500; i++)
    {
        myList.Add(new List<double>());
        for (int j = 0; j < 50000; j++)
            myList[i].Add(j *i);
    }
    DateTime t2 = System.DateTime.Now;
    Console.WriteLine(t2 - t1);
}

C ++ - tablica:

static void TestArray()
{
    cout << "Normal array test:" << endl;
    const int rows = 5000;
    const int columns = 9000;
    clock_t start, finish;

    start = clock();
    double** arr = new double*[rows];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    finish = clock();

    cout << (finish - start) << endl;

    start = clock();
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    finish = clock();

    cout << (finish - start) << endl;
}

C # - tablica:

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

}

Czas: (wydanie / debugowanie)

C ++

• Inicjalizacja tablicy 600/606 ms,
• Wypełnienie tablicy 200/270 ms,
• 1 sekunda / 13 sekund inicjacja i wypełnienie wektora.

(Tak, 13 sekund, zawsze mam problemy z listami / wektorami w trybie debugowania).

DO#:

• Inicjalizacja tablicy 20/20 ms,
• Wypełnienie tablicy 403/440 ms,
• 710/742 ms lista inicj. I wypeł.

Cóż, to zależy. Jeśli kod bajtowy zostanie przetłumaczony na kod maszynowy (a nie tylko JIT) (to znaczy, jeśli wykonasz program) i jeśli twój program używa wielu alokacji / dezalokacji, może być szybszy, ponieważ algorytm GC potrzebuje tylko jednego przejścia (teoretycznie) raz w całej pamięci, ale normalne wywołania malloc / realloc / free C / C ++ powodują obciążenie każdego połączenia (obciążenie wywołania, obciążenie struktury danych, brak pamięci podręcznej;)).

Jest to teoretycznie możliwe (także w przypadku innych języków GC).

Nie widzę tak naprawdę wady, że nie mogę używać metaprogramowania w C # dla większości aplikacji, ponieważ większość programistów i tak go nie używa.

Inną dużą zaletą jest to, że SQL, podobnie jak „rozszerzenie” LINQ , zapewnia kompilatorowi optymalizację wywołań do baz danych (innymi słowy, kompilator może skompilować całe LINQ do jednego pliku binarnego „blob”, w którym wywoływane funkcje są wstawiane lub zoptymalizowany do użytku, ale spekuluję tutaj).

Sądzę, że istnieją aplikacje napisane w C # działające szybko, a także więcej aplikacji napisanych w C ++ działających szybko (no C ++ jest tylko starszy ... i weź też UNIX ...)
- pytanie w istocie jest - co to jest, użytkownicy a programiści narzekają na ...
Cóż, IMHO, w przypadku C # mamy bardzo wygodny interfejs użytkownika, bardzo ładną hierarchię bibliotek i cały system interfejsu CLI. W przypadku C ++ mamy szablony, ATL, COM, MFC i całą sekwencję napisanego i działającego kodu alreadyc, takiego jak OpenGL, DirectX itd. ... Programiści narzekają na nieokreślone wzrosty wywołań GC w przypadku C # (oznacza to, że program działa szybko i w sekundę - huk! utknął).
Pisanie kodu w C # jest bardzo proste i szybkie (nie zapominając o tym, że zwiększają również ryzyko błędów. W przypadku C ++ programiści narzekają na wycieki pamięci, - oznaczają kruszenia, wywołania między bibliotekami DLL, a także „DLL hell” - problem z obsługa i zastępowanie bibliotek nowszymi ...
Myślę, że więcej umiejętności będziesz mieć w języku programowania, tym więcej jakości (i szybkości) będzie charakteryzowało twoje oprogramowanie.

Powiedziałbym to w ten sposób: programiści, którzy piszą szybszy kod, są tymi, którzy są bardziej poinformowani o tym, co sprawia, że ​​obecne maszyny działają szybko, a przy okazji, oni też używają odpowiedniego narzędzia, które pozwala na precyzyjne określenie poziomu niskiego i deterministyczne techniki optymalizacji. Z tych powodów ci ludzie używają C / C ++ zamiast C #. Poszedłbym tak daleko, stwierdzając to jako fakt.

Jeśli się nie mylę, szablony C # są określane w czasie wykonywania. To musi być wolniejsze niż szablony czasu kompilacji C ++.

A jeśli weźmiesz pod uwagę wszystkie inne optymalizacje czasu kompilacji wspomniane przez tak wielu innych, a także brak bezpieczeństwa, który w rzeczywistości oznacza większą prędkość ...

Powiedziałbym, że C ++ jest oczywistym wyborem pod względem surowej prędkości i minimalnego zużycia pamięci. Ale to również przekłada się na więcej czasu na opracowanie kodu i upewnienie się, że nie przeciekasz pamięci ani nie powodujesz wyjątków wskaźnika zerowego.

Werdykt:

• C #: Szybszy rozwój, wolniejszy bieg

• C ++: Powolny rozwój, szybszy bieg.

To naprawdę zależy od tego, co próbujesz osiągnąć w kodzie. Słyszałem, że to tylko miejska legenda, że ​​istnieje różnica w wydajności między VB.NET, C # i zarządzanym C ++. Jednak odkryłem, przynajmniej w porównaniach ciągów, że zarządzanie C ++ bije spodnie od C #, co z kolei bije spodnie od VB.NET.

W żadnym wypadku nie przeprowadziłem wyczerpujących porównań złożoności algorytmicznej między językami. Używam również ustawień domyślnych w każdym z języków. W VB.NET używam ustawień, aby wymagać deklaracji zmiennych itp. Oto kod, którego używam do zarządzanego C ++: (Jak widać, ten kod jest dość prosty). Używam tego samego w innych językach w Visual Studio 2013 z .NET 4.6.2.

#include "stdafx.h"

using namespace System;
using namespace System::Diagnostics;

bool EqualMe(String^ first, String^ second)
{
    return first->Equals(second);
}
int main(array<String ^> ^args)
{
    Stopwatch^ sw = gcnew Stopwatch();
    sw->Start();
    for (int i = 0; i < 100000; i++)
    {
        EqualMe(L"one", L"two");
    }
    sw->Stop();
    Console::WriteLine(sw->ElapsedTicks);
    return 0;
}

Istnieją pewne główne różnice między C # i C ++ pod względem wydajności:

• C # jest oparty na GC / stercie. Alokacja i sam GC są narzutem jako brak lokalizacji dostępu do pamięci
• Optymalizatory C ++ stały się bardzo dobre na przestrzeni lat. Kompilatory JIT nie mogą osiągnąć tego samego poziomu, ponieważ mają ograniczony czas kompilacji i nie widzą zasięgu globalnego

Oprócz tego ważną rolę odgrywają także kompetencje programisty. Widziałem zły kod C ++, w którym klasy były przekazywane przez wartość jako argument w każdym miejscu. Możesz faktycznie pogorszyć wydajność w C ++, jeśli nie wiesz, co robisz.

> W końcu odpowiedzi muszą gdzieś być, prawda? :)

Umm nie.

Jak zauważono w kilku odpowiedziach, pytanie jest niedokładnie określone w sposób zachęcający do odpowiedzi w odpowiedzi, a nie do odpowiedzi. Aby wziąć tylko jeden sposób:

• pytanie łączy język z implementacją języka - ten program C jest 2194 razy wolniejszy i 1,17 razy szybszy niż ten program C # - musielibyśmy zapytać: Jakie implementacje językowe?

A potem które programy? Która maszyna? Który system operacyjny? Który zestaw danych

Zainspirowany tym, zrobiłem szybki test z 60 procentami powszechnych instrukcji potrzebnych w większości programów.

Oto kod C #:

for (int i=0; i<1000; i++)
{
    StreamReader str = new StreamReader("file.csv");
    StreamWriter stw = new StreamWriter("examp.csv");
    string strL = "";
    while((strL = str.ReadLine()) != null)
    {
        ArrayList al = new ArrayList();
        string[] strline = strL.Split(',');
        al.AddRange(strline);
        foreach(string str1 in strline)
        {
            stw.Write(str1 + ",");
        }
        stw.Write("\n");
    }
    str.Close();
    stw.Close();
}

Tablica łańcuchów i lista arraylistów są celowo stosowane w celu uwzględnienia tych instrukcji.

Oto kod c ++:

for (int i = 0; i<1000; i++)
{
    std::fstream file("file.csv", ios::in);
    if (!file.is_open())
    {
        std::cout << "File not found!\n";
        return 1;
    }

    ofstream myfile;
    myfile.open ("example.txt");
    std::string csvLine;

    while (std::getline(file, csvLine))
    {
        std::istringstream csvStream(csvLine);
        std::vector csvColumn;
        std::string csvElement;

        while( std::getline(csvStream, csvElement, ‘,’) )
        {
            csvColumn.push_back(csvElement);
        }

        for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
        {
            myfile << *j << ", ";
        }

        csvColumn.clear();
        csvElement.clear();
        csvLine.clear();
        myfile << "\n";
    }
    myfile.close();
    file.close();
}

Rozmiar użytego pliku wejściowego wynosił 40 KB.

A oto wynik -

• Kod C ++ uruchomiono w 9 sekund.
• Kod C #: 4 sekundy !!!

Och, ale to było na Linuksie ... Z C # działającym na Mono ... I C ++ z g ++.

OK, oto co mam w systemie Windows - Visual Studio 2003 :

• Kod C # uruchomiono w 9 sekund.
• Kod C ++ - okropne 370 sekund !!!