PyPy 6.3 kat daha hızlıysa neden CPython üzerinden PyPy kullanmamalıyım?


685

PyPy projesi hakkında çok şey duydum . Onlar 6,3 kat daha hızlı daha olduğunu iddia CPython üzerinde tercüman kendi sitesinde .

Python gibi dinamik diller hakkında konuştuğumuzda, hız en önemli sorunlardan biridir. Bunu çözmek için PyPy'nin 6,3 kat daha hızlı olduğunu söylüyorlar.

İkinci konu, meşhur Küresel Tercüman Kilidi (GIL) olan paralelliktir . Bunun için PyPy, GIL'siz Python verebileceğini söylüyor .

PyPy bu büyük zorlukları çözebilirse, daha geniş bir şekilde benimsenmesini engelleyen zayıf yönleri nelerdir? Yani, benim gibi tipik bir Python geliştiricisi olan birinin şu anda PyPy'ye geçmesini engelleyen nedir?


30
Yorumlar tasfiye edildi, çünkü çoğu cevaplarda (ve bazı durumlarda) ya da hiç söylenmemesi gereken şeylerdi. Ayrıca, bu sorunun öznelliği ile ilgili dile getirilen bazı endişeleri gidermek için düzenlenmiştir. Lütfen gerçekleri kullanarak yanıtlamaya çalışın ve mümkünse kaynaklarla ilgili iddiaları yedekleyin!
Şok9

3
Pypy'yi çok kullanıyorum. Çok iyi çalışır. Bununla birlikte, Pypy birçok CPU ağır iş yükü için biraz daha hızlı olsa da, aslında attığım I / O ağır iş yükleri için daha yavaştır. Örneğin, backshift adı verilen tekilleştirici bir yedekleme programı yazdım. Çok sayıda dosya parçalaması yapan ilk yedekleme için pypy harika. Ancak çoğunlukla zaman damgalarını güncelleyen sonraki yedeklemeler için CPython daha hızlıdır.
dstromberg

Yanıtlar:


657

NOT: PyPy, bu sorunun sorulduğu 2013'te olduğundan daha olgun ve daha iyi desteklenmektedir. Güncel olmayan bilgilerden sonuç çıkarmaktan kaçının.


  1. PyPy, diğerlerinin de belirttiği gibi, C uzantıları için sürekli desteğe sahiptir . Bu sahiptir fakat genellikle daha yavaş Python hızlarında, destek ve bunun en iyi şekilde şüpheli var. Bu nedenle birçok modül sadece CPython gerektirir . PyPy numpy'yi desteklemiyor PyPy şimdi numpy'yi destekliyor . Bazı uzantılar hala desteklenmemektedir (Pandalar, SciPy vb.), Değişikliği yapmadan önce desteklenen paketler listesine göz atın .
  2. Python 3 desteği şu anda deneyseldir. şimdi kararlı oldu! 20 Haziran 2014 tarihi itibariyle PyPy3 2.3.1 - Fulcrum çıktı !
  3. PyPy bazen pek çok insanın Python'u kullandığı "scriptler" için daha hızlı değildir . Bunlar basit ve küçük şeyler yapan kısa süreli programlardır. PyPy bir JIT derleyicisi olduğundan, ana avantajları uzun çalışma sürelerinden ve basit türlerden (sayılar gibi) gelir. Açıkçası, PyPy'nin JIT öncesi hızları CPython'a kıyasla oldukça kötü .
  4. Atalet . PyPy'ye geçmek genellikle bazı insanlar ve kuruluşlar için çok fazla çalışma olan yeniden yapılandırma gerektirir.

Bunlar beni etkileyen ana nedenler.


14
İyileştirmekten bahsettiğiniz güzel. Örneğin, web sunucumun Python 2.4 ve 2.5 arasında bir seçeneği var; ve yakınımdaki "büyük bir eğlence yazılımı üreticisi" 2.6'yı yakında yükseltme planını kullanmıyor. Bazen bir dönüşümün maliyetini bile keşfetmek büyük ve maliyetli bir çaba olabilir.
Mike Housky

19
PyPy'nin "C kadar hızlı" olması, sayısal C için, sayısal olarak kullanılan yüksek düzeyde optimize edilmiş, çok iş parçacıklı önbellek kullanan C kitaplıklarından daha fazladır. Sayısal olarak, Python sadece işaretçiler etrafında büyük dizilere feribot için kullanılır. Yani PyPy "C kadar hızlı" olmak "işaretçilerinizin + meta verilerinizin C kadar hızlı hareket ettirilmesi" anlamına gelir. Önemli bir şey değil. O zaman neden Python ile uğraşasınız ki? Gitmek cblas ve lapacke fonksiyon imzaları.
cjordan1

12
@ cjordan1: Ne dediğini anlamıyorum. Yüksek seviye numpy yapılar np.sum(M[1:2*n**2:2, :2*n**2] * M[:2*n**2:2, :2*n**2].conjugate(), axis=1)Python'da son derece etkileyici ( ?) Ve bu da Python'u bilim topluluğu için çok uygun hale getiriyor. Ek olarak, Python'daki yoğun olmayan kısımları yapmak ve daha küçük yoğun döngüler için C'ye bombardımanı yapmak yaygın ve kullanışlı bir stratejidir.
Veedrac

26
@Veedrac Demek istediğim buydu. "Git cblas ve lapacke'deki fonksiyon imzalarına bakın" gibi, çünkü o kadar uzun ve kullanımı zordur ki, işaretçiler ve meta veriler etrafında feribot için neden Python kullandığımızı anlayacaksınız.
cjordan1

5
@ tommy.carstensen Burası gerçekten derinlemesine gitmek için iyi bir yer değil, ama deneyeceğim. 1. Bu yazdığım zaman, şimdi olduğundan çok daha doğruydu. 2. "Komut dosyaları" çoğunlukla IO-ağırdır. PyPy'nin IO'su genellikle CPython'lardan daha yavaştır - eskiden önemli ölçüde yavaştı. 3. PyPy eskiden CPython'dan daha yavaştı, şimdi ipleri işlerken - şimdi genellikle daha iyi ve nadiren daha kötü. 4. Birçok "betik" sadece tutkal kodudur - tercümanı daha hızlı hale getirmek bu durumda genel çalışma sürelerini iyileştirmez. 5. PyPy'nin ısınma süreleri daha büyüktü - kısa çalışan komut dosyaları nadiren çok sayıda sıcak kod üretmeyi başardı.
Veedrac

104

Olmadığını sitesi değil PYPY iddia 6,3 kat daha hızlı CPython fazla. Alıntılamak:

Tüm kriterlerin geometrik ortalaması CPython'dan 0.16 veya 6.3 kat daha hızlı

Bu, yaptığınız battaniye ifadesinden çok farklı bir ifadedir ve farkı anladığınızda, yalnızca "PyPy kullan" diyememenizin en az bir nedenini anlayacaksınız. Nit-pick'im gibi gelebilir, ancak bu iki ifadenin neden tamamen farklı olduğunu anlamak çok önemlidir.

Bunu yıkmak için:

  • Yaptıkları ifade sadece kullandıkları karşılaştırmalar için geçerlidir. Programınız hakkında kesinlikle hiçbir şey söylemez (programınız kriterlerinden biri ile tam olarak aynı değilse).

  • Açıklama, bir grup karşılaştırmanın ortalamasıyla ilgilidir. PyPy'yi çalıştırmanın test ettikleri programlar için bile 6,3 kat iyileşme sağlayacağı iddiası yoktur.

  • PyPy bile CPython çalıştığı tüm programları çalıştırmak dair hiçbir iddia yoktur hiç yalnız daha hızlı izin.


15
Elbette PyPy'nin tüm Python kodlarını daha hızlı çalıştıracağı iddiası yoktur. Ancak tüm saf Python uygulamasını alırsanız, bunların önemli bir çoğunluğunun PyPy'de ve sonra CPython'da çok daha hızlı (> 3x kez) çalışacağına bahse girebilirim.
Robert Zaremba

18
İlk iki mermi noktanızın hiçbiri mantıklı değil. Kriterlerin "programınız hakkında kesinlikle hiçbir şey" olmadığını söyleyebilirsiniz. Kriterlerin tüm gerçek uygulamaların mükemmel bir göstergesi olmadığı oldukça açıktır, ancak bir gösterge olarak kesinlikle yararlı olabilirler. Ayrıca, bir grup karşılaştırmanın ortalamasını bildiren onlar hakkında ne yanıltıcı bulduğunuzu anlamıyorum. Oldukça açık bir şekilde ifade ediyorlar. Bir programcı ortalamanın ne olduğunu anlamıyorsa, dil performansından çok daha ciddi endişeleri vardır.
Sean Geoffrey Pietz

6
@SeanGeoffreyPietz - PyPy'nin sitesinin herhangi bir şekilde yanıltıcı olduğunu iddia etmiyordum - sonuçlarını doğru bir şekilde sundular. Ama asıl soru onları yanlış yorumladı ve yazarın 'ortalama' kelimesinin önemini anlamadığını gösteriyordu. Bireysel kriterlerin çoğu 6,3 kat daha hızlı değildir. Farklı bir ortalama türü kullanırsanız, farklı bir değer elde edersiniz, bu nedenle "6,3 x daha hızlı", "geometrik ortalama 6,3 x daha hızlıdır" için yeterli bir özet değildir. "A Grubu, B grubundan Z kat daha hızlıdır" anlamlı olamayacak kadar belirsizdir.
spookylukey

6
-1: @spookylukey Kıyaslama süitinin iddiayı destekleyecek kanıtlar sağlamadan taraflı olduğunu öne sürüyorsunuz. Eleştiri her zaman kanıtlarla desteklenmelidir!
Evgeni Sergeev

5
@EvgeniSergeev - hayır, tüm ölçütlerin taraflı olduğunu ima ediyorum! Tabii ki kasıtlı olarak değil. Olası faydalı programların alanı sonsuz ve inanılmaz derecede çeşitlidir ve bir dizi kıyaslama, bu kıyaslamalardaki performansı her zaman ölçer. "PyPy, CPython'dan ne kadar hızlı?" "Fred, Joe'dan ne kadar hızlıysa?"
spookylukey

74

Pypy% 100 uyumlu olmadığından, derlemek için 8 gig ram alır, hareketli bir hedeftir ve cpython'un kararlı olduğu oldukça deneyseldir, 2 yıl boyunca modül üreticileri için varsayılan hedef (pypy üzerinde çalışmayan c uzantıları dahil) ) ve zaten yaygın olarak dağıtıldı.

Pypy muhtemelen referans uygulaması olmayacak, ancak sahip olmak iyi bir araçtır.


2
Pypy.org/download.html'e göre , PyPy'nin 8 değil, 64 bitlik bir sistemde derlemesi için 4 GB RAM'e ihtiyacı var. Ve bu sayfada gerekirse 3 GB'ın altında bir seçenek var.
knite

4
@ knite 1: 2015 itibariyle yeni olan bu dokümantasyon tarihsel olarak 8 GB'ı okudu. 2: 2015'te pratikte hala en az 8'e ihtiyacınız var, 6-7 ücretsiz.
Tritium21

4
Bir derleme veya dağıtım kullanıyorsanız, derlemek için bellek gereksinimi o kadar alakalı değildir . "Hedefi hareket ettirmek ve son derece deneysel" olarak, kırılan şeylere birkaç örnek verebilir misiniz? Yine, insanlar gece yapıları veya kaynak yerine sürüm yapıları kullanıyorsa, makul bir işlevsellik beklentisi yok mu?
smci

@ smci Bu, eski verilere dayanan ve eski cevapları olan eski bir sorudur. Bu soruyu ve her cevabı 4 yıl önce pypy durumu için tarihsel olarak düşünün.
Tritium21

1
@ Tritium21: Sadece mevcut cevapla ilgileniyorum. Bu ne? Düzenlemeyle söylemek Cevabınız isteyeceğini "idi ... Python sürümü 2.x vs PYPY karşılaştıran 2013 itibarıyla" (Söz konusu "6.3x-geometrik ortalama" iddiası dışarı güncel olduğu Ayrıca eğer olarak 7.5x iddia ediyorlar, ancak o zamanlar bile kıyaslamalara bağlı ... ), o zaman bu da düzenleme gerektiriyor (sürüm numaraları, en son veriler, vb.) Bence karşılaştırma paketi çok alakalı değil, neredeyse hiç kimse çalışamaz bu günlerde bir CPU üzerinde bir betik dilinde raytracing. Ben pybenchmarks.org
smci

37

İkinci soru cevap daha kolaydır: temelde olabilir tüm kod saf Python ise bir damla-in yedek olarak PYPY kullanın. Bununla birlikte, yaygın olarak kullanılan birçok kitaplık (standart kitaplığın bazıları dahil) C dilinde yazılır ve Python uzantıları olarak derlenir. Bunlardan bazıları PyPy ile çalışmak için yapılabilir, bazıları olamaz. PyPy, Python ile aynı "öne dönük" aracı sağlar - yani, Python --- ama onun doğası farklıdır, bu yüzden bu doğuşlarla arayüz oluşturan araçlar çalışmaz.

İlk soruya gelince, birincisi ile bir çeşit Catch-22 olduğunu hayal ediyorum: PyPy, hızı geliştirmek ve diğer kodlarla birlikte çalışabilirliği artırmak için hızla gelişiyor. Bu, resmi olandan daha deneysel hale getirdi.

Bence PyPy istikrarlı bir duruma girerse, daha yaygın olarak kullanılmaya başlayabilir. Ayrıca Python'un C temellerinden uzaklaşmasının harika olacağını düşünüyorum. Ama bir süre olmayacak. PyPy, istediğiniz her şeyi yapmanın neredeyse yeterli olduğu kritik kitleye henüz ulaşmadı , bu da insanları boşlukları doldurmaya motive edecek.


17
C'nin yakın zamanda herhangi bir yere gidecek bir dil olduğunu sanmıyorum (söylemek isterim, yaşamımızda kaybolmayacak). herhangi bir yerde çalışacak başka bir dil olana kadar C'ye sahip olacağız. puanları.
Tritium21

7
@ Tritium21: Evet, orada sadece editörlük yapıyorum. Mevcut C ile iyiyim, ama bence Python'un C'ye olan bağımlılığı son derece zararlı ve PyPy bunun harika bir örneği: şimdi daha hızlı Python alma şansımız var, ancak C'ye güvenmekle yıllar geçtik Python'un kendi ayakları üzerinde durması çok daha iyi olur. Python'un kendisi C ile yazılmışsa bile sorun değil, ama sorun insanları Python'u C'ye bağlı şekilde genişletmeye teşvik eden bir uzatma mekanizmasının varlığıdır.
BrenBarn

4
çift ​​kenarlı kılıç - python'u bu kadar popüler yapan şeyin bir kısmı, diğer uygulamaları genişletme ve diğer uygulamalar tarafından genişletme yeteneğidir. Eğer onu alırsan, python hakkında konuşacağımızı sanmıyorum.
Tritium21

10
@BrenBarn Python'un C'ye bağımlılığının zararlı olduğunu iddia etmek aptalca. Python'un C-API'sı olmadan, Python'un sayısal / bilimsel ekosistem ve GUI arayüzlerinin tamamı da dahil olmak üzere biçimlendirici gençlik yıllarında (90'ların sonunda) kazandığı gerçekten güçlü kütüphanelerin ve büyük birlikte çalışmanın çoğu mümkün olmazdı. Bu tür battaniye ifadeleri yapmadan önce Python'un tüm kullanım evrenine bir bakış açısı elde etmek için etrafa bakın.
Peter Wang

4
@PeterWang Tüm bu kütüphaneler Python'da yazılabilir, ancak oldukları kadar hızlı olmazlar. BrenBarn'ın söylediği şey, şimdi bu pıhtıları python ile yazılabilmesi için python'u yeterince hızlı yapma şansımız var, ancak bu şansı almayı reddediyoruz, çünkü onu almak C kütüphanelerini kullanma yeteneğini kaybetmek anlamına geliyor. Zararlı olarak kastettiğine inanıyorum, C kütüphanelerinin varlığının kötü bir şey değil, hızlı kütüphaneler yapmanın tek yolu C kullanmaktır.
Vikki

14

Bu konuda küçük bir kıyaslama yaptım. Diğer posterlerin çoğu uyumluluk hakkında iyi puanlar vermiş olsa da, tecrübem, PyPy'nin sadece bitler etrafında hareket etmek için çok daha hızlı olmadığıydı. Python'un birçok kullanımı için, gerçekten sadece iki veya daha fazla hizmet arasındaki bitleri çevirmek için var. Örneğin, pek çok web uygulaması veri kümelerinin yoğun CPU analizini gerçekleştirmemektedir. Bunun yerine, bir istemciden bazı baytlar alır, bir tür veritabanında saklar ve daha sonra diğer istemcilere döndürürler. Bazen verilerin formatı değişebilir.

BDFL ve CPython geliştiricileri dikkat çekici derecede zeki bir gruptur ve CPython'un böyle bir senaryoda mükemmel performans göstermesine yardımcı olmayı başardılar. İşte utanmaz bir blog eklentisi: http://www.hydrogen18.com/blog/unpickling-buffers.html . CPython türetilmiş ve tam C modülü arabirimini koruyan Stackless kullanıyorum. Bu durumda PyPy'yi kullanmanın herhangi bir avantajı yoktu.


1
PyPy birçok dikkatle çalıştırmak vardır kriterler (şu anda gerçekten Kullanıcıya dönük benchmark paketi sahip olmadığı, maalesef CPython aksine). Tabii ki ağ trafiği için PyPy sihirli bir şekilde daha hızlı bir şey yapamaz.
Julian

1
Julian, PyPy milletinin yıllardır söz konusu kıyaslama paketinin çalışma zamanlarını iyileştirmek için çok çaba harcadığını belirtmek gerekir. Bir dereceye kadar, optimizasyonlarını bu kıyaslama kümelerine "abartıyorlar" ve deneyimlerime göre, tamamen sayısal hesaplamaların yanı sıra (Fortran veya C99'da daha iyi olan), PyPy'yi daha fazla elde etmedim CPython'dan ~ 2 kat daha hızlı.
Alex Rubinsteyn

9
@AlexRubinsteyn Ancak PyPy üzerinde çalışanların görüşü her zaman genel olarak PyPy'nin CPython'dan daha yavaş olduğu bir durum bulursanız ve makul bir ölçüt haline getirebiliyorsanız, pakete eklenmesi için iyi bir şansı vardır.
gsnedders

1
Blogunu kontrol ettim. Sonuçlarınızda, sade-python çifti (turşu, StringIO), pypy'nin cpython'dan ~ 6.8x daha hızlı olduğunu gösterir. Bunun yararlı bir sonuç olduğunu düşünüyorum. Sonuç olarak, pypy kodunun (düz python!) C kodundan (cPickle, cStringIO) değil, cpython kodundan daha yavaş olduğuna (doğru) işaret edersiniz.
Caleb Hattingh

1
@gsnedders ben dayalı bir kriter teklif var rinohtype üzerinde birden vesilelerle . Henüz süite eklemediler.
Brecht Machiels

12

S: PyPy, CPython'a kıyasla bu büyük zorlukları (hız, bellek tüketimi, paralellik) çözebilirse, daha geniş bir şekilde benimsenmesini engelleyen zayıflıkları nelerdir?

C: İlk olarak, PyPy ekibinin hız sorununu genel olarak çözebileceğine dair çok az kanıt var . Uzun vadeli kanıtlar, PyPy'nin belirli Python kodlarını CPython'dan daha yavaş çalıştırdığını ve bu dezavantajın PyPy'de çok derinden kaynaklandığını gösteriyor.

İkincisi, PyPy'nin mevcut sürümü, oldukça büyük bir durumda CPython'dan çok daha fazla bellek tüketir. Bu yüzden PyPy henüz bellek tüketimi sorununu çözmedi.

PyPy'nin söz konusu büyük zorlukları çözüp çözmediği ve genel olarak CPython'dan daha hızlı, daha az belleğe aç ve paralelliğe daha kolay olup olmayacağı kısa vadede çözülemeyen açık bir sorudur. Bazı insanlar PyPy'nin hiçbir zaman CPython 2.7 ve 3.3'e hakim olmasını sağlayan genel bir çözüm sunamayacağına bahse girer .

PyPy genel olarak CPython'dan daha iyi olmayı başarırsa, bu da sorgulanabilir, daha geniş bir şekilde benimsenmesini etkileyen ana zayıflık CPython ile uyumluluğu olacaktır. CPython'un daha geniş bir CPU ve işletim sistemi aralığında çalıştığı gibi sorunlar da vardır, ancak bu sorunlar PyPy'nin performansı ve CPython uyumluluk hedeflerine kıyasla çok daha az önemlidir.


S: Neden CPython'u PyPy ile değiştiremiyorum?

C: PyPy, CPython ile% 100 uyumlu değildir, çünkü başlık altında CPython'u simüle etmez. Bazı programlar yine de C bağlamaları, Python nesnesi ve yöntemlerinin C uygulamaları veya CPython'un çöp toplayıcısının artımlı doğası gibi Pyyt'ta bulunmayan CPython'un benzersiz özelliklerine bağlı olabilir.


Bu cevap hiçbir referans vermez veya referans vermez.
qwr

7

CPython referans sayımı ve çöp toplama, PyPy sadece çöp toplama vardır.

Bu nedenle nesneler daha önce silinme eğilimindedir ve __del__CPython'da daha öngörülebilir bir şekilde çağrılır. Bazı yazılımlar bu davranışa dayanır, bu nedenle PyPy'ye geçiş için hazır değildir.

Diğer bazı yazılımlar her ikisiyle de çalışır, ancak CPython ile daha az bellek kullanır, çünkü kullanılmayan nesneler daha önce serbest bırakılmıştır. (Bunun ne kadar önemli olduğunu ve diğer uygulama ayrıntılarının bellek kullanımını etkilediğini gösteren herhangi bir ölçümüm yok.)


17
__del__CPython'da bile erken veya hiç çağrılmaya güvenmenin yanlış olduğu vurgulanmalıdır . Koyduğunuzda, genellikle işe yarar ve bazı insanlar bunu garanti ettiği anlamına gelir. Nesneye başvuran herhangi bir şey bir referans döngüsüne takılırsa (ki bu oldukça kolaydır - mevcut istisnayı belirli bir çelişkisiz yolla incelemenin bir referans döngüsü oluşturduğunu biliyor muydunuz) sonlandırma bir sonraki döngü GC'ye kadar süresiz olarak ertelenir ( asla olmayabilir ). Nesnesi, bir referans döngüsünün parçası ise, __del__çağrılmayacaktır hiç (Python 3.4 öncesinde).

3
CPython'da, nesne başına ek yük, çok sayıda nesne oluşturmaya başladığınızda LOT için önemlidir. PyPy, varsayılan olarak, bir şey için yuvaların eşdeğerini yapıyor .

4

Birçok proje için, farklı pitonlar arasında hız bakımından% 0 fark var. Mühendislik zamanının hakim olduğu ve tüm pitonların aynı miktarda kütüphane desteğine sahip olduğu budur.


1
Projeniz bu kadar basitse, o zaman önemli değil, ancak aynı şey herhangi bir dilin herhangi bir uygulaması için de söylenebilir: Yaptığınız tek şey, diğer kütüphanelerin işlevlerini nispeten performans gösteren ABI'ler aracılığıyla toplamaksa, o zaman hepsi ilgisizdir.

1
Basit ile ilgisi yoktur. Mühendislik zamanında geri besleme döngüsü önemlidir. Bazen çalışma süresinden çok daha önemlidir.
Stephan Eggermont

1
Çok belirsiz bir şekilde konuşuyorsunuz (mühendislik zamanı, kısıtlılıkların ne olduğu, vb. Referans vermeden mühendislik zamanı; kime geri beslenene referans verilmeyen geri bildirim döngüsü vb.), Bu yüzden gidiyorum ticari şifreli referanslardan ziyade bu görüşmeden vazgeçmek.

Burada belirsiz bir şey yok. OODA döngüsüne veya PDCA'ya bir göz atın.
Stephan Eggermont

3
@user Peki, bir ay sürecek bir çalışma ve bir dakika sürecek olan herhangi bir proje, PyPy bin kat daha hızlı olsa bile, PyPy'yi kullanmada genel olarak% 0,0 oranında (1 ay + 1 dakikaya karşı 1 ay) hız kazanacaktır. Stephan tüm projelerin% 0 hızlanacağını iddia etmiyordu.
gmatht

4

Bunu basitleştirmek için: PyPy, CPython tarafından bulunmayan hızı sağlar, ancak uyumluluğundan ödün verir. Bununla birlikte, çoğu insan, hızı için değil, esnekliği ve "pil dahil" özelliği (yüksek uyumluluk) için Python'u seçer (yine de tercih edilir).


16
"pil dahil" büyük standart kütüphane anlamına gelir , AFAIK
tshepang

4

PyPy'nin Python'dan daha yavaş olduğu örnekler buldum. Ancak: Yalnızca Windows'ta.

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

Yani, PyPy düşünüyorsanız, Windows'u unutun. Linux'ta müthiş ivmeler elde edebilirsiniz. Örnek (1 ile 1.000.000 arasındaki tüm primerleri listeleyin):

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

Bu PyPy'de Python'dan 10 (!) Kat daha hızlı çalışır. Ama pencerelerde değil. Orada sadece 3 kat daha hızlı.


İlginç! Bazı karşılaştırmalar ve sayılar çok iyi olurdu.
ben26941

1

PyPy bir süredir Python 3 desteğine sahipti, ancak 2 Nisan 2018'de Anthony Shaw'un HackerNoon gönderisine göre PyPy3 hala PyPy'den (Python 2) birkaç kat daha yavaş.

Birçok bilimsel hesaplama, özellikle matris hesaplamaları için numpy daha iyi bir seçimdir ( SSS: Numpy veya numpypy kurmalı mıyım? ).

Pypy gmpy2'yi desteklemez. Hızını test etmedim ve projenin 2014 yılında bir sürümü vardı, ancak gmpy_cffi'yi kullanabilirsiniz .

Project Euler sorunları için, PyPy'yi sık sık kullanıyorum ve basit sayısal hesaplamalar için çoğu zaman from __future__ import divisionamacım için yeterli, ancak Python 3 desteği 2018 itibariyle hala çalışıyor ve en iyi bahsiniz 64 bit Linux'ta. Aralık 2018 itibariyle en son Windows PyPy3.5 v6.0 beta sürümündedir.


0

Desteklenen Python Sürümleri

Python Zen'den alıntı yapmak için :

Okunabilirlik önemlidir.

Örneğin, Python 3.7 veri dosyalarını ve Python 3.8 fstring = 'i tanıttı .

Python 3.7 ve Python 3.8'de sizin için daha önemli olan başka özellikler olabilir. Mesele şu ki PyPy şu anda Python 3.7 veya Python 3.8'i desteklemiyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.