Czy możemy sformułować ogólne stwierdzenia dotyczące wydajności kodu interpretowanego w porównaniu do kodu skompilowanego?

60

Porównuję dwie technologie, aby uzyskać rekomendację, z której firma powinna skorzystać. Kod technologii A jest interpretowany, podczas gdy kod technologii B jest kompilowany do kodu maszynowego. W moim porównaniu stwierdzam, że ogólnie technologia B miałaby lepszą wydajność, ponieważ nie ma dodatkowego obciążenia związanego z procesem interpretacji. Oświadczam również, że ponieważ program można napisać na wiele sposobów, nadal jest możliwe, że program napisany w tech A może przewyższyć program napisany w tech B.

Kiedy przekazałem ten raport do recenzji, recenzent stwierdził, że nie podałem żadnego wyraźnego powodu, dla którego ogólnie koszty interpretacji byłyby na tyle duże, że moglibyśmy dojść do wniosku, że wydajność technologii B byłaby lepsza.

Więc moje pytanie brzmi: czy możemy kiedykolwiek powiedzieć coś o wydajności skompilowanych / interpretowanych technologii? Jeśli możemy powiedzieć, że kompilacja jest generalnie szybsza niż interpretowana, jak mogę przekonać recenzenta o moim punkcie?

EpicSam
źródło
76
Ponieważ wydaje się, że jest to problem praktyczny, a nie ćwiczenie akademickie, może być wskazane, aby nawet nie próbować udzielać ogólnej odpowiedzi, ale faktycznie oceniać technologie A i B. Chociaż prawdopodobnie nie można udzielić ogólnej odpowiedzi, z pewnością można ocenić charakterystyki wydajności dwóch konkretnych technologii, wskazując ich znaczenie dla rodzaju aplikacji,
którymi
26
Pytanie dotyczy ogólników, ale wydaje się, że twoim prawdziwym problemem jest specyfika Technologii A i B. Chociaż myślę, że ogólnie tłumaczone języki mogą być wolniejsze jako całość, fakt ten prawdopodobnie nie ma absolutnie żadnego wpływu na twoje konkretne technologie. Jest całkiem możliwe, że twoja konkretna interpretowana B jest szybsza niż skompilowana A niezależnie od ogólnego trendu.
Bryan Oakley,
18
Losowo wybieraj język interpretowany i skompilowany i stawiaj dolara, że ​​skompilowany jest szybszy. Powtórz tyle razy, a ostatecznie wyjdziesz wystarczająco daleko, aby kupić lunch w Subway. Istnieją jednak szybsze i ciekawsze sposoby na zarobienie tak dużej kwoty przez kompetentnego programistę. A Subway i tak nie jest taki wspaniały.
Ed Plunkett,
23
Wydaje się, że sam sobie przeczysz. Z jednej strony chcesz złożyć ogólne oświadczenie o językach interpretowanych a skompilowanych. Ale z drugiej strony chcesz zastosować to ogólne stwierdzenie do konkretnego scenariusza. Ale kiedy zastosujesz go do konkretnego scenariusza, nie będzie już uogólniony . Nawet jeśli możesz uzasadnić, że tłumaczone języki są ogólnie wolniejsze , twój recenzent nie przejmuje się tym. Robisz analizę dwóch bardzo specyficznych technologii. To dosłownie przeciwieństwo uogólnienia.
loneboat
8
Szczerze mówiąc, dlaczego, u licha, chcesz dać rekomendację dotyczącą jednej z dwóch technologii opartą przede wszystkim na wydajności? W szczególnych przypadkach (takich jak programowanie gier 3D o wysokiej prędkości) wydajność może być istotnym kryterium, ale w przypadku większości rzeczywistych programów biznesowych powinna być ostatnią rzeczą, którą porównujesz, a nie pierwszą.
Doc Brown

Odpowiedzi:

111

Nie.

Zasadniczo wydajność implementacji języka zależy przede wszystkim od kwoty pieniędzy, zasobów, siły roboczej, badań, inżynierii i rozwoju.

W szczególności wydajność konkretnego programu zależy przede wszystkim od ilości myśli włożonej w jego algorytmy.

Istnieje kilka bardzo szybkich interpretatorów i niektóre kompilatory, które generują bardzo wolny kod.

Na przykład jednym z powodów, dla których Forth jest nadal popularny, jest to, że w wielu przypadkach interpretowany program Forth jest szybszy niż równoważny skompilowany program C, a jednocześnie program użytkownika napisany w Forth plus napisany interpreter Forth w C jest mniejszy niż program użytkownika napisany w C.

Jörg W Mittag
źródło
12
o ile mogę powiedzieć własną wcześniejszą odpowiedź w połączonym (być może duplikacie) pytaniu obejmuje te sprawy znacznie lepiej niż to
komnata
11
Jeśli niemożliwe jest wyciągnięcie ogólnych wniosków na temat wydajności i możemy napisać pewien program w A, który przewyższa podobny program w B, ale możemy również napisać program w B, który przewyższa program napisany w A. Nie możemy naprawdę wyciągnąć żadnych wniosków na temat szybkość języka kiedykolwiek? W każdym razie Forth wygląda interesująco, będę musiał przeczytać o tym później.
EpicSam,
36
@EpicSam: poprawnie. Sam pomysł „szybkości języka” jest zasadniczo pozbawiony sensu.
Jörg W Mittag
23
Ogólnie: bądź konkretny.
igouy,
19
Zakładam, że przez „... i niektóre bardzo wolne kompilatory” miałeś na myśli kod, który generują, a nie szybkość kompilacji.
martineau,
81

Uogólnienia i konkretne scenariusze są dosłownie przeciwieństwami.

Wydaje się, że sam sobie przeczysz. Z jednej strony chcesz złożyć ogólne oświadczenie o językach interpretowanych a skompilowanych. Ale z drugiej strony chcesz zastosować to ogólne stwierdzenie do konkretnego scenariusza dotyczącego Technologii A i Technologii B.

Gdy zastosujesz coś do konkretnego scenariusza, nie jest to już uogólnione . Więc nawet jeśli potrafisz stwierdzić, że interpretowane języki są ogólnie wolniejsze , nadal nie masz racji. Twój recenzent nie dba o uogólnienia. Robisz analizę dwóch bardzo specyficznych technologii. To dosłownie przeciwieństwo uogólnienia.

samotna łódź
źródło
3
To zdecydowanie najlepsza odpowiedź na tekst pytania, w przeciwieństwie do tytułu pytania.
David Moles,
37

Zasadniczo interpretowany program jest około 2x – 10x wolniejszy niż pisanie programu w języku hosta tłumacza, przy czym tłumacze dla bardziej dynamicznych języków są wolniejsi. Jest tak, ponieważ interpretowany program musi wykonać całą rzeczywistą pracę, ale dodatkowo ma narzut interpretacji.

W zależności od struktury tłumacza mogą występować bardzo znaczące różnice. Istnieją dwie sprzeczne szkoły projektowania interpreterów: jedna mówi, że kody powinny być tak małe, jak to możliwe, aby można je było łatwiej zoptymalizować, a druga mówi, że kody powinny być tak duże, jak to możliwe, abyśmy mogli więcej pracować w tłumaczu. Kiedy struktura twojego programu odpowiada filozofii tłumacza, koszty ogólne stają się nieistotne.

Np. Perl jest interpretowanym językiem ukierunkowanym na manipulację tekstem. Idiomatyczny program Perl wykonujący manipulację tekstem nie będzie dużo wolniejszy niż program C, aw niektórych przypadkach może nawet przewyższyć program C (możliwe, ponieważ Perl używa innej reprezentacji ciągu i ma wbudowane różne optymalizacje związane z tekstem i IO). Jednak robienie liczb w Perlu będzie nieznośnie wolne. Przyrost ++xjest pojedynczą instrukcją asemblera, ale wymaga wielu przejść wskaźnikowych i rozgałęzień dla interpretera Perla. Niedawno przeniosłem związany z procesorem skrypt Perla do C ++ i uzyskałem przyspieszenie 7x – 20x, w zależności od poziomu optymalizacji kompilatora.

Mówienie o optymalizacji jest tutaj ważne, ponieważ dopracowany, zoptymalizowany interpreter może znacznie przewyższyć nieoptymalizujący naiwny kompilator. Ponieważ tworzenie kompilatora optymalizującego jest trudne i wymaga dużego wysiłku, jest mało prawdopodobne, aby Twoja „technologia B” miała taki poziom dojrzałości.

(Uwaga: Witryna gier komputerowych z testami porównawczymi ma mylącą strukturę, ale gdy osiągniesz tabelę czasową jednego problemu, zauważysz, że wydajność różnych języków jest wszędzie - często nie ma wyraźnej granicy wydajności pomiędzy skompilowanymi i interpretowanymi rozwiązaniami. Najważniejszą częścią witryny nie są wyniki testów porównawczych, ale dyskusje na temat tego, jak trudne są znaczące testy porównawcze).

Przy wyborze technologii samo wykonanie środowiska uruchomieniowego języka jest całkowicie nieistotne. Bardziej prawdopodobne jest, aby technologia spełniała pewne podstawowe ograniczenia (nasz budżet wynosi x USD, musimy być w stanie dostarczyć przed rrrr-mm-dd, musimy spełnić różne niefunkcjonalne wymagania) i że ma ona niższy poziom całkowity koszt posiadania (uwzględnienie wydajności programisty, kosztów sprzętu, kosztów okazji biznesowych, ryzyka błędów i nieoczekiwanych ograniczeń w technologii, kosztów utrzymania, kosztów szkolenia i zatrudnienia, ...). Np. W branży, w której najważniejszy jest czas wprowadzenia produktu na rynek, najlepiej pasowałaby technologia o najlepszej wydajności programistów. W przypadku dużej organizacji łatwość utrzymania i koszty długoterminowe mogą być bardziej interesujące.

amon
źródło
10
Jeśli uważasz, że „Witryna gier komputerowych z testami porównawczymi ma mylącą strukturę”, podaj adres URL konkretnej strony, która obsługuje Twój punkt, zamiast oczekiwać, że ludzie będą wyszukiwać z najwyższego poziomu w poszukiwaniu czegoś, czego nigdy nie znajdą! Pokazać; nie mów tylko.
igouy,
8
Jeśli uważasz, że „najważniejszą częścią witryny nie są wyniki testu porównawczego, ale dyskusje na temat tego, jak trudne są znaczące testy porównawcze”, podaj adresy URL tych stron. Pokazać; nie mów tylko.
igouy,
4
Byłoby to dla wygody tych, którzy czytają twoją odpowiedź. (Jestem tylko kimś, kto administruje testami porównawczymi).
igouy,
2
@amon łączący przykład k-nukleotydu w odpowiedzi sprawiłby, że byłby bardziej czytelny, a notatka bardziej przydatna, podobnie jak powiązanie dyskusji (bez przeczytania całej strony nie jest dla mnie oczywiste o jakich rozmowach mówisz).
David Moles,
1
Skąd, u licha, dostałeś 2-10X? Współczynnik zależy całkowicie od tego, ile czasu zajmuje pobranie i wysłanie do modułu obsługi dla każdego kodu bajtowego, w porównaniu z czasem, jaki zajmuje każdy moduł obsługi, a 10x byłoby możliwe tylko wtedy, gdyby cykl pobierania zajął 9 razy więcej niż moduł obsługi, co jest dziko nieprawdopodobnie. Częściej wykonanie jest zdominowane przez program obsługi. a cykl pobierania może być znikomy.
user207421,
18

Absolutnie możesz powiedzieć coś o wydajności skompilowanych / interpretowanych technologii. Ale najpierw musisz zdefiniować „wydajność”. Jeśli budujesz prosty pod względem obliczeniowym system wbudowany, wówczas „wydajność” prawdopodobnie skłania się ku stronie wykorzystania pamięci. Podczas gdy złożony obliczeniowo system działający na dużych zestawach danych sam zdefiniowałby „wydajność” w liczbie obliczeń na jednostkę czasu, ponieważ narzut pamięci z JVM lub .NET byłby znikomy.

Gdy zdecydujesz, co to jest „wydajność”, możesz powiedzieć coś w rodzaju „będziemy mieć w dowolnym momencie 50 miliardów obiektów w pamięci, a zinterpretowana technologia doda do każdego obiektu dodatkowe 8 bajtów na potrzeby zarządzania wewnętrznego, co odpowiada nakładowi pamięci 400 GB w porównaniu do techB, który nie dodaje tych danych ”

jhbh
źródło
12

To pytanie techniczne i masz już wiele dobrych odpowiedzi technicznych, ale chciałbym zwrócić uwagę na nieco inny aspekt twojej sytuacji: fakt, że nie możesz po prostu podjąć decyzji w rodzaju „technologii A lub technologii B” wyłącznie z przyczyn technicznych i / lub wydajnościowych.

Techniczne aspekty czegoś takiego to tylko niewielka część decyzji między A i B. Należy pamiętać o dziesiątkach innych czynników:

  • czy wiąże się to z jakimikolwiek kosztami licencji? Na przykład: musisz zapłacić (znaczną kwotę) za korzystanie z klastra maszyn SQL Server w porównaniu z korzystaniem z klastra maszyn PostgreSQL.
  • czy mam pracowników, którzy znają tę technologię (stos) i jej ekosystem? Jeśli tak, czy są dostępne? Jeśli nie, czy mogę zatrudnić? Ile będzie mnie to kosztować? A może szkolę już istniejące? Ile to będzie mnie kosztowało?
  • czego chce klient? Często może to być problem.
  • czy zalecana przeze mnie technologia jest gotowa do użytku produkcyjnego? A może to tylko aktualny szum, który może umrze? (np. pomyśl o Node.js, kiedy pojawił się po raz pierwszy)
  • czy technologia, którą polecam, dobrze pasuje do istniejącej architektury czy architektury, o której myślę? Czy też muszę wydać dużo pieniędzy, sprawiając, że współpracują ze sobą bezproblemowo?
  • i wiele innych aspektów, które zależą od konkretnej sytuacji.

Jak widać, przy podejmowaniu takiej decyzji należy rozważyć MASĘ rzeczy.

Wiem, że to nie odpowiada konkretnie na twoje pytanie, ale myślę, że daje to większy obraz twojej sytuacji i specyfiki takiej decyzji.

Radu Murzea
źródło
10

Częściowa ocena to ramy koncepcyjne odpowiednie do powiązania tłumaczy ustnych i kompilatorów.

Czy możemy sformułować ogólne stwierdzenia dotyczące wydajności kodu interpretowanego w porównaniu do kodu skompilowanego?

Językami programowania są specyfikacje (napisane w niektórych raportach, takich jak R5RS lub n1570 ). Są nie oprogramowanie, więc nie ma sensu mówić o wydajności . Ale niektóre języki programowania mogą mieć kilka implementacji, w tym tłumaczy i kompilatorów .

Nawet w tradycyjnie skompilowanych językach (tj. Językach, których implementacje są często kompilatorami), takich jak C, niektóre części są często interpretowane. Na przykład ciąg kontrola formatu printf (zdefiniowane w standardzie C) jest często „interpretować” (przez C standardowej biblioteki , która posiada printf funkcję przy użyciu zmiennych argumentów technik), ale niektóre kompilatory (w tym GCC ) są w stanie -w ograniczoną specyficznego przypadki - w celu optymalizacji i „skompilowania” go w wywołania niższego poziomu.

Niektóre implementacje, nawet w „interpreterach”, wykorzystują techniki kompilacji JIT (więc generuj kod maszynowy w czasie wykonywania ). Dobrym przykładem jest luajit . Inne implementacje (np. Python, Ocaml, Java, Parrot, Lua) tłumaczą kod źródłowy na kod bajtowy, który jest następnie interpretowany.

SBCL to „kompilator” Common Lisp, który dynamicznie tłumaczy każdą interakcję REPL (i wywołania evalitp.) Na kod maszynowy. Więc czujesz, że to tłumacz. Większość implementacji JavaScript w przeglądarkach (np. V8 ) wykorzystuje techniki kompilacji JIT.

Innymi słowy, różnica między tłumaczami a kompilatorami jest bardzo rozmyta (w rzeczywistości istnieje między nimi kontinuum), a praktycznie mówiąc, większość implementacji języka programowania często ma zarówno aspekt interpretera, jak i kompilatora (przynajmniej do kodu bajtowego).

Implementacja może być szybka lub powolna niezależnie od użycia większości technik podobnych do „kompilatora” lub „interpretera”.

Niektóre cechy językowe sprzyjają podejściu do tłumaczenia (i można je efektywnie skompilować tylko poprzez analizę całego programu ).

W przypadku niektórych rodzajów problemów warto zaprojektować oprogramowanie z niektórymi metodami metaprogramowania i zapewnia ono znaczne przyspieszenie. Można sobie wyobrazić, że biorąc pod uwagę określone dane wejściowe, program dynamicznie generuje specjalistyczny kod do jego przetworzenia. Jest to nawet możliwe w przypadku C lub C ++ (przy użyciu biblioteki JIT lub wygenerowaniu kodu C, kompilacji jako wtyczki, która jest ładowana dynamicznie).

Zobacz także to powiązane pytanie dotyczące Pythona i tamto

Basile Starynkevitch
źródło
7

W przypadku kodu takiego A = A + Bmożna skompilować do jednej lub dwóch instrukcji maszynowych, z których każda zajmuje określoną liczbę cykli. Żaden tłumacz nie może zrobić tego samego w tej liczbie cykli z prostego powodu.

Tłumacz interpretuje również własny zestaw instrukcji (nazywaj je kodami bajtowymi, kodami p, językiem pośrednim itp.). Za każdym razem, gdy widzi kod bajtowy, taki jak ADD, musi go jakoś wyszukać i rozgałęzić się do kodu, który dokonuje dodania.

Następnym razem to widzi, że musi powtarzać tego odnośnika, chyba, że ma sposób na zapamiętanie uprzedniej odnośnika. Jeśli ma sposób na zapamiętanie wcześniejszego wyszukiwania, nie jest to już tak zwany „tłumacz”, ale raczej kompilator „just-in-time” lub JITter.

Z drugiej strony...

W przypadku kodu callSomeFunction( ... some args ...), ile cykli spędzonych między wprowadzeniem tego kodu a jego pozostawieniem? Wszystko zależy od tego, co dzieje się w środku callSomeFunction. Może to być kilka, a może tryliony, nawet jeśli callSomeFunctionsam zostanie skompilowany. Jeśli to dużo, nie ma sensu dyskutować o koszcie interpretacji tego wiersza kodu - pieniądze są gdzie indziej.

Pamiętaj, że interpretowane języki mają swoją wartość, np. Nie trzeba ich kompilować. („Kompilacja” składni powierzchni do kodów bajtowych zajmuje trywialny czas. Weźmy na przykład R lub MATLAB.)

Potrzebna jest także elastyczność inteligentnych poziomów programowania. W Minsky's Society of Mind , rozdział 6.4 B -Brains, są programy A, które zajmują się światem, i są programy B, które zajmują się programami A, i mogą być dalsze poziomy. Programy, które piszą i zarządzają innymi programami, mogą być łatwiej wykonywane w systemach interpretacyjnych.

W Lisp możesz pisać, (+ A B)aby dodać A i B, ale po napisaniu masz tylko opcję, aby go uruchomić lub nie. Możesz także napisać, (eval (list '+ 'A 'B))który konstruuje program, a następnie wykonuje go. Może skonstruować coś innego.

Przedmiotem programu jest inny program . Łatwiej jest pisać w tłumaczonym języku (jednak, jak zauważa Jörg, nowsze wersje Lisp, podczas gdy mają możliwość evalkompilacji w locie, więc nie mają kary za tłumaczenie).

Mike Dunlavey
źródło
1
Uważam za interesujące, że mówisz, że pisanie programów na poziomie meta jest łatwiejsze w interpretowanych językach, ale użyj Lisp jako przykładu, w którym skompilowano większość implementacji.
Jörg W Mittag,
1
@ JörgWMittag: Jasne, ale wszystkie mają evali applyfunkcje, które są tłumaczami.
Mike Dunlavey,
2
Nie jestem pewien, że przynajmniej na SBCL evalnie jest interpretowane. I nie ma apply. Z pewnością istnieją implementacje, które zawierają tłumaczy, ale SBCL nie.
Jörg W Mittag
1
Interpreter może zoptymalizować warunki pętli w czasie wykonywania i zgnieść pozostałe iteracje. Jest to rzadko możliwe w skompilowanych programach. W szczególności Hotspot Oracle robi dokładnie to.
Basilevs,
2
@ JörgWMittag: Sure evalis not interpret ed . Jest to interpretować er .
Mike Dunlavey,
5

Rodzaj, w pewnym sensie, zależy, ale zgodnie z ogólną zasadą skompilowane - czy to przez JIT, czy statycznie skompilowane - środowisko będzie szybsze dla wielu zadań wymagających dużej mocy obliczeniowej - zakładając dla uproszczenia ten sam język.

Częściowo dlatego, że tłumaczone języki muszą mieć pętlę tłumacza, która czyta instrukcję, wybiera odpowiednią akcję do wykonania i wykonuje ją. W najlepszym przypadku, takim jak interpretacja kodu bajtowego Pythona lub Javy (tak jak robił to stary JVM), ma narzut kilku instrukcji i spowodował spustoszenie za pomocą predyktora gałęzi - bez ostatniej można spodziewać się ogromnych kar z powodu nieprzewidzianych zdarzeń. Nawet bardzo głupi JIT powinien to znacznie przyspieszyć.

To powiedziawszy, język interpretowany może oszukiwać. Na przykład Matlab ma zoptymalizowane procedury mnożenia macierzy i po kilku zmianach możesz uruchomić kod na GPU (zastrzeżenie: pracuję dla nVidii - każda wyrażona tutaj opinia jest moja i nie reprezentuje poglądu mojego pracodawcy). W ten sposób możesz pisać krótki i mocny kod wyższego poziomu, nie martwiąc się o szczegóły - ktoś się nim zajął i poświęcił czas i zasoby na jego optymalizację w języku niskiego poziomu. Nie ma w nim niczego odziedziczonego i nie zapobiega to, na przykład, Matlabowi do JIT kodu, ale często nie ma żadnego powodu, ponieważ narzut wywołania rutyny wysokiego poziomu jest minimalny w porównaniu z czasem spędzonym na niskim poziomie.

TL; DR - skompilowane programy mają ogromną przewagę wydajności nad interpretowanymi (porównanie jabłek z jabłkami patrz PyPy Speed ). Jednak szybkość pliku wykonywalnego jest tylko częścią problemu i może nie mieć większego wpływu na ogólną szybkość (jeśli czas jest spędzany głównie w bibliotekach). Liczy się także wdrożenie.

Maciej Piechotka
źródło
5

Twoje założenie jest uzasadnione, chociaż jest założeniem.

Nie zamierzam omawiać powodów, dla których skompilowany kod powinien być szybszy niż kod interpretowany: jeśli wiesz, jak działają komputery, będzie to oczywiste. Różnicą mogą być rzędy wielkości dla niektórych rodzajów problemów. Jeśli Twój recenzent poważnie kwestionuje ten ogólny przypadek, nie wie, o czym mówi.

Mogą mieć jednak rację, czy różnica jest znacząca w rodzaju tworzonej aplikacji. Jeśli jest to głównie We / Wy lub w większości wywoływanie bibliotek skompilowanych i nie ma dużo obliczeń, narzut związany z procesem interpretacji może być nieznaczny.

Ale mój post jest następujący: jako ekspert IT będziesz często wezwany do podejmowania szybkich decyzji w oparciu o ogólną wiedzę o tym, jak powinno działać. Wykonanie określonego testu może dać bardziej dokładną odpowiedź, ale będzie kosztować znacznie więcej i nie doprowadzi cię tam pierwszy.

Ale od czasu do czasu dasz się złapać. Zdarzyło mi się. Dokonujesz dobrego założenia, a potem okazuje się, że nie wziąłeś pod uwagę głupoty świata.

Ale nie potrafię wyjaśnić tak dobrze, jak moja ulubiona kreskówka Dilberta wszechczasów. Nic nie pokazuje lepiej niż niebezpieczeństwo bycia mądrym dupkiem.

alternatywny tekst

TL; DR: powinieneś mieć rację, ale na wszelki wypadek sprawdź prawdziwy świat.

rghome
źródło
3

O ile nie użyjesz czegoś nieco egzotycznego, twoim problemem nie będzie wydajność w interpretowanym języku A i kompilowanym języku B.

Ponieważ jeśli ty / twój zespół znasz A, a nie B, a więc piszesz o wiele lepszy kod w A niż B, możesz osiągnąć znacznie lepszą wydajność w A niż B. Jeśli masz ludzi znających jeden język, a język / biblioteki mogą praca, której potrzebujesz, trzymaj się jej.

Oto link o wyrażeniach regularnych w różnych językach; zobaczysz, że regex są lepiej zaimplementowane w niektórych językach, nawet jeśli są skompilowane lub nie: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

Walfrat
źródło
Problem polega na tym, że zespół może używać zarówno A, jak i B, i nie wskazał preferencji dla żadnego z nich, gdy poprosiłem ich o wkład.
EpicSam,
@EpicSam co z ich wcześniejszymi projektami?
Walfrat,
1
Zastosowano zarówno A, jak i B. Jednak chcą przejść do korzystania z 1 technologii dla wszystkich projektów. Wydajność obu technologii jest wystarczająca dla obecnych projektów. Jednak potencjalną wyższą wydajność jednego z nich należy wziąć pod uwagę, patrząc na potencjalne przyszłe projekty.
EpicSam,
3
@EpicSam lepiej poszukaj społeczności wokół języka i dostępnej biblioteki / frameworka, które pomogą Ci w twoich projektach.
Walfrat,
6
Zgadzam się z @Walfrat. Założę się, że językiem o „najwyższym potencjale” jest prosty montaż lub zestaw surowych instrukcji procesora. Ale nie mówimy o tych językach, ponieważ „oczywiste” jest, że posiadanie narzędzi takich jak kompilatory, interpretatory i wstępnie napisane biblioteki jest niezwykle ważne. Myślę, że dostępność narzędzi / wiedzy społeczności jest ważniejsza niż wybór między interpretacją / kompilacją
Ivan
1

Myślę, że mówienie o wydajności dwóch technologii po prostu nie jest dobrym pomysłem, ponieważ jedna jest kompilowana, a druga interpretowana. Jak stwierdzono w innych odpowiedziach, może to zależeć od obszaru zastosowania (niektóre języki mogą być zoptymalizowane, aby wykonywać niektóre operacje bardzo szybko i wykonywać inne rzeczy wolniej), a także od doświadczenia osób, które będą korzystać z tej technologii.

Nie sądzę, że uzasadnione jest oczekiwanie, że zwiększysz wydajność, jeśli weźmiesz kilka znakomitych koderów interpretowanych języków i zapewnisz im technologię, której nie znają - może teoretycznie ta ostatnia MOŻE przynieść lepszą wydajność, ale w rzeczywistości, bez niezbędnych umiejętności i doświadczenia nie wykorzystasz wszystkich możliwości optymalizacji.

Od jednego ze znanych pracowników firmy z Doliny Krzemowej słyszałem również, że wolą język, który jest prostszy w użyciu, ponieważ płacenie niektórym wykwalifikowanym programistom za bardziej skomplikowany, ale wysoce zoptymalizowany kod jest bardziej kosztowne i kłopotliwe niż po prostu kup więcej sprzętu, aby poradzić sobie z mniej wydajnym wdrażaniem, dlatego też należy wziąć to pod uwagę przy wyborze technologii.

KjMag
źródło
0

Kiedyś musiałem wydać podobne oświadczenie, aby uzasadnić wielką decyzję.

Po pierwsze, mogą nie chcieć wierzyć w skromnego inżyniera, więc znalazłem porównywalne testy porównawcze i zacytowałem je. Jest ich wiele, od ludzi takich jak Microsoft czy renomowane uniwersytety. I powiedzą coś takiego: Metoda A jest od 3 do 10 razy szybsza niż metoda B, w zależności od zmiennych X i Y.

Po drugie, możesz chcieć uruchomić własny test porównawczy, być może używając reprezentatywnego fragmentu danego kodu lub czegoś podobnego, co już masz. Uruchom go 1000 razy w ciągu nocy, więc naprawdę jest mierzalna różnica.

W tym momencie różnica (lub jej brak) między A i B powinna być tak wyraźna, że ​​wystarczy tylko ją przedstawić. Dlatego sformatuj wyniki wyraźnie, z diagramami, jeśli to możliwe, podając wszystkie założenia i definiując wszystkie użyte dane.

RedSonja
źródło
1
Problem z robieniem własnego testu porównawczego polega na tym, że skutecznie po prostu porównuję 2 konkretne programy napisane w A i B, a nie A i B jako całość. Powinno być możliwe tworzenie programów, które rozwiązują problem X zarówno w A, jak i B, gdzie A jest szybszy, a następnie przepisywać je w sposób B jest szybszy i odwrotnie. Zasadniczo pozwala to na cofnięcie się od wniosku, na przykład jeśli wolisz A, albo wybierz scenariusz, w którym A jest szybszy, lub po prostu zoptymalizuj wersję A, aż osiągnie lepsze wyniki niż w B. Dlatego mogliśmy podsumować wydajność tylko w konkretnym sprawa nie jest ogólna.
EpicSam
W zależności od tego, jak ważna i ważna jest ta decyzja, możesz zaimplementować reprezentatywną część funkcjonalności za pomocą A i B. Musisz uzasadnić, jak reprezentatywna jest Twoja sekcja i że nie próbujesz uprzedzać na korzyść swoich osobistych preferencji.
RedSonja,
1
@EpicSam Znajdź kogoś wyraźnie faworyzującego A i pozwól mu zoptymalizować test porównawczy dla A. Zrób to samo dla B. Musisz tylko upewnić się, że obaj programiści są na tym samym poziomie i spędzają mniej więcej tyle samo czasu. Nadal istnieje problem z wyborem benchmarku, ale pozwól, aby obaj programiści byli zaangażowani w decyzję; idealnie, niech zgodzą się na punkt odniesienia. Kolejnym problemem jest zmarnowany czas, ale można sobie z tym poradzić, wybierając coś prostego i użytecznego.
maaartinus
0

Argumentowałbym, że każdy język dynamiczny ma przewagę nad językami kompilowanymi statycznie: „Optymalizacje środowiska wykonawczego”

To jeden z powodów, dla których Java może być szybsza niż C ++

Tak, ładowanie dynamicznie pisanego języka zawsze będzie kosztowało tłumaczenie i będzie niekorzystne. Jednak po uruchomieniu interpreter może profilować i poprawiać częste ścieżki kodu za pomocą informacji wykonawczych, których języki statyczne nigdy nie będą miały

UWAGA: Cóż, Java jest językiem interpretowanym, a nie dynamicznym. Jest to jednak doskonały przykład tego, co można przyspieszyć dzięki informacjom wykonawczym

SystematicFrank
źródło
-3

... Twierdzę również, że skoro program można napisać na wiele sposobów, nadal jest możliwe, że program napisany w tech A może przewyższyć program napisany w tech B.

Kiedy przekazałem ten raport do recenzji, recenzent stwierdził, że nie podałem żadnego wyraźnego powodu, dla którego ogólnie koszty interpretacji byłyby na tyle duże, że moglibyśmy dojść do wniosku, że wydajność technologii B byłaby lepsza. ...

To byłoby moje podejście:

Ogólnie rzecz biorąc, tłumacze ustni są kompilowani, więc każda interpretowana technologia jest niczym więcej niż skompilowaną technologią, jeśli spojrzeć na nią na niskim poziomie. Dlatego skompilowane technologie są po prostu większe, a dzięki większej liczbie możliwości nigdy nie pogorszysz się, jeśli będziesz mądry (którym ogólnie jesteś). Zależy to od tego, ile informacji jest dostępnych w czasie kompilacji i ile informacji jest dostępnych tylko w czasie wykonywania oraz od tego, jak dobre są kompilatory i tłumacze, ale teoretycznie zawsze powinno być możliwe przynajmniej wyrównanie wydajności dowolnego interpretera z odpowiednim kompilatorem, tylko dlatego, że tłumacze są wytwarzani przez kompilatory. To możliwe, nie oznacza to jednak, że dotyczy to technologii A i B.

W praktyce po prostu powiedz recenzentowi o wszystkich dostępnych testach porównawczych, w których porównywane są skompilowane i zinterpretowane systemy. Następnie poproś go o zasugerowanie tłumacza, który przebije Twój zoptymalizowany algorytm kodowany w asemblerze.

Należy dodać, że takie ogólne stwierdzenie wcale nie pomaga w porównaniu dwóch specyficznych technologii A i B. Tam wybór A i B ma o wiele, wiele większe znaczenie, niż jeśli są one interpretowane lub kompilowane.

Trilarion
źródło
2
Totalnie źle. Nie rozumiesz, jak działają tłumacze, a jak kompilatory.
rghome