Dlaczego PyPy nie został dołączony do standardowego Pythona?


165

Patrzyłem na PyPy i zastanawiałem się, dlaczego nie został zaadaptowany do głównych dystrybucji Pythona. Czy takie rzeczy jak kompilacja JIT i mniejsze zużycie pamięci nie poprawią znacznie szybkości całego kodu Pythona?

Krótko mówiąc, jakie są główne wady PyPy, które powodują, że pozostaje oddzielnym projektem?


4
Ponadto pypy nie obsługuje jeszcze numpy. morepypy.blogspot.ch/2012/09/numpy-on-pypy-status-update.html
rthiago

A obsługa numpy jedynie zarysowuje powierzchnię tego, czego wymagałyby naukowe aplikacje komputerowe przed przejściem na PyPy. Oto kilka przekonujących przemyśleń oryginalnego autora numpy: technicaldiscovery.blogspot.com/2011/10/…
Stuart Berg

3
Myślę, że te odpowiedzi i komentarze są nieaktualne
Marlon Abeykoon

Odpowiedzi:


249

PyPy nie jest rozwidleniem CPythona, więc nigdy nie można go połączyć bezpośrednio z CPythonem.

Teoretycznie społeczność Pythona mogłaby uniwersalnie przyjąć PyPy, PyPy mogłoby stać się implementacją referencyjną, a CPython mógłby zostać przerwany. Jednak PyPy ma swoje słabości:

  • CPython jest łatwy do zintegrowania z modułami Pythona napisanymi w C, co jest tradycyjnym sposobem, w jaki aplikacje Pythona obsługiwały zadania intensywnie wykorzystujące procesor (patrz na przykład projekt SciPy).
  • Sam krok kompilacji PyPy JIT kosztuje czas procesora - tylko dzięki wielokrotnemu uruchamianiu skompilowanego kodu staje się on ogólnie szybszy. Oznacza to, że czasy uruchamiania mogą być dłuższe, a zatem PyPy niekoniecznie jest tak wydajne do uruchamiania kodu kleju lub trywialnych skryptów.
  • Zachowanie PyPy i CPython nie jest identyczne pod każdym względem, szczególnie jeśli chodzi o „szczegóły implementacji” (zachowanie, które nie jest określone w języku, ale jest nadal ważne na poziomie praktycznym).
  • CPython działa na większej liczbie architektur niż PyPy i został z powodzeniem przystosowany do pracy w architekturach osadzonych w sposób, który może być niepraktyczny dla PyPy.
  • Schemat zliczania referencji CPythona do zarządzania pamięcią prawdopodobnie ma bardziej przewidywalny wpływ na wydajność niż różne systemy GC PyPy, chociaż niekoniecznie jest to prawdą w przypadku wszystkich strategii „czystego GC”.
  • PyPy nie obsługuje jeszcze w pełni Pythona 3.x, chociaż jest to aktywny element pracy.

PyPy to świetny projekt, ale szybkość wykonywania zadań intensywnie wykorzystujących procesor to nie wszystko, aw wielu aplikacjach jest to najmniejszy problem. Na przykład Django może działać na PyPy, co przyspiesza tworzenie szablonów, ale sterowniki bazy danych CPythona są szybsze niż PyPy; ostatecznie to, która implementacja jest bardziej wydajna, zależy od tego, gdzie jest wąskie gardło w danej aplikacji.

Inny przykład: można by pomyśleć, że PyPy świetnie nadaje się do gier, ale większość strategii GC, takich jak te używane w PyPy, powoduje zauważalne wahania. W przypadku CPythona większość elementów gry wymagających dużej mocy obliczeniowej jest przenoszona do biblioteki PyGame, z której PyPy nie może skorzystać, ponieważ PyGame jest głównie zaimplementowany jako rozszerzenie C (choć zobacz: pygame-cffi). Nadal uważam, że PyPy może być świetną platformą do gier, ale nigdy nie widziałem, aby faktycznie była używana.

PyPy i CPython mają radykalnie różne podejścia do podstawowych pytań projektowych i dokonują różnych kompromisów, więc żadne z nich nie jest „lepsze” od innych w każdym przypadku.


4
Nie jest prawdą, że PyPy nie nadaje się do uruchamiania skryptów. Jego czas uruchamiania jest prawie taki sam jak CPython, a jego szybkość interpretacji jest podobna.
Lucian,

6
Warto zauważyć, że PyPy jest teraz dostarczany z przyrostowym GC i w konsekwencji jest potencjalnie bardziej odpowiedni dla gier.
porgarmingduod

63

Po pierwsze, nie jest w 100% kompatybilny z Pythonem 2.xi ma tylko wstępne wsparcie dla 3.x.

To też nie jest coś, co można by łączyć - implementacja Pythona dostarczana przez PyPy jest generowana przy użyciu stworzonego przez nich frameworka, który jest niesamowicie fajny, ale także całkowicie różni się od istniejącej implementacji CPythona. Musiałaby to być całkowita wymiana.

Istnieje kilka bardzo konkretnych różnic między PyPy i CPython, z których największa dotyczy modułów rozszerzeń obsługiwane są - co, jeśli chcesz wyjść poza standardową bibliotekę, to wielka sprawa.

Warto również zauważyć, że PyPy nie jest uniwersalnie szybszy.


54

Zobacz ten film Guido van Rossuma . Mówi o tym samym pytaniu, które zadałeś w 12 min i 33 sek.

Najważniejsze:

  • brak kompatybilności z Python 3
  • brak obsługi rozszerzeń
  • nieodpowiedni jako kod kleju
  • szybkość to nie wszystko

W końcu to on decyduje ...


3
+1 dla linku Z bezpośrednim linkiem do odpowiedniej części filmu! Również +1 za przezabawnie prawdomówną ankietę Guido van Rossuma „Ile osób używa PyPy w produkcji? ... bez rąk? Kaszle Cóż, myślę, że wciąż jest nadzieja [dla CPythona]”.
Trevor Boyd Smith

15

Jednym z powodów może być to, że według strony PyPy , obecnie działa ona tylko na 32- i 64-bitowej architekturze Intel x86, podczas gdy CPython działa również na innych platformach. Wynika to prawdopodobnie z ulepszeń szybkości w PyPy specyficznych dla platformy. Chociaż szybkość to dobra rzecz, ludzie często chcą, aby implementacje językowe były jak najbardziej niezależne od platformy.


6
Zauważ, że zaplecze ARM jest „prawie gotowe”, a zaplecze PowerPC to WIP. Należy również zauważyć, że odnosi się to tylko do kompilatora JIT, a przeniesienie JIT do nowej architektury wymaga jedynie zaimplementowania generatora kodu dla stosunkowo prostego i niskiego poziomu IR, nic więcej.

1
Od 2018 roku PyPy działa teraz na większej liczbie architektur x86 (32/64 bity na Linunx, Windows, MacOS i BSD), ale także na Linuksie, nowszym sprzęcie ARM (ARMv6 lub ARMv7, z VFPv3), big- i little-endian warianty PPC64 i s390x.
Frédéric Grosshans,


6

Oprócz wszystkiego, co zostało tutaj powiedziane, PyPy nie jest tak solidny jak CPython pod względem błędów. Dzięki SymPy w ciągu ostatnich kilku lat znaleźliśmy około tuzina błędów w PyPy, zarówno w wydanych wersjach, jak iw nightlies.

Z drugiej strony, kiedykolwiek znaleźliśmy tylko jeden błąd w CPythonie i był to wersja wstępna.

Ponadto nie pomijaj braku obsługi Python 3. Nikt w podstawowej społeczności Pythona już nawet nie dba o Python 2. Pracują nad kolejnymi dużymi rzeczami w Pythonie 3.4, które będzie piątym głównym wydaniem Pythona 3. Faceci z PyPy nadal nie mają żadnego z nich. Muszą więc nadrobić zaległości, zanim staną się rywalami.

Nie zrozum mnie źle. PyPy jest niesamowity. Ale nadal jest daleki od bycia lepszym niż CPython pod wieloma bardzo ważnymi względami.

A tak przy okazji, jeśli używasz SymPy w PyPy, nie zobaczysz mniejszego zużycia pamięci (ani też przyspieszenia). Zobacz https://bitbucket.org/pypy/pypy/issues/1447/ .


2
Od 2018 roku mogę potwierdzić, że widziałem przyspieszenia o mniej więcej rzędzie wielkości w różnych zastosowaniach sympy
Frédéric Grosshans

1
@ FrédéricGrosshans ciekawe. Będę musiał ponownie spróbować go porównać.
asmeurer
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.