PyPy - jak może pokonać CPython?

Z bloga Google Open Source :

PyPy to reimplementacja Pythona w Pythonie, wykorzystująca zaawansowane techniki w celu uzyskania lepszej wydajności niż CPython. Wiele lat ciężkiej pracy w końcu się opłaciło. Nasze wyniki prędkości często przekraczają CPython, od bycia nieco wolniejszym, do przyspieszeń do 2x w prawdziwym kodzie aplikacji, do przyspieszeń do 10x w małych testach porównawczych.

Jak to jest możliwe? Której implementacji Python użyto do implementacji PyPy? CPython ? A jakie są szanse, że PyPyPy lub PyPyPyPy pokonają swój wynik?

(Na powiązaną notatkę ... dlaczego ktoś miałby spróbować czegoś takiego?)

Pytanie 1 Jak to jest możliwe?

Ręczne zarządzanie pamięcią (czyli to, co CPython robi z liczeniem) może być wolniejsze niż automatyczne zarządzanie w niektórych przypadkach.

Ograniczenia w implementacji interpretera CPython wykluczają pewne optymalizacje, które może wykonać PyPy (np. Drobnoziarniste zamki).

Jak wspomniał Marcelo, JIT. Będąc w stanie potwierdzić, że typ obiektu może zaoszczędzić Ci konieczności wykonywania wielu dereferencji wskaźnika, aby w końcu dojść do metody, którą chcesz wywołać.

Q2 Której implementacji Python użyto do implementacji PyPy?

Interpretator PyPy jest zaimplementowany w RPython, który jest statycznie typowanym podzbiorem Pythona (język, a nie interpreter CPython). - Patrz https://pypy.readthedocs.org/en/latest/architecture.html informacje .

Pytanie 3 A jakie są szanse, że PyPyPy lub PyPyPyPy pokonają swój wynik?

Zależy to od wdrożenia tych hipotetycznych tłumaczy. Jeśli jeden z nich na przykład wziął źródło, przeprowadził na nim jakąś analizę i przekształcił go bezpośrednio w ściśle określony kod asemblera po uruchomieniu, wyobrażam sobie, że byłby on znacznie szybszy niż CPython.

Aktualizacja: Ostatnio, na starannie dobrany przykład , pypy pokonał podobny program skompilowany z C gcc -O3. To przemyślany przypadek, ale zawiera pewne pomysły.

Pytanie 4 Dlaczego ktoś miałby spróbować czegoś takiego?

Z oficjalnej strony. https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement

Naszym celem jest zapewnienie:

• wspólne ramy tłumaczeń i wsparcia dla tworzenia
  implementacji języków dynamicznych, kładąc nacisk na czyste
  oddzielenie specyfikacji języka od
  aspektów implementacyjnych . Nazywamy to RPython toolchain_.

• zgodna, elastyczna i szybka implementacja języka Python_, która wykorzystuje powyższy zestaw narzędzi, aby umożliwić nowe zaawansowane funkcje wysokiego poziomu bez konieczności kodowania szczegółów niskiego poziomu.

Dzięki oddzieleniu problemów w ten sposób nasza implementacja Pythona - i innych języków dynamicznych - jest w stanie automatycznie wygenerować kompilator Just-in-Time dla dowolnego języka dynamicznego. Pozwala także na podejście polegające na mieszaniu i dopasowywaniu do decyzji, w tym wielu, które historycznie znajdowały się poza kontrolą użytkownika, takich jak platforma docelowa, modele pamięci i wątków, strategie usuwania śmieci i zastosowane optymalizacje, w tym to, czy JIT w pierwszej kolejności.

Kompilator C gcc jest zaimplementowany w C. Kompilator Haskell GHC jest napisany w Haskell. Czy masz jakiś powód, dla którego interpreter / kompilator języka Python nie jest pisany w języku Python?

„PyPy to reimplementacja Pythona w Pythonie” jest dość mylącym sposobem opisania PyPy, IMHO, chociaż technicznie jest to prawdą.

Istnieją dwie główne części PyPy.

1. Ramy tłumaczeń
2. Tłumacz

Struktura tłumaczenia jest kompilatorem. Kompiluje kod RPython do C (lub innych celów), automatycznie dodając takie aspekty, jak wyrzucanie elementów bezużytecznych i kompilator JIT. Nie może obsługiwać dowolny kod Python, tylko RPython.

RPython jest podzbiorem normalnego Pythona; cały kod RPython jest kodem Python, ale nie na odwrót. Nie ma formalnej definicji RPython, ponieważ RPython jest w zasadzie tylko „podzbiorem Pythona, który może być przetłumaczony przez środowisko translacji PyPy”. Ale aby zostać przetłumaczonym, kod RPython musi być wpisany statycznie (typy są wywnioskowane, nie deklarujesz ich, ale wciąż jest to ściśle jeden typ na zmienną) i nie możesz robić takich rzeczy jak deklarowanie / modyfikowanie funkcji / klasy w czasie wykonywania.

Tłumacz to normalny interpreter języka Python napisany w RPython.

Ponieważ kod RPython jest normalnym kodem w języku Python, można go uruchomić na dowolnym interpretera języka Python. Ale żadne z twierdzeń dotyczących prędkości PyPy nie pochodzi z takiego działania; jest to tylko szybki cykl testowy, ponieważ tłumaczenie tłumacza zajmuje dużo czasu.

Mając to na uwadze, powinno być od razu oczywiste, że spekulacje na temat PyPyPy lub PyPyPyPy w rzeczywistości nie mają żadnego sensu. Masz tłumacza napisanego w RPython. Tłumaczysz go na kod C, który szybko wykonuje Python. Tam proces się kończy; nie ma już RPython do przyspieszenia poprzez ponowne przetworzenie.

Zatem „Jak to możliwe, że PyPy jest szybszy niż CPython” również staje się dość oczywiste. PyPy ma lepszą implementację, w tym kompilator JIT (uważam, że generalnie nie jest tak szybki bez kompilatora JIT, co oznacza, że ​​PyPy jest szybszy tylko dla programów podatnych na kompilację JIT). CPython nigdy nie został zaprojektowany jako wysoce optymalizująca implementacja języka Python (choć starają się, aby była to wysoce zoptymalizowana implementacja, jeśli podążasz za różnicą).

Naprawdę innowacyjny fragment projektu PyPy polega na tym, że nie piszą ręcznie skomplikowanych schematów GC ani kompilatorów JIT. Piszą interpreter stosunkowo prosto w RPython, a dla wszystkich RPython jest niższy poziom niż Python, to wciąż jest zorientowany obiektowo język zbierania śmieci, znacznie wyższy poziom niż C. Następnie struktura tłumaczenia automatycznie dodaje rzeczy takie jak GC i JIT. Tak więc ramy tłumaczenia są ogromnewysiłek, ale równie dobrze odnosi się do interpretera python PyPy, jednak zmieniają one swoją implementację, pozwalając na większą swobodę eksperymentowania w celu poprawy wydajności (bez martwienia się o wprowadzenie błędów GC lub aktualizację kompilatora JIT, aby poradzić sobie ze zmianami). Oznacza to również, że kiedy zaczną implementować interpreter języka Python3, automatycznie uzyska te same korzyści. I wszyscy inni tłumacze napisani w ramach PyPy (których jest wiele na różnych etapach języka polskiego). Wszyscy tłumacze korzystający ze środowiska PyPy automatycznie obsługują wszystkie platformy obsługiwane przez środowisko.

Tak więc prawdziwą zaletą projektu PyPy jest oddzielenie (w jak największym stopniu) wszystkich elementów wdrażania wydajnego niezależnego od platformy tłumacza dla dynamicznego języka. A potem wymyśl jedno dobre wdrożenie w jednym miejscu, które może być ponownie wykorzystane przez wielu tłumaczy. Nie jest to natychmiastowa wygrana, jak „mój program w Pythonie działa teraz szybciej”, ale jest to świetna perspektywa na przyszłość.

I może szybciej uruchomić Twój program Python (być może).

PyPy jest zaimplementowany w Pythonie, ale implementuje kompilator JIT do generowania natywnego kodu w locie.

Powodem do wdrożenia PyPy na Pythonie jest prawdopodobnie to, że jest to po prostu bardzo produktywny język, zwłaszcza że kompilator JIT sprawia, że ​​wydajność języka hosta jest nieco nieistotna.

PyPy jest napisany w języku Python z ograniczeniami. O ile mi wiadomo, nie działa na interpretera CPython. Python z ograniczeniami jest podzbiorem języka Python. AFAIK, interpreter PyPy jest kompilowany do kodu maszynowego, więc po zainstalowaniu nie używa interpretera python w czasie wykonywania.

Wydaje się, że twoje pytanie oczekuje, że interpreter PyPy działa na CPython podczas wykonywania kodu. Edycja: Tak, aby użyć PyPy, najpierw przetłumacz kod Pythona PyPy na C i buduj z gcc, na bajtowy kod jvm lub na kod CLI .Net. Zobacz Pierwsze kroki