Dlaczego nie powinienem używać PyPy zamiast CPython, jeśli PyPy jest 6,3 razy szybszy?

685

Dużo słyszałem o projekcie PyPy . Twierdzą, że jest 6,3 razy szybszy niż interpreter CPython na ich stronie .

Ilekroć mówimy o dynamicznych językach, takich jak Python, szybkość jest jednym z najważniejszych problemów. Aby rozwiązać ten problem, mówią, że PyPy jest 6,3 razy szybszy.

Druga kwestia to równoległość, niesławna blokada globalnego tłumacza (GIL). W tym celu PyPy mówi, że może dać Python bez GIL .

Jeśli PyPy może rozwiązać te wielkie wyzwania, jakie są jego słabości, które uniemożliwiają szersze przyjęcie? To znaczy, co zapobiega kogoś takiego jak ja, typowy Python dewelopera, z włączeniem do pypy teraz ?

chanty
źródło
30
Czyściłem komentarze, ponieważ większość z nich była rzeczami, które powinny zostać doprecyzowane w odpowiedziach (a w niektórych przypadkach są), lub wcale nie powinny być powiedziane. Zredagowano także w celu rozwiązania kilku wątpliwości dotyczących podmiotowości tego pytania. Spróbuj odpowiedzieć na podstawie faktów i, jeśli to możliwe, wykonaj kopię zapasową twierdzeń w źródłach!
Shog9
3
Często korzystam z Pypy. Zwykle działa bardzo dobrze. Jednak, chociaż Pypy jest nieco szybszy w przypadku wielu obciążeń procesora, w rzeczywistości jest wolniejszy w przypadku obciążeń I / O, które na niego rzuciłem. Na przykład napisałem program do tworzenia kopii zapasowych deduplikacji o nazwie backshift. W przypadku początkowej kopii zapasowej, która wykonuje wiele fragmentów plików, pypy jest świetna. Ale w przypadku kolejnych kopii zapasowych, które głównie aktualizują znaczniki czasu, CPython jest szybszy.
dstromberg

Odpowiedzi:

657

UWAGA: PyPy jest teraz bardziej dojrzały i lepiej obsługiwany niż w 2013 roku, kiedy zadano to pytanie. Unikaj wyciągania wniosków z nieaktualnych informacji.


  1. Pypy, jak inni zostały szybko wymienić, ma wątpliwy wsparcie dla rozszerzeń C . To ma wsparcia, ale zazwyczaj na wolniejszy niż Python prędkości i to w najlepszym razie niepewna. Dlatego wiele modułów po prostu wymaga CPython. PyPy nie obsługuje numpy PyPy obsługuje teraz numpy . Niektóre rozszerzenia nadal nie są obsługiwane (Pandy, SciPy itp.). Przed wprowadzeniem zmiany zapoznaj się z listą obsługiwanych pakietów .
  2. Obsługa języka Python 3 jest obecnie eksperymentalna. właśnie osiągnął stabilny! Od 20 czerwca 2014 PyPy3 2.3.1 - Fulcrum jest już dostępny !
  3. PyPy czasami nie jest tak naprawdę szybsze dla „skryptów”, do których wiele osób używa Pythona. Są to krótko działające programy, które robią coś prostego i małego. Ponieważ PyPy jest kompilatorem JIT, jego główne zalety wynikają z długiego czasu działania i prostych typów (takich jak liczby). Szczerze mówiąc, prędkości przed JIT PyPy są dość złe w porównaniu do CPython.
  4. Bezwładność . Przejście na PyPy często wymaga zmiany ustawień, co dla niektórych osób i organizacji jest po prostu zbyt dużym nakładem pracy.

To są główne powody, które mnie dotyczą, powiedziałbym.

Veedrac
źródło
14
Miło, że wspominałeś o ponownym narządzaniu Na przykład mój host ma do wyboru Python 2.4 i 2.5; a „główny producent oprogramowania rozrywkowego” w mojej okolicy korzysta z wersji 2.6 bez planów aktualizacji wkrótce. Czasami odkrycie kosztu konwersji może być dużym, kosztownym wysiłkiem.
Mike Housky,
19
PyPy będąc „tak szybkim jak C” bardziej dotyczy ogólnego C niż wysoce zoptymalizowanych wielowątkowych bibliotek C obsługujących pamięć podręczną używanych w liczbach. W przypadku liczb, Python jest po prostu używany do przesyłania wskaźników do dużych tablic. Zatem PyPy jest „tak szybki jak C” oznacza „twoje wskaźniki + metadane są przenoszone tak szybko jak C”. Żaden problem. Więc po co w ogóle zawracać sobie głowę Pythonem? Zobacz podpisy funkcji w cblas i lapacke.
cjordan1
12
@ cjordan1: Nie rozumiem tego, co mówisz. Wysokopoziomowe konstrukcje numpy są niezwykle ekspresyjne ( np.sum(M[1:2*n**2:2, :2*n**2] * M[:2*n**2:2, :2*n**2].conjugate(), axis=1)?) W Pythonie, co czyni Python bardzo odpowiednim dla społeczności naukowej. Dodatkowo, wykonywanie nieintensywnych części w Pythonie i odpalanie do C dla mniejszych intensywnych pętli jest powszechną i użyteczną strategią.
Veedrac
26
@ Veedrac To właśnie miałem na myśli. Jak w „Idź, popatrz na sygnatury funkcji w cblas i lapacke”, ponieważ są one tak długie i trudne w użyciu, że od razu zrozumiesz, dlaczego używamy Pythona do przesyłania wskaźników i metadanych.
cjordan1
5
@ tommy.carstensen To nie jest tak naprawdę dobre miejsce do zagłębiania się, ale spróbuję. 1. Było to o wiele bardziej prawdziwe, kiedy to napisałem, niż jest teraz. 2. „Skrypty” są często ciężkie dla IO. We / Wy PyPy jest nadal często wolniejsze niż CPython - wcześniej było znacznie wolniejsze. 3. PyPy był wcześniej wolniejszy niż CPython w obsłudze łańcuchów - teraz jest często lepszy i rzadko gorzej. 4. Wiele „skryptów” to po prostu kod kleju - przyspieszenie interpretera nie poprawi w tym przypadku ogólnych czasów działania. 5. Czasy rozgrzewania PyPy były dłuższe - skrypty o krótkim czasie działania rzadko były w stanie wygenerować dużo gorącego kodu.
Veedrac
104

Ta strona nie twierdzi, że PyPy jest 6,3 razy szybszy niż CPython. Cytować:

Średnia geometryczna wszystkich testów porównawczych jest 0,16 lub 6,3 razy szybsza niż CPython

Jest to zupełnie inne oświadczenie niż złożone oświadczenie, a kiedy zrozumiesz różnicę, zrozumiesz co najmniej jeden zestaw powodów, dla których nie możesz po prostu powiedzieć „użyj PyPy”. Może to zabrzmieć jak wybieranie nitów, ale zrozumienie, dlaczego te dwa stwierdzenia są zupełnie inne, jest niezbędne.

Aby to rozbić:

  • Oświadczenie, które składają, dotyczy tylko stosowanych przez nich testów porównawczych. Nie mówi absolutnie nic o twoim programie (chyba że twój program jest dokładnie taki sam jak jeden z ich testów porównawczych).

  • Oświadczenie dotyczy średnio grupy testów porównawczych. Nie ma twierdzenia, że ​​uruchomienie PyPy da 6,3-krotną poprawę nawet w przypadku programów, które przetestowały.

  • Nie ma twierdzenia, że ​​PyPy uruchomi nawet wszystkie programy, które CPython w ogóle uruchamia , nie mówiąc już o szybszym.

spookylukey
źródło
15
Oczywiście nie ma żadnych twierdzeń, że PyPy będzie szybciej uruchamiał cały kod Pythona. Ale jeśli weźmiesz całą czystą aplikację Python, założę się, że znaczna większość z nich będzie działać znacznie szybciej (> 3 razy) na PyPy niż na CPython.
Robert Zaremba
18
Żaden z twoich dwóch pierwszych punktów nie ma sensu. Jak możesz powiedzieć, że testy porównawcze mówią „absolutnie nic o twoim programie”. Jest całkiem oczywiste, że testy porównawcze nie są idealnym wskaźnikiem wszystkich rzeczywistych aplikacji, ale z pewnością mogą być przydatne jako wskaźnik. Również nie rozumiem, co uważasz za wprowadzające w błąd, że zgłaszają średnią grupę testów porównawczych. Podają dość wyraźnie, że to średnia. Jeśli programista nie rozumie, czym jest średnia, mają o wiele poważniejsze obawy niż znajomość języka.
Sean Geoffrey Pietz
6
@SeanGeoffreyPietz - Nie twierdziłem, że strona PyPy była w jakikolwiek sposób myląca - dokładnie przedstawili swoje wyniki. Ale pierwotne pytanie źle je zacytowało i wykazało, że autor nie zrozumiał znaczenia słowa „średnia”. Wiele indywidualnych testów porównawczych nie jest 6,3 razy szybszych. A jeśli użyjesz innego rodzaju średniej, otrzymasz inną wartość, więc „6,3 x szybsze” nie jest wystarczającym podsumowaniem „średnia geometryczna jest 6,3 x szybsza”. „Grupa A jest Z razy szybsza niż grupa B” jest zbyt ogólnikowa, aby mogła mieć znaczenie.
spookylukey
6
-1: @spookylukey Wydaje się, że sugerujesz, że zestaw testów jest stronniczy bez dostarczania dowodów na poparcie roszczenia. Krytyka zawsze powinna być poparta dowodami!
Evgeni Sergeev
5
@EvgeniSergeev - nie, sugeruję, że wszystkie testy porównawcze są stronnicze! Oczywiście niekoniecznie celowo. Przestrzeń możliwych użytecznych programów jest nieskończona i niezwykle zróżnicowana, a zestaw testów porównawczych mierzy tylko wydajność tych testów. Pytanie „o ile szybszy jest PyPy niż CPython?” jest jak pytanie „o ile szybciej, jeśli Fred niż Joe?”, o czym OP chce wiedzieć.
spookylukey
74

Ponieważ pypy nie jest w 100% kompatybilny, wymaga skompilowania 8 gigabajtów pamięci RAM, jest ruchomym celem i jest wysoce eksperymentalny, gdy cpython jest stabilny, domyślny cel dla producentów modułów na 2 dekady (w tym rozszerzenia c, które nie działają na pypy ) i już szeroko wdrożony.

Pypy prawdopodobnie nigdy nie będzie implementacją referencyjną, ale jest to dobre narzędzie.

Tryt21
źródło
2
Według pypy.org/download.html PyPy potrzebuje 4 GB pamięci RAM do skompilowania (w systemie 64-bitowym), a nie 8. Na tej stronie jest też opcja zrobienia tego poniżej 3 GB w razie potrzeby.
knite
4
@knite 1: to nowość od 2015 r., dokumentacja w przeszłości czytała 8 GB. 2: w praktyce w 2015 roku nadal potrzebujesz co najmniej 8, z 6-7 darmowymi.
Tritium21
4
Wymagania dotyczące pamięci do kompilacji nie są tak istotne, jeśli używasz kompilacji lub dystrybucji . Jeśli chodzi o „ruchomy cel i wysoce eksperymentalny”, czy możesz podać kilka przykładów rzeczy, które się psują? Ponownie, jeśli ludzie używają kompilacji wersji zamiast kompilacji nocnych lub źródła, czy nie mają uzasadnionego oczekiwania co do funkcjonalności?
smci
@smci To starożytne pytanie oparte na starożytnych danych i dawnych odpowiedziach. Rozważ to pytanie i każdą odpowiedź jako historyczną dla stanu pypy 4 lata temu.
Tryt 21
1
@ Tritium21: Interesuje mnie tylko aktualna odpowiedź. Co to jest? Możesz zredagować swoją odpowiedź, aby powiedzieć „Od 2013 r. Porównanie pypy z wersją 2.x Pythona było ...” Również jeśli oświadczenie „6.3x średnia geometryczna” w pytaniu jest nieaktualne ( ponieważ z 4/2017 twierdzą, że 7,5x, ale nawet wtedy zależy od testów porównawczych ... ), to też wymaga edycji (numery wersji, najnowsze dane itp.) Myślę, że pakiet testów porównawczych nie jest zbyt istotny, prawie nikt nie uruchomiłby raytracing w języku skryptowym na CPU obecnie. Znalazłem pybenchmarks.org
smci,
37

Drugie pytanie jest łatwiejsze do odpowiedzi: zasadniczo możesz użyć PyPy jako zamiennika drop-in, jeśli cały kod jest czystym Pythonem. Jednak wiele powszechnie używanych bibliotek (w tym niektóre biblioteki standardowe) są napisane w C i skompilowane jako rozszerzenia Pythona. Niektóre z nich mogą być przystosowane do współpracy z PyPy, niektóre nie. PyPy zapewnia to samo „skierowane do przodu” narzędzie, jak Python --- to znaczy, że jest Python --- ale jego elementy wewnętrzne są różne, więc narzędzia łączące się z tymi elementami wewnętrznymi nie będą działać.

Jeśli chodzi o pierwsze pytanie, wyobrażam sobie, że jest to coś w rodzaju Catch-22 z pierwszym: PyPy ewoluuje szybko, starając się poprawić szybkość i poprawić interoperacyjność z innym kodem. Dzięki temu jest bardziej eksperymentalny niż oficjalny.

Myślę, że możliwe jest, że jeśli PyPy przejdzie w stan stabilny, może zacząć być szerzej wykorzystywany. Myślę też, że byłoby dobrze, gdyby Python odszedł od swoich podstaw C. Ale to się nie stanie przez jakiś czas. PyPy nie osiągnął jeszcze masy krytycznej, w której jest prawie wystarczająco użyteczny, aby zrobić wszystko, co chcesz, co zmotywuje ludzi do uzupełnienia braków.

BrenBarn
źródło
17
Nie sądzę, że C jest językiem, który wkrótce się gdziekolwiek wybiera (chciałbym powiedzieć, że nie zniknie za naszego życia). dopóki nie będzie innego języka, który będzie działał w dowolnym miejscu, będziemy mieć C. (zwróć uwagę, JVM jest napisany w C. Nawet java, język, który „biegnie wszędzie” potrzebuje C ze względu na swoją wszechstronność.) W przeciwnym razie zgadzam się z tym postem w większości swoich punktów.
Tritium21,
7
@ Tritium21: Tak, właśnie tam redaguję. Nie mam nic przeciwko istniejącemu C, ale myślę, że zależność Pythona od C jest bardzo szkodliwa, a PyPy jest doskonałym przykładem tego: teraz mamy szansę uzyskać szybszego Pythona, ale lata nas polegają na C O wiele lepiej byłoby, gdyby Python stał na własnych nogach. Jest nawet w porządku, jeśli sam Python jest napisany w C, ale problemem jest istnienie mechanizmu rozszerzenia, który zachęca ludzi do rozszerzania Pythona w sposób zależny od C.
BrenBarn
4
miecz dwustronny - częścią tego, co sprawiło, że Python jest tak popularny, jest jego zdolność do rozszerzania innych aplikacji i rozszerzania się o inne aplikacje. Jeśli to zabierzesz, nie sądzę, że będziemy rozmawiać o pythonie.
Tritium21,
10
@BrenBarn Głupotą jest twierdzenie, że zależność Pythona od C jest szkodliwa. Bez C-API Pythona większość naprawdę potężnych bibliotek i wspaniałej interakcji, którą Python zyskał w młodości (pod koniec lat 90.), w tym cały ekosystem liczbowy / naukowy oraz interfejsy GUI, nie byłyby możliwe. Rozejrzyj się, aby uzyskać pewne spojrzenie na cały wszechświat zastosowań Pythona, zanim wydasz takie ogólne instrukcje.
Peter Wang
4
@PeterWang Wszystkie te biblioteki można pisać w języku Python, jednak nie byłyby tak szybkie, jak są. BrenBarn mówi, że teraz mamy szansę uczynić Pythona wystarczająco szybkim, aby te biblioteki mogły być napisane w pythonie, ale odmawiamy skorzystania z tej szansy, ponieważ przyjęcie go oznacza utratę możliwości korzystania z bibliotek C. Uważam, że to właśnie miał na myśli przez szkodę, nie dlatego, że istnienie bibliotek C jest złą rzeczą, ale że jedynym sposobem na tworzenie szybkich bibliotek jest użycie C.
vikki
14

Zrobiłem mały test porównawczy na ten temat. Podczas gdy wiele innych plakatów mówiło dobrze o kompatybilności, z mojego doświadczenia wynika, że ​​PyPy nie jest o wiele szybszy do poruszania się po bitach. W przypadku wielu zastosowań Pythona istnieje tylko translacja bitów między dwiema lub więcej usługami. Na przykład niewiele aplikacji internetowych wykonuje intensywną analizę procesora zbiorów danych. Zamiast tego pobierają bajty od klienta, przechowują je w jakiejś bazie danych, a następnie zwracają je innym klientom. Czasami format danych ulega zmianie.

Deweloperzy BDFL i CPython są niezwykle inteligentną grupą ludzi i udało im się pomóc CPython osiągnąć doskonałe wyniki w takim scenariuszu. Oto bezwstydna wtyczka do blogu: http://www.hydrogen18.com/blog/unpickling-buffers.html . Używam Stackless, który pochodzi z CPython i zachowuje pełny interfejs modułu C. W tym przypadku nie znalazłem żadnej korzyści z używania PyPy.

Eric Urban
źródło
1
PyPy ma wiele starannie przeprowadzonych testów porównawczych (niestety w przeciwieństwie do CPython, który tak naprawdę nie ma obecnie pakietu testów porównawczych dla użytkownika). Oczywiście dla ruchu sieciowego PyPy nie może magicznie przyspieszyć niczego.
Julian
1
Julian, warto zauważyć, że ludzie PyPy od lat koncentrują się na poprawie czasu wykonywania tego konkretnego pakietu testów. W pewnym stopniu wydaje się, że „zbytnio” dopasowują swoje optymalizacje do tego zestawu testów porównawczych i, z mojego doświadczenia, oprócz obliczeń czysto numerycznych (które i tak są lepsze w Fortran lub C99), nigdy nie dostałem PyPy'ego, aby był bardziej ponad ~ 2x szybciej niż CPython.
Alex Rubinsteyn
9
@AlexRubinsteyn Jednak osoby, które pracują nad PyPy, zawsze wierzyły, że jeśli znajdziesz przypadek, w którym PyPy jest wolniejszy niż CPython, i możesz zmienić go w rozsądny punkt odniesienia, ma duże szanse na dodanie do pakietu.
gsnedders
1
Sprawdziłem twojego bloga. W twoich wynikach para prostych python (pickle, StringIO) pokazuje, że pypy jest ~ 6,8 razy szybszy niż cpython. Myślę, że to przydatny wynik. Podsumowując, wskazujesz (poprawnie), że kod pypy (który jest zwykłym pytonem!) Jest wolniejszy niż kod C (cPickle, cStringIO), a nie kod cpython.
Caleb Hattingh
1
@gsnedders Mam propozycję odniesienia w oparciu o rinohtype na wielu okazjach . Nie dodali jeszcze tego do pakietu.
Brecht Machiels,
12

P: Jeśli PyPy może rozwiązać te wielkie wyzwania (szybkość, zużycie pamięci, równoległość) w porównaniu do CPython, jakie są jego słabości, które uniemożliwiają szersze zastosowanie?

Odp .: Po pierwsze, niewiele jest dowodów na to, że zespół PyPy może ogólnie rozwiązać problem prędkości . Długoterminowe dowody wskazują, że PyPy uruchamia niektóre kody Pythona wolniej niż CPython i ta wada wydaje się być głęboko zakorzeniona w PyPy.

Po drugie, obecna wersja PyPy zużywa znacznie więcej pamięci niż CPython w dość dużym zestawie przypadków. PyPy nie rozwiązał jeszcze problemu zużycia pamięci.

To, czy PyPy rozwiąże wspomniane wielkie wyzwania i będzie generalnie szybsze, mniej wymagające pamięci i bardziej przyjazne dla paralelizmu niż CPython, jest kwestią otwartą, której nie można rozwiązać w krótkim okresie. Niektóre osoby obstawiają, że PyPy nigdy nie będzie w stanie zaoferować ogólnego rozwiązania umożliwiającego zdominowanie CPython 2.7 i 3.3 we wszystkich przypadkach.

Jeśli PyPy odniesie lepszy wynik niż CPython w ogóle, co jest wątpliwe, główną słabością wpływającą na jego szersze zastosowanie będzie jego kompatybilność z CPython. Istnieją również problemy, takie jak fakt, że CPython działa na szerszej gamie procesorów i systemów operacyjnych, ale problemy te są znacznie mniej ważne w porównaniu do wydajności PyPy i celów kompatybilności CPython.


P: Dlaczego nie mogę teraz zastąpić CPython PyPy?

Odp .: PyPy nie jest w 100% kompatybilny z CPython, ponieważ nie symuluje CPython pod maską. Niektóre programy mogą nadal zależeć od unikalnych funkcji CPython, których nie ma w PyPy, takich jak powiązania C, implementacje C obiektu i metod Pythona lub przyrostowy charakter modułu śmieciowego CPython.


źródło
Ta odpowiedź nie przytacza żadnych wzorców ani nie zawiera referencji.
qwr
7

CPython ma liczenie referencji i odśmiecanie, PyPy ma tylko odśmiecanie.

Tak więc obiekty są zwykle usuwane wcześniej i __del__są wywoływane w bardziej przewidywalny sposób w CPython. Niektóre oprogramowanie polega na tym zachowaniu, dlatego nie są gotowe do migracji do PyPy.

Niektóre inne oprogramowanie działa z oboma, ale zużywa mniej pamięci z CPython, ponieważ nieużywane obiekty są wcześniej zwalniane. (Nie mam żadnych pomiarów wskazujących, jak ważne jest to i jakie inne szczegóły implementacji wpływają na użycie pamięci).

pkt
źródło
17
Należy podkreślić, że poleganie na __del__wcześniejszym wezwaniu lub w ogóle jest błędne nawet w CPython. Jak to ująłeś, zwykle działa, a niektórzy uważają to za gwarantowane. Jeśli cokolwiek, co odnosi się do obiektu, zostanie uwięzione w cyklu odniesienia (co jest raczej łatwe - czy wiesz, że sprawdzenie bieżącego wyjątku w pewien nieskomplikowany sposób tworzy cykl odniesienia?) Finalizacja jest opóźniana w nieskończoność, aż do następnego cyklu GC (co może nigdy nie być ). Jeśli sam obiekt jest częścią cyklu odniesienia, __del__nie będzie w ogóle wywoływany (przed Python 3.4).
3
Narzut na obiekt jest wyższy w CPython, co ma duże znaczenie, gdy zaczniesz tworzyć wiele obiektów. Uważam, że PyPy domyślnie odpowiada ekwiwalentowi automatów .
4

W przypadku wielu projektów różnica prędkości między pytonami wynosi 0%. To są te, które są zdominowane przez czas inżynierii i gdzie wszystkie pytony mają taką samą obsługę bibliotek.

Stephan Eggermont
źródło
1
Jeśli twój projekt jest tak prosty, to oczywiście nie ma to znaczenia, ale to samo można powiedzieć o dowolnej implementacji dowolnego języka: jeśli wszystko, co robisz, to agregowanie funkcji innych bibliotek za pomocą stosunkowo wydajnych ABI, to wszystko nie ma znaczenia.
1
Nie ma to nic wspólnego z prostym. W czasie projektowania ważna jest pętla sprzężenia zwrotnego. Czasami znacznie ważniejsze niż czas działania.
Stephan Eggermont
1
Cóż, mówisz bardzo niejasno (czas inżynierii bez odniesienia do tego, co jest projektowane, jakie są ograniczenia, itp .; pętla sprzężenia zwrotnego bez odniesienia do tego, co jest komu przekazywane, itd.), Więc idę wyskoczyć z tej rozmowy, zamiast wymieniać tajemnicze odniesienia.
Nic tu niejasnego. Spójrz na pętlę OODA lub PDCA.
Stephan Eggermont
3
@ użytkownik Cóż, każdy projekt uruchamiany raz, którego napisanie zajmuje miesiąc i minutę, będzie miał ogólne przyspieszenie o 0,0% (1 miesiąc + 1 minuta vs 1 miesiąc) od korzystania z PyPy, nawet jeśli PyPy byłby tysiąc razy szybszy. Stephan nie twierdził, że wszystkie projekty miałyby przyspieszenie 0%.
gmatht
4

Upraszczając: PyPy zapewnia szybkość, której brakuje CPython, ale poświęca jego kompatybilność. Większość ludzi wybiera jednak Pythona ze względu na jego elastyczność i funkcję „baterii” (wysoka kompatybilność), a nie ze względu na szybkość (choć nadal jest preferowana).

Yishen Chen
źródło
16
„w zestawie bateria” oznacza dużą standardową bibliotekę , AFAIK
tshepang
4

Znalazłem przykłady, w których PyPy działa wolniej niż Python. Ale: tylko w systemie Windows.

C:\Users\User>python -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 294 msec per loop

C:\Users\User>pypy -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 1.33 sec per loop

Jeśli więc myślisz o PyPy, zapomnij o systemie Windows. W systemie Linux możesz osiągnąć niesamowite przyspieszenia. Przykład (podaj wszystkie liczby pierwsze od 1 do 1 000 000):

from sympy import sieve
primes = list(sieve.primerange(1, 10**6))

Działa to 10 (!) Razy szybciej na PyPy niż na Pythonie. Ale nie w systemie Windows. Tam jest tylko 3 razy szybszy.

lifolofi
źródło
Ciekawy! Byłoby więcej porównań i liczb.
ben26941,
1

PyPy już od jakiegoś czasu obsługuje Python 3, ale zgodnie z tym postem HackerNoon autorstwa Anthony'ego Shawa z 2 kwietnia 2018 r. PyPy3 jest wciąż kilka razy wolniejszy niż PyPy (Python 2).

W przypadku wielu obliczeń naukowych, zwłaszcza obliczeń macierzowych, lepszym wyborem jest numpy (patrz FAQ: Czy powinienem instalować numpy czy numpypy? ).

Pypy nie obsługuje gmpy2. Zamiast tego możesz skorzystać z gmpy_cffi, chociaż nie przetestowałem jego prędkości, a projekt miał jedną wersję w 2014 roku.

W przypadku problemów z Project Euler często używam PyPy, a do prostych obliczeń numerycznych często from __future__ import divisionwystarcza do moich celów, ale obsługa Python 3 jest wciąż rozwijana od 2018 r., A najlepszym rozwiązaniem jest 64-bitowy Linux. Windows PyPy3.5 v6.0, najnowszy z grudnia 2018 r., Jest w wersji beta.

qwr
źródło
0

Obsługiwane wersje Pythona

Aby zacytować Zen Pythona :

Liczy się czytelność.

Na przykład Python 3.7 wprowadził klasy danych, a Python 3.8 wprowadził fstring = .

W Pythonie 3.7 i Pythonie 3.8 mogą znajdować się inne funkcje, które są dla Ciebie ważniejsze. Chodzi o to, że PyPy nie obsługuje obecnie Python 3.7 lub Python 3.8.

Martin Thoma
źródło