- Bu kez yayımlanan Python 3.14, şimdiye kadarki CPython sürümleri arasında en hızlı performansı gösteriyor
- Tek iş parçacığında 3.14, 3.13'e kıyasla yaklaşık %27 iyileşme gösterdi; JIT'in performans artışı sınırlı, Free-threading yorumlayıcısı ise tek iş parçacığında biraz daha yavaş
- Çok iş parçacıklı kullanımda FT yorumlayıcısı, GIL'in kaldırılmasının etkisiyle Fibonacci'de 3,1 kat, bubble sort'ta 2 kat hızlanma göstererek CPU yoğun çok iş parçacıklı iş yüklerinde etkili oldu
- Sonuç olarak 3.14, CPython içinde en hızlı sürüm; 3.11 ve üzeri öneriliyor, Pypy hâlâ çok hızlı ve JIT'in olgunluk açısından daha fazla gelişmeye ihtiyacı var
Benchmark varsayımları ve sınırlamalar
- Python 3.14'ün resmi yayımlanmasının hemen ardından, farklı Python sürümleri ve diğer dillerle yapılan performans benchmark sonuçları paylaşıldı
- Bu test, yalnızca saf Python kodu ile yazılmış basit özyineleme (Fibonacci) ve yineleme (bubble sort) fonksiyonlarıyla gerçekleştirildi
- Gerçek geliştirme ortamlarında çoğu zaman C/C++/Rust gibi yerel kodlarla birlikte kullanıldığından, bu sonuçlar gerçek dünyadaki durumlarla bire bir örtüşmez
Test matrisi
- Test ortamı
- 6 farklı Python sürümü (3.9~3.14), Pypy, Node.js, Rust dahil
- Python yorumlayıcıları: standart (Standard), JIT, Free-threading (her biri 3.13 ve sonrası)
- Test script'leri: Fibonacci (fibo.py), bubble sort (bubble.py)
- İş parçacığı modları: tek iş parçacığı, 4 iş parçacığı
- Test makineleri: Linux (Framework i5), macOS (M2)
- Node.js ve Rust sürümleri de karşılaştırma için referans olarak dahil edildi
Test script'leri
- Fibonacci (fibo.py): özyinelemeli yapı kullanılarak her ortamda
fibo(40) çalıştırıldı
- Bubble sort (bubble.py): 10.000 rastgele sayı sıralandı
- Her test 3 kez tekrarlanarak ortalama değer hesaplandı
- Test kodu GitHub deposunda açık olarak paylaşılıyor
Benchmark #1: Fibonacci (tek iş parçacığı)
- Python 3.14, 3.13'e göre yaklaşık %27 daha hızlı sonuç verdi (6,59 saniye vs 8,26 saniye)
- 3.11 sürümünden itibaren performans, "çok yavaş" seviyesinden "biraz daha az yavaş" seviyesine geçmiş görünüyor
- Pypy, 3.14'ten yaklaşık 5 kat daha hızlı; Node.js ile benzer seviyede, Rust ise açık ara en hızlı
- Free-threading, tek iş parçacığında standart sürümden hâlâ daha yavaş olsa da 3.14 ile birlikte fark azaldı (%91 seviyesi)
JIT, Free-threading yorumlayıcıları
- JIT, bu özyinelemeli fonksiyon yapısında hissedilir bir performans artışı sağlamadı
- Free-threading, tek iş parçacığında aksine biraz daha yavaş sonuç verdi
- JIT'in performans artışı sınırı, fonksiyon yapısına göre değişebilir
Benchmark #2: Bubble sort (tek iş parçacığı)
- Python 3.14, 3.11'den az farkla daha hızlı, ancak aradaki fark Fibonacci'ye göre daha küçük (3.14: 2,18 saniye, 3.11: 2,48 saniye)
- Pypy, 3.14'ten yaklaşık 18 kat daha hızlı
- JIT, Linux ortamında az da olsa daha hızlı olabilirken macOS'ta neredeyse fark yaratmadı
Benchmark #3: Fibonacci (çok iş parçacığı)
- Standart yorumlayıcıda GIL (Global Interpreter Lock) nedeniyle iş parçacığı sayısı artırılsa da beklenen hızlanma görülmüyor
- Free-threading yorumlayıcısı (3.14), standarda kıyasla 3,1 kat daha hızlı
- JIT'in etkisi neredeyse hiç doğrulanmadı
- Yalnızca Pypy sonucu ölçüldü; Node.js/Rust bu testte karşılaştırılmadı
Benchmark #4: Bubble sort (çok iş parçacığı)
- Free-threading (3.14 FT), standarda (3.14) göre 2 kat daha hızlı sonuç verdi; özellikle CPU yoğun işlerde avantajı belirgin
- JIT'in net bir performans üstünlüğü yok
- Mac'teki Free-threading performansı dikkat çekiyor
Sonuç
- CPython 3.14, mevcut CPython sürümleri arasında en hızlı performansı gösteriyor
- Yükseltme zorsa 3.11 veya üzeri sürümlerin kullanılması öneriliyor
- JIT yorumlayıcısı, pratikte hissedilen hız artışı açısından sınırlı kaldı
- Free-threading yorumlayıcısı, çok iş parçacıklı CPU yoğun senaryolarda belirgin avantaj sağlıyor
- Pypy son derece hızlı ve daha fazla incelenmeye değer
Diğer
- Sonuçlar çeşitli ortam değişkenlerine göre değişebileceğinden, doğrudan benchmark yapıp doğrulamanız önerilir
- Ayrıntılar ve kod için GitHub deposuna bakılabilir
1 yorum
Hacker News görüşleri
Hayatımı değiştiren birinden bahsetmek istiyorum. İlk web sitemi Flask mega tutorial ile yaptım; yayına almadan hemen önce Flask'ta bozuk dosyaları işleme gibi kritik bir noktada takıldım, soru sordum ve Stack Overflow yanıtıyla çözerek anında siteye uyguladım. Sonrasında site inanılmaz yayıldı. Referans olsun diye yanıt bağlantısını bırakıyorum stackoverflow link
Flask ile ilgisi yok ama yeni Flask logosunu gerçekten hiç beğenmiyorum. Eski logo vintage ve el yapımı gibi bir his veriyordu, yeni logo ise sanki bir lise öğrencisinin WordArt ile şaka olsun diye yaptığı bir şey gibi. Eski logo, Yeni logo
Yaptığın sitenin yout.com olup olmadığını sormak istiyorum. Hâlâ Flask kullanıyor musun merak ettim
Bir gün yeniden vibe coding yapıp microphonetest.com sitesini diriltmen harika olurdu
Benchmark yazarken döngü içinde süre ölçüp bunları toplamamanı öneririm. Tüm döngünün çalışma süresini ölçüp tekrar sayısına bölmek daha iyidir. Süre ölçümünün kendi jitter'ı sonucu çarpıtabilir
Python'un 3.14 sürümünde TeX gibi sabitlenmesinden endişe ediyorum Reddit bağlantısı
"Durmamasını" uman görüşü görünce, Donald Knuth'un değişimden ziyade sürekli aynı sonucu üreten bir sistemi daha çok önemsemesi bana tazeleyici geldi. Her şeyin birkaç yıl içinde eski sayıldığı bir dünyada, sırf OOO çıktı diye mutlaka geçmek zorundaymışız gibi hissetmek bana hastalık gibi geliyor. Gerçekten 100 yıl kullanılacak kod yazamamamız için bir sebep yok. Kod sonuçta matematiktir. Binlerce yıl önce icat edilen polinomları kullanınca kimse sana demode demiyor. Kanıtlanmış olanda kalmaya da değer verilmeli. Her seferinde yeni sürüm, yeni araç peşinde koşmak zorunda değiliz. Değiştirmek için sebep olmayan kod yazan insanların asıl katkıyı yapanlar olduğunu düşünüyorum
πthon ile ilgili şakaya şaşırtıcı derecede iyi uyan bir durum olduğu yorumu
Python haberi çıktığında her seferinde, 2025'te bile PyPy'nin hâlâ ayrı bir kulvarda olmasına üzülüyorum. GIL'siz Python'un bir gün GIL'siz C FFI'ı da mümkün kılıp kılamayacağını merak ediyorum. Bunun Python'a gerçekten çok yardımı olurdu diye düşünüyorum
C FFI zaten uzun zamandır GIL'i elle bırakabiliyordu; o yüzden bununla tam olarak ne kastedildiğini merak ediyorum
C'den çıkıp farklı derleyici implementasyonlarıyla çeşitli lehçeler üretmek sağlıklı bir ekosistem bence. Çünkü deneyi ve gelişimi teşvik ediyor. PyPy ile CPython arasındaki farkın da o kadar büyük olmadığını ve uyumluluğun yüksek olduğunu düşünüyorum pypy uyumluluk notu
freethreading zaten tam da bunun için var. Bildiğim kadarıyla çeşitli C FFI kütüphaneleri henüz GIL olmadan çalışacak şekilde değiştirilmediği için freethreading varsayılan olarak kullanılamıyor
Python'un deneysel bir JIT ekleyerek PyPy'ye bir adım daha yaklaştığını söyleyebiliriz. Yeni JIT'ini kendisi mi geliştirecek yoksa PyPy ile mi birleşecek bilmiyorum ama PyPy'den çok şey öğrendiğine inanıyorum
Bunun gibi bir şeyin, yani ayrı implementasyon ekosistemlerini birleştirmenin, değişebileceğini düşünüp düşünmediğini merak ediyorum. Python'un tesadüfen performansa zarar veren başka bir breaking change getirmesi, geniş bir kullanıcı kitlesi için zararlı olurdu. Python organizasyonu gerçekten bunu ister mi emin değilim
PyPy'nin çok iş parçacıklı kodda bile free threaded CPython'dan daha hızlı olması ilginç
non-GIL geçişinin çok sorunsuz ilerlemesi dikkat çekici. 2→3 geçişiyle kıyaslayınca bu gerçekten etkileyici. Standart hızlara kısa sürede ulaşması da umut verici; uyumsuzlukların da yakında ortadan kalkmasını umuyorum
Hızlıca kendin benchmark denemek istersen fast_langton_ant reposunu öneririm.
python3 server.py -s 10000000 -ngibi çalıştırabilirsinKatlanan yorum özelliğinin karma ya da başka seçeneklere göre mi çalıştığını merak ediyorum. Miguel'in yardım ettiği anının en popüler gönderi olması dikkatimi çekti ama sadece konuyla ilgili yorumları görmek istediğimde katlama özelliğinin olmadığını ilk kez fark ettim
Yalnızca basit döngüler ve tamsayı işlemleri kullanan benchmark'larla Python'un gerçek hayattaki kullanımını değerlendirmek zor bence. Hash map ya da string işleme gerçek koda daha yakın. Birçok Python kullanıcısı sayısal hesaplamayı dış kütüphanelere bırakıyor
Tüm benchmark'lar sonuçta belirli bir ölçütü test etmek üzere tasarlanır. Yazar da yazıda hedefini açıkladığı için merak ediyorsan ona bakmanı öneririm
Daha kapsamlı analiz eden bir yazı olmasını isterdim ama benim gerçek kullanımım için bu tür benchmark'lar daha uygun. Ben çoğunlukla çeşitli problemlere yönelik Monte Carlo simülasyonları ya da basit bilimsel hesaplamaları tekrar tekrar yazıyorum. Tek seferlik simülasyonlar için hızlı algoritmalar ya da alışık olmadığım kütüphaneleri kullanmıyorum. Bazen 10 dakika sürmesi de sorun değil (ör. scipy, numpy'yi çoğunlukla yine kullanıyorum). Varsayımları sık sık değiştirerek tekrar denediğim için olabildiğince basit kalmayı tercih ediyorum. Okunabilirlik ve doğaçlama kod önemli, iyi optimize edilmemiş olması da sorun değil (ör. Fibonacci, bubble sort, iç içe for döngüleri gibi). Gerçek performans gerektiğinde ise içeriği doğrudan cpp/zmp/pybind/numba ile kendim yazıyorum
FastAPI endpoint çağrıları veya numpy hesaplamaları gibi daha yaygın örnekleri benchmark'a eklemek, Python'un gerçek kullanımına daha yakın olurdu. Bunlar saf Python kodu olmayabilir ama pratikte birçok kişi Python'u böyle kullanıyor
Sadece tight loop ve int işlemleriyle benchmark yapmanın ne kadar gerçekçi olduğunu sorguluyorum
Yeni deneysel tail call interpreter'ın (seçenek
--with-tail-call-interp) benchmark'a dahil edilip edilmediğini merak ediyorum tail-call-interp resmi dokümanı. Test sonuçlarında bahsedilmediği için muhtemelen dahil edilmediğini tahmin ediyorum. tail call interpreter'ın diğer mevcut implementasyonlardan ne kadar farklı olduğunu kıyaslamayı isterdim--with-tail-call-interp). Optimizasyonun özyinelemeli tail call'lara da uygulanıp uygulanmadığından emin değilim ama uygulanıyorsa Fibonacci testinde bir performans artışı görülmesi gerekirdi