Dlaczego niektóre języki programowania są „szybsze” lub „wolniejsze” niż inne?


80

Zauważyłem, że niektóre aplikacje lub algorytmy zbudowane na języku programowania, na przykład C ++ / Rust, działają szybciej lub szybciej niż te zbudowane na powiedzmy Java / Node.js, działające na tym samym komputerze. Mam kilka pytań na ten temat:

  1. Dlaczego to się dzieje?
  2. Co rządzi „prędkością” języka programowania?
  3. Czy ma to coś wspólnego z zarządzaniem pamięcią?

Byłbym bardzo wdzięczny, gdyby ktoś to dla mnie zepsuł.


18
Zwróć uwagę, że szczególnie w przypadku JVM i CLR przeprowadzono szeroko zakrojone badania nad optymalizacją maszyn wirtualnych i mogą one przewyższyć skompilowane C ++ w wielu okolicznościach - ale łatwo jest naiwnie przeprowadzić błędne testy porównawcze.
Chrylis


26
To powiedziawszy, łączenie Javy i wszystkiego co związane z JavaScript jest obraźliwe.
Raphael

5
Jestem rozdarty między zamykaniem tego jako zbyt szerokim (podręczniki można pisać o odpowiednich tematach!) Lub powielaniem . Głosy społeczności, proszę!
Raphael

4
to pytanie jest również dość podobne, co determinuje szybkość języka programowania
dniu

Odpowiedzi:


95

Przy projektowaniu i implementacji języka programowania istnieje wiele opcji, które mogą wpłynąć na wydajność. Wspomnę tylko o kilku.

Każdy język musi być ostatecznie uruchamiany przez wykonanie kodu maszynowego. „Skompilowany” język, taki jak C ++, jest analizowany, dekodowany i tłumaczony na kod maszynowy tylko raz, w czasie kompilacji. Język „zinterpretowany”, jeśli jest implementowany bezpośrednio, jest dekodowany w czasie wykonywania, na każdym kroku i za każdym razem. Oznacza to, że za każdym razem, gdy uruchamiamy instrukcję, interpreter musi sprawdzić, czy jest to „jeśli-to-inaczej”, czy przydział itp. I działać odpowiednio. Oznacza to, że jeśli zapętlimy 100 razy, dekodujemy ten sam kod 100 razy, marnując czas. Na szczęście tłumacze często to optymalizują poprzez np. System kompilacji „just-in-time”. (Bardziej poprawnie, nie ma czegoś takiego jak „skompilowany” lub „zinterpretowany” język - jest to właściwość implementacji, a nie języka. Mimo to,

Różni kompilatorzy / tłumacze dokonują różnych optymalizacji.

Jeśli język ma automatyczne zarządzanie pamięcią, jego implementacja musi wykonać odśmiecanie. Ma to koszt działania, ale uwalnia programistę od zadania podatnego na błędy.

Język może być bliższy maszynie, pozwalając ekspertowi na mikrooptymalizację wszystkiego i wyciśnięcie większej wydajności z procesora. Jednak jest dyskusyjne, czy jest to faktycznie korzystne w praktyce, ponieważ większość programistów tak naprawdę nie optymalizuje mikro, a kompilator może zoptymalizować dobry język wyższego poziomu niż to, co zrobiłby przeciętny programista. (Czasami jednak bycie dalej od maszyny może mieć również swoje zalety! Na przykład Haskell ma bardzo wysoki poziom, ale dzięki swoim możliwościom wyboru projektu może zawierać bardzo lekkie zielone nici.)

Statyczne sprawdzanie typu może również pomóc w optymalizacji. W dynamicznie wpisywanym, interpretowanym języku, za każdym razem x - y, gdy wykonuje się obliczenia , tłumacz często musi sprawdzać, czy obie x,ysą liczbami i (np.) Zgłaszać wyjątek. To sprawdzenie można pominąć, jeśli typy zostały już sprawdzone podczas kompilacji.

Niektóre języki zawsze zgłaszają błędy czasu wykonywania w rozsądny sposób. Jeśli piszesz a[100]w Javie, w której ajest tylko 20 elementów, otrzymujesz wyjątek czasu wykonywania. W C spowodowałoby to niezdefiniowane zachowanie, co oznacza, że ​​program może ulec awarii, nadpisać niektóre losowe dane w pamięci, a nawet wykonać absolutnie cokolwiek innego (norma ISO C nie ma żadnych ograniczeń). Wymaga to sprawdzenia środowiska wykonawczego, ale zapewnia programistom znacznie ładniejszą semantykę.

Należy jednak pamiętać, że podczas oceny języka wydajność to nie wszystko. Nie miej na tym punkcie obsesji. Powszechną pułapką jest próba mikrooptymalizacji wszystkiego, ale nie dostrzega się, że stosowana jest nieefektywna struktura algorytmu / danych. Knuth powiedział kiedyś: „przedwczesna optymalizacja jest źródłem wszelkiego zła”.

Nie lekceważ, jak trudno jest poprawnie napisać program . Często lepiej jest wybrać „wolniejszy” język, który ma bardziej przyjazną dla człowieka semantykę. Ponadto, jeśli istnieją pewne części krytyczne pod względem wydajności, zawsze można je zaimplementować w innym języku. Tytułem odniesienia, w konkursie programowym ICFP 2016 , były to języki używane przez zwycięzców:

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

Żaden z nich nie używał jednego języka.


81
Jedna wersja całego cytatu z Knuth : „Programiści marnują ogromną ilość czasu na myślenie lub martwienie się o szybkość niekrytycznych części swoich programów, a te próby wydajności mają silny negatywny wpływ podczas debugowania i konserwacji. Powinniśmy zapomnieć o małej wydajności, powiedzmy w około 97% przypadków: przedwczesna optymalizacja jest źródłem wszelkiego zła. Jednak nie powinniśmy tracić naszych możliwości w tak krytycznych 3%. ”
Derek Elkins

6
Również niektóre języki gwarantują pozornie niewinne rzeczy, które mogą wpływać na zdolność kompilatora do optymalizacji, patrz ścisłe aliasing w C ++ vs. FORTRAN
PlasmaHH

9
Dołączyłem, aby móc głosować za komentarzem @DerekElkins. Zbyt często brakuje kontekstu tego cytatu, czasami nawet prowadząc do wniosku, że opowiada się on za tym, że wszelka optymalizacja jest zła.
rura

9
@DerekElkins Jak na ironię, przegapiłeś chyba najważniejszą część: dwa zdania zaraz po sobie. „Dobry programista nie uśpi się na skutek takiego rozumowania. Mądrze będzie uważnie przyjrzeć się krytycznemu kodowi, ale dopiero po zidentyfikowaniu tego kodu. Często błędem jest osądzanie z góry, które części program jest naprawdę krytyczny, ponieważ uniwersalne doświadczenie programistów korzystających z narzędzi pomiarowych polegało na tym, że ich intuicyjne domysły zawiodły ”. PDF str.268
8bittree

9
@DerekElkins Aby być jasnym, nie chcę wkładać do ust słów, które twierdzą, że to twierdzisz, ale zbyt często spotykam ludzi, którzy dodają tylko trochę do podstawowego cytatu i myślą, że Knuth opowiada się za przedwczesną optymalizacją 3 % czasu, kiedy cały artykuł wyjaśnia, że ​​zawsze sprzeciwia się przedwczesnej optymalizacji, prawie zawsze sprzeciwia się małym optymalizacjom, ale opowiada się za drobnymi optymalizacjami w sekcjach ocenianych jako krytyczne.
8bittree

18

Co rządzi „prędkością” języka programowania?

Nie ma czegoś takiego jak „prędkość” języka programowania. Jest tylko prędkość określonego programu napisanego przez określonego programistę wykonanego przez określoną wersję konkretnej implementacji konkretnego silnika wykonawczego działającego w określonym środowisku.

Mogą występować ogromne różnice w wydajności podczas uruchamiania tego samego kodu napisanego w tym samym języku na tym samym komputerze przy użyciu różnych implementacji. Lub nawet używając różnych wersji tej samej implementacji. Na przykład uruchomienie dokładnie tego samego testu porównawczego ECMAScript na dokładnie tej samej maszynie przy użyciu wersji SpiderMonkey sprzed 10 lat w porównaniu z wersją z tego roku prawdopodobnie przyniesie wzrost wydajności pomiędzy 2 × –5 ×, a może nawet 10 ×. Czy to oznacza, że ​​ECMAScript jest 2 razy szybszy niż ECMAScript, ponieważ uruchamianie tego samego programu na tym samym komputerze jest 2 razy szybsze w nowszej implementacji? To nie ma sensu.

Czy ma to coś wspólnego z zarządzaniem pamięcią?

Nie całkiem.

Dlaczego to się dzieje?

Zasoby. Pieniądze. Microsoft prawdopodobnie zatrudnia więcej osób przygotowujących kawę dla programistów kompilatorów niż cała społeczność PHP, Ruby i Python łącznie ma ludzi pracujących na swoich maszynach wirtualnych.

Dla mniej więcej jakiejkolwiek funkcji języka programowania, która w jakiś sposób wpływa na wydajność, istnieje również rozwiązanie. Na przykład C (używam C jako stand-in dla klasy podobnych języków, z których niektóre istniały nawet przed C) nie jest bezpieczny dla pamięci, więc wiele programów C działających w tym samym czasie może deptać wzajemna pamięć. Tak więc wynajdujemy pamięć wirtualną i sprawiamy, że wszystkie programy C przechodzą przez warstwę pośredniczącą, aby mogły udawać, że są jedynymi uruchomionymi na komputerze. Jest to jednak powolne, dlatego wynajdujemy MMU i implementujemy pamięć wirtualną w sprzęcie, aby ją przyspieszyć.

Ale! Języki bezpieczne dla pamięci nie potrzebują tego wszystkiego! Posiadanie wirtualnej pamięci nie pomaga im ani trochę. W rzeczywistości jest gorzej: pamięć wirtualna nie tylko nie pomaga w bezpiecznych dla pamięci językach, pamięć wirtualna, nawet jeśli jest implementowana sprzętowo, nadal wpływa na wydajność. Może to być szczególnie szkodliwe dla wydajności śmieciarek (czego używa znaczna liczba implementacji języków bezpiecznych dla pamięci).

Kolejny przykład: nowoczesne uniwersalne procesory ogólnego przeznaczenia wykorzystują wyrafinowane sztuczki, aby zmniejszyć częstotliwość pomyłek w pamięci podręcznej. Wiele z tych sztuczek polega na próbie przewidzenia, jaki kod zostanie wykonany i jaka pamięć będzie potrzebna w przyszłości. Jednak w przypadku języków o wysokim stopniu polimorfizmu w środowisku wykonawczym (np. Języki OO) bardzo trudno jest przewidzieć te wzorce dostępu.

Istnieje jednak inny sposób: całkowity koszt pominięcia pamięci podręcznej to liczba pomyłek pamięci podręcznej pomnożona przez koszt pojedynczego braku pamięci podręcznej. Procesory głównego nurtu starają się zmniejszyć liczbę nieudanych prób, ale co by było, gdybyś mógł obniżyć koszty pojedynczego niepowodzenia?

Procesor Azul Vega-3 został specjalnie zaprojektowany do uruchamiania zwirtualizowanych maszyn JVM i miał bardzo potężną MMU z niektórymi specjalistycznymi instrukcjami pomagającymi w zbieraniu śmieci i wykrywaniu ucieczki (dynamiczny odpowiednik statycznej analizy ucieczki) oraz potężnymi kontrolerami pamięci, a także całym systemem nadal może robić postępy w ponad 20000 zaległych brakach pamięci podręcznej w locie. Niestety, podobnie jak większość procesorów specyficznych dla języka, jego konstrukcja została po prostu wydana i brutalnie wymuszona przez „gigantów” Intel, AMD, IBM i tym podobne.

Architektura procesora to tylko jeden przykład, który ma wpływ na to, jak łatwo lub jak trudno jest mieć wysokowydajną implementację języka. Język taki jak C, C ++, D, Rust, który dobrze pasuje do współczesnego głównego modelu programowania procesorów, będzie łatwiejszy do zrobienia niż język, który musi „walczyć” i ominąć procesor, taki jak Java, ECMAScript, Python, Ruby , PHP.

Naprawdę, to wszystko kwestia pieniędzy. Jeśli wydasz tyle samo pieniędzy na opracowanie wysokowydajnego algorytmu w ECMAScript, wysokowydajnej implementacji ECMAScript, wydajnego systemu operacyjnego zaprojektowanego dla ECMAScript, wysokowydajnego procesora zaprojektowanego dla ECMAScript, tak jak zostało to wydane w ciągu ostatniego przez dziesięciolecia, aby języki podobne do C działały szybko, wtedy prawdopodobnie zobaczysz taką samą wydajność. Tyle, że w tej chwili wydano znacznie więcej pieniędzy na szybkie tworzenie języków podobnych do C niż na szybkie tworzenie języków podobnych do ECMAS, a założenia dotyczące języków podobnych do C są wypierane na cały stos, od MMU i procesorów po systemy operacyjne i systemy pamięci wirtualnej do bibliotek i frameworków.

Osobiście jestem najbardziej zaznajomiony z Ruby (który jest ogólnie uważany za „wolny język”), dlatego podam dwa przykłady: Hashklasę (jedną z centralnych struktur danych w Ruby, słowniku klucz-wartość) w Rubiniusie Implementacja Ruby jest napisana w 100% czystym języku Ruby i ma mniej więcej taką samą wydajność jakHashklasa w YARV (najczęściej używana implementacja), która jest napisana w C. I jest biblioteka do obróbki obrazów napisana jako rozszerzenie C dla YARV, która również ma (powolną) czystą Rubinową „wersję rezerwową” dla implementacji, które nie obsługuje C, który wykorzystuje tonę bardzo dynamicznych i refleksyjnych sztuczek Ruby; eksperymentalna gałąź JRuby, wykorzystująca szkielet interpretera AST Truffle i ramę kompilacji Graal JIT firmy Oracle Labs, może wykonać tę czystą „awaryjną wersję” Rubiego tak szybko, jak YARV może wykonać oryginalną wysoce zoptymalizowaną wersję C. Jest to po prostu (no cokolwiek, ale) osiągnięte przez naprawdę sprytnych ludzi, którzy robią naprawdę sprytne rzeczy z dynamicznymi optymalizacjami środowiska uruchomieniowego, kompilacją JIT i częściową oceną.


4
Chociaż technicznie języki nie są z natury szybkie, niektóre języki kładą większy nacisk na umożliwienie programiście szybkiego tworzenia kodu. C jest zoptymalizowany przede wszystkim do procesorów, a nie na odwrót. Na przykład C wybrał stały rozmiar intze względu na wydajność, pomimo faktu, że nieograniczone liczby całkowite, takie jak te używane przez Python, są znacznie bardziej matematycznie naturalne. Wdrażanie nielimitowanych liczb całkowitych w sprzęcie nie byłoby tak szybkie, jak liczby całkowite o stałym rozmiarze. Języki, które próbują ukryć szczegóły implementacji, wymagają złożonych optymalizacji, aby zbliżyć się do naiwnych implementacji C.
gmatht

1
C ma swoją historię - został stworzony, aby system napisany w języku asemblera był przenośny na inne systemy. Pierwotnym celem było więc dostarczenie „przenośnego asemblera” dla Uniksa i było ono bardzo dobrze zaprojektowane. Tak dobrze radził sobie w latach 1980-1995, że miał masę krytyczną, gdy pojawił się Windows 95.
Thorbjørn Ravn Andersen

1
Nie zgadzam się z komentarzem na temat zasobów. Liczy się nie liczba osób w zespole, to poziom umiejętności najlepszych ludzi w zespole.
Michael Kay,

„Microsoft prawdopodobnie zatrudnia więcej osób przygotowujących kawę dla swoich programistów kompilatorów niż cała społeczność PHP, Ruby i Python łącznie ma ludzi pracujących na swoich maszynach wirtualnych”. Przypuszczam, że to zależy od tego, jak daleko jesteś w stanie rozciągnąć termin „programista kompilatora” i ile w tym bierzesz (Microsoft opracowuje wiele kompilatorów). Na przykład, tylko zespół kompilatorów VS C ++ jest stosunkowo małym AFAIK.
Cubic

7

Teoretycznie, jeśli napiszesz kod, który robi dokładnie to samo w dwóch językach i skompilujesz oba używając „idealnego” kompilatora, wydajność obu powinna być taka sama.

W praktyce istnieje kilka powodów, dla których wydajność będzie inna:

  1. Niektóre języki są trudniejsze do optymalizacji.

    Dotyczy to zwłaszcza funkcji, które zwiększają dynamikę kodu (dynamiczne pisanie, metody wirtualne, wskaźniki funkcji), ale także na przykład wyrzucanie elementów bezużytecznych.

    Istnieją różne sposoby szybkiego uczynienia kodu przy użyciu takich funkcji, ale zwykle kończy się to przynajmniej nieco wolniej niż bez ich używania.

  2. Niektóre implementacje językowe wymagają kompilacji w czasie wykonywania.

    Dotyczy to zwłaszcza języków z maszynami wirtualnymi (jak Java) i języków, które wykonują kod źródłowy, bez pośredniego kroku dla pliku binarnego (jak JavaScript).

    Takie implementacje językowe muszą wykonywać więcej pracy w środowisku wykonawczym, co wpływa na wydajność, szczególnie na czas uruchamiania / wydajność wkrótce po uruchomieniu.

  3. Implementacje językowe celowo poświęcają mniej czasu na optymalizacje niż mogliby.

    Wszystkie kompilatory dbają o wydajność samego kompilatora, a nie tylko generowanego kodu. Jest to szczególnie ważne w przypadku kompilatorów wykonawczych (kompilatorów JIT), w których kompilacja zbyt długo spowalnia wykonywanie aplikacji. Ale dotyczy to kompilatorów z wyprzedzeniem, takich jak te dla C ++. Na przykład przydział rejestrów jest problemem kompletnym dla NP, więc nie jest realistyczne rozwiązanie go idealnie, a zamiast tego stosuje się heurystykę, która jest wykonywana w rozsądnym czasie.

  4. Różnice w idiomach w różnych językach.

    Kod napisany we wspólnym stylu dla określonego języka (kod idiomatyczny) przy użyciu wspólnych bibliotek może powodować różnice w wydajności, ponieważ taki kod idiomatyczny zachowuje się subtelnie inaczej w każdym języku.

    Jako przykład rozważmy vector[i]w C ++, list[i]w C # i list.get(i)w Javie. Kod C ++ prawdopodobnie nie sprawdza zasięgu i nie wykonuje żadnych wirtualnych wywołań, kod C # wykonuje sprawdzanie zasięgu, ale nie ma wirtualnych wywołań, a kod Java wykonuje sprawdzanie zasięgu i jest to wywołanie wirtualne. Wszystkie trzy języki obsługują metody wirtualne i niewirtualne, a zarówno C ++, jak i C # mogą obejmować sprawdzanie zasięgu lub unikanie go podczas uzyskiwania dostępu do podstawowej tablicy. Ale standardowe biblioteki tych języków postanowiły napisać te równoważne funkcje w różny sposób, w wyniku czego ich wydajność będzie inna.

  5. W niektórych kompilatorach może brakować optymalizacji.

    Autorzy kompilatorów mają ograniczone zasoby, więc nie mogą wdrożyć każdej możliwej optymalizacji, nawet ignorując inne problemy. Zasoby, które dysponują, mogą być bardziej skoncentrowane na jednym obszarze optymalizacji niż na innych. W rezultacie kod napisany w różnych językach może mieć różną wydajność z powodu różnic w ich kompilatorach, nawet jeśli nie ma podstawowego powodu, dla którego jeden język powinien być szybszy lub nawet łatwiejszy do optymalizacji niż drugi.


Niektóre języki nie mają kompilatora. W niektórych językach nie może być kompilatora ( odniesienie ).
Raphael

3
W niektórych językach kompilator statyczny nie może istnieć . Na dynamiczną kompilację nie ma wpływu nierozstrzygalność właściwości statycznych.
Jörg W Mittag

Jeśli języki są wystarczająco różne, nie mają „kodu, który robi dokładnie to samo”. Mogą mieć kod, który generuje takie same dane wyjściowe lub obserwowalne przez użytkownika zachowanie, co nie jest tym samym. Więc nie zgadzam się z twoją przesłanką.
einpoklum

@einpoklum Nie widzę różnicy. Z pewnymi wyjątkami (jak synchronizacja wątków), które moim zdaniem nie są tutaj interesujące, specyfikacje językowe zwykle pozwalają na wszelkie optymalizacje, które pozwalają zachować obserwowalne zachowanie. Jakie masz na myśli zachowanie, którego nie można zaobserwować, ale którego nie można zoptymalizować?
svick

Teoretycznie każdy interpretowany język można „skompilować”, generując plik EXE składający się z interpretera + kodu źródłowego programu.
dan04

1

To bardzo ogólne pytanie, ale w twoim przypadku odpowiedź może być prosta. C ++ kompiluje się do kodu maszynowego, gdzie Java kompiluje się do kodu bajtowego Java, który jest następnie uruchamiany na maszynie wirtualnej Java (chociaż istnieje również kompilacja just-in-time, która dodatkowo kompiluje kod bajtowy Java do natywnego kodu maszynowego). Kolejną różnicą może być wyrzucanie elementów bezużytecznych, które jest usługą, którą zapewnia tylko Java.


2
To zbyt uproszczona odpowiedź. Istnieją ustawienia, w których Java jest szybsza.
Raphael

4
Istnieją również implementacje Java, które kompilują się do kodu maszynowego i interpretowane implementacje C ++. Czym jest „kod maszynowy”, skoro mam procesor picoJava, który natywnie wykonuje JVM, a na JVM działa interpreter JPC x86, to co sprawia, że ​​kod obiektowy x86 jest „kodem maszynowym”, a JVM nie jest?
Jörg W Mittag

2
Nitpick: Nie tylko Java zapewnia wyrzucanie elementów bezużytecznych ... a nawet jeśli weźmiesz pod uwagę C ++ i Javę, niektóre programy frameworki / biblioteki C ++ mają dostępne funkcje usuwania śmieci.
einpoklum

Kompilacja do natywnego kodu maszynowego ogólnie poprawia wydajność. Jednak w niektórych ograniczonych przypadkach wysokiej jakości interpreter może pokonać naiwny kompilator just-in-time.
Depressed

@ JörgWMittag Sztuką jest kompilacja do natywnego kodu maszynowego - kodu maszynowego zrozumiałego przez procesor hosta - a następnie bezpośrednie przejście do wywoływanego kodu, aby można go było wykonać bez interpretacji. Będzie to x86 na układzie x86 i bajtowe kody JVM na procesorze picoJava.
Depressed

-5

Twoje pytanie jest zbyt ogólne, więc obawiam się, że nie mogę udzielić dokładnej odpowiedzi, której potrzebujesz.

Dla mojego najlepszego wyjaśnienia, spójrzmy na platformę C ++ i .Net.

C ++, bardzo zbliżony do kodu maszynowego i jeden z ulubionych programów do programowania w przeszłości (jak ponad 10 lat temu?) Ze względu na wydajność. Nie ma zbyt wielu zasobów potrzebnych do opracowania i uruchomienia programu C ++, nawet z IDE, są one uważane za bardzo lekkie i bardzo szybkie. Możesz także napisać kod C ++ w konsoli i stamtąd rozwinąć grę. Jeśli chodzi o pamięć i zasoby, z grubsza zapomniałem, ile pojemności zajmuje komputer, ale jest to pojemność, której nie można porównać z obecną generacją języka programowania.

Teraz spójrzmy na .Net. Warunkiem koniecznym do rozwoju .Net jest jeden gigantyczny IDE, który składa się nie tylko z jednego rodzaju języków programowania. Nawet jeśli chcesz po prostu programować, powiedzmy C #, samo IDE domyślnie zawiera wiele platform programistycznych, takich jak J #, VB, mobilne itp. Chyba że wykonasz instalację niestandardową i zainstalujesz tylko dokładnie to, czego chcesz, pod warunkiem, że masz wystarczające doświadczenie, aby grać z instalacją IDE.

Poza instalowaniem samego oprogramowania IDE, .Net ma także ogromną pojemność bibliotek i platform w celu ułatwienia dostępu do dowolnej platformy, której potrzebują programiści ORAZ nie.

Programowanie w .Net może być świetną zabawą, ponieważ domyślnie dostępnych jest wiele popularnych funkcji i komponentów. Możesz przeciągać i upuszczać i używać wielu metod sprawdzania poprawności, odczytu plików, dostępu do bazy danych i wiele więcej w IDE.

W rezultacie jest to kompromis między zasobami komputerowymi a szybkością rozwoju. Te biblioteki i środowisko zajmuje pamięć i zasoby. Gdy uruchomisz program w .Net IDE, może to zająć mnóstwo czasu, próbując skompilować biblioteki, komponenty i wszystkie twoje pliki. Podczas debugowania komputer wymaga wielu zasobów do zarządzania procesem debugowania w środowisku IDE.

Zwykle, aby wykonać program .Net, potrzebujesz dobrego komputera z niektórymi pamięciami RAM i procesorem. W przeciwnym razie równie dobrze możesz nie programować. Pod tym względem platforma C ++ jest znacznie lepsza niż .Net. Chociaż nadal potrzebujesz dobrego komputera, ale pojemność nie będzie zbytnio martwić w porównaniu do .Net.

Mam nadzieję, że moja odpowiedź może pomóc w twoim pytaniu. Daj mi znać, jeśli chcesz dowiedzieć się więcej.

EDYTOWAĆ:

Po prostu wyjaśnienie mojej głównej kwestii, odpowiadam głównie na pytanie „Co rządzi prędkością programowania”.

Z punktu widzenia IDE użycie języka C ++ lub .Net we względnym IDE nie wpływa na szybkość pisania kodu, ale wpłynie na szybkość rozwoju, ponieważ kompilator Visual Studio zajmuje więcej czasu, ale program IDE C ++ jest znacznie lżejszy i zużywają mniej zasobów komputerowych. Na dłuższą metę możesz szybciej programować z IDE typu C ++ w porównaniu z IDE .Net, które w dużym stopniu zależy od bibliotek i frameworka. Jeśli poświęcisz czas oczekiwania IDE na uruchomienie, kompilację, uruchomienie programu itp., Wpłynie to na szybkość programowania. Chyba że „szybkość programowania” skupia się tylko na „szybkości pisania kodu”.

Ilość bibliotek i frameworka w Visual Studio również zużywa pojemność komputera. Nie jestem pewien, czy to odpowiada na pytanie „zarządzanie pamięcią”, ale chcę tylko podkreślić, że Visual Studio IDE może zająć wiele zasobów podczas jego uruchamiania, a tym samym spowolnić ogólną „szybkość programowania”. Oczywiście nie ma to nic wspólnego z „szybkością pisania kodu”.

Jak można się domyślać, nie znam zbyt dużo C ++, ponieważ używam go tylko jako przykładu, moja główna uwaga dotyczy typu ciężkiego IDE typu Visual Studio, które pochłania zasoby komputerowe.

Jeśli wpadłem na pomysł i w ogóle nie odpowiedziałem na pytanie dotyczące wątku, przepraszam za długi post. Ale radziłbym wątkowi, aby wyjaśnił pytanie i zapytał dokładnie, co powinien wiedzieć o „szybszym” i „wolniejszym”


6
Dla przypomnienia, programowanie .NET wymaga tylko zestawu .NET SDK (i, w celu wykonania, samego środowiska uruchomieniowego .NET). Możesz użyć zwykłego edytora tekstu i wywołać kompilator z wiersza poleceń. IDE (zakładam, że masz na myśli Visual Studio) NIE jest wymagane, chociaż z pewnością pomaga w każdym dużym projekcie (Intellisense, debugger itp.). Istnieją również lżejsze IDE, takie jak SharpDevelop z mniejszą ilością dzwonków i gwizdków.
MetalMikester

16
Z pewnością możesz się rozwijać w .Net bez IDE. Ale nie rozumiem, w jaki sposób IDE ma związek z szybkością pisania kodu w języku.
svick

8
@MetalMikester: I oczywiście Visual Studio to idE to IDE dla rozwoju C ++ w systemie Windows.
Jörg W Mittag

3
Kompilowanie C ++ do kodu .Net to tylko jeden przełącznik kompilatora; domniemana przepaść to mosty jednym kliknięciem myszy w studiu wizualnym.
MSalters

1
Nie jestem wcale pewien, czy nazwałbym współczesne C ++ „bardzo blisko kodu maszynowego”. Oryginał C, tak; został pomyślany jako przenośny asembler i pozostał bardzo blisko tego (chociaż biblioteka standardowa się powiększyła, a różne kompilatory oferują dodatki do właściwego języka, który zabiera go dalej od jego początków). Może oryginalny C ++ (C z klasami); przepisanie wariantu C zawierającego klasy na czyste C nie jest trudne, w którym to momencie obowiązuje poprzednia dyskusja. Ale nowoczesny C ++ z szablonami, polimorfizmem i wszystkim innym pod Słońcem? To prawie „bardzo bliski kodowi maszynowemu”.
CVn
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.