Python 3.14 telah dirilis. Seberapa cepat peningkatannya?

• Python 3.14 yang dirilis kali ini menunjukkan performa tercepat di antara semua versi CPython sejauh ini
• Dalam single-thread, 3.14 menunjukkan peningkatan sekitar 27% dibanding 3.13, peningkatan performa JIT minim, dan interpreter free-threading sedikit lebih lambat pada single-thread
• Dalam multi-thread, interpreter FT menunjukkan efek penghapusan GIL dengan percepatan 3,1x untuk Fibonacci dan 2x untuk bubble sort, sehingga efektif untuk multi-thread yang intensif CPU
• Kesimpulannya, 3.14 adalah CPython tercepat, disarankan memakai 3.11 atau lebih baru, PyPy masih sangat cepat, dan JIT masih perlu peningkatan kematangan

---

Premis dan keterbatasan benchmark

• Tepat setelah rilis resmi Python 3.14, dibagikan hasil benchmark performa yang membandingkan beberapa versi Python dan bahasa lain
• Pengujian ini dilakukan menggunakan fungsi rekursif sederhana (Fibonacci) dan fungsi iteratif (bubble sort) yang ditulis hanya dengan kode Python murni
• Di lingkungan pengembangan nyata, Python sering dipakai bersama kode native seperti C/C++/Rust, jadi hasil ini tidak bisa dipetakan 1:1 ke situasi dunia nyata

Matriks pengujian

• Lingkungan pengujian
  • Mencakup 6 versi Python (3.9~3.14), PyPy, Node.js, dan Rust
  • Interpreter Python: standar (Standard), JIT, free-threading (masing-masing untuk 3.13 ke atas)
  • Skrip uji: Fibonacci (fibo.py), bubble sort (bubble.py)
  • Mode thread: single-thread, 4 thread
  • Mesin uji: Linux (Framework i5), macOS (M2)
• Versi Node.js dan Rust juga ikut dibandingkan sebagai referensi

Skrip pengujian

• Fibonacci (fibo.py): menggunakan struktur rekursif, menjalankan fibo(40) pada tiap lingkungan
• Bubble sort (bubble.py): mengurutkan 10.000 angka acak
• Setiap pengujian diulang 3 kali untuk memperoleh nilai rata-rata
• Kode pengujian dipublikasikan di repositori GitHub

Benchmark #1: Fibonacci (single-thread)

• Python 3.14 mencatat kecepatan sekitar 27% lebih baik dibanding 3.13 (6,59 detik vs 8,26 detik)
• Sejak versi 3.11, performanya berubah dari "sangat lambat" menjadi "setidaknya agak kurang lambat"
• PyPy sekitar 5 kali lebih cepat daripada 3.14, setara dengan Node.js, sementara Rust jauh paling cepat
• Free-threading masih lebih lambat daripada versi standar pada single-thread, tetapi selisih kecepatannya mengecil di 3.14 (sekitar 91% dari performa standar)

JIT, interpreter free-threading

• JIT tidak memberikan peningkatan performa yang terasa pada struktur fungsi rekursif ini
• Free-threading justru sedikit lebih lambat pada single-thread
• Batas peningkatan performa JIT bisa berbeda tergantung struktur fungsi

Benchmark #2: Bubble sort (single-thread)

• Python 3.14 sedikit lebih cepat daripada 3.11, tetapi selisihnya lebih kecil dibanding Fibonacci (3.14: 2,18 detik, 3.11: 2,48 detik)
• PyPy sekitar 18 kali lebih cepat daripada 3.14
• JIT kadang sedikit lebih cepat di Linux, tetapi di macOS hampir tidak ada perbedaan

Benchmark #3: Fibonacci (multi-thread)

• Pada interpreter standar, karena GIL (Global Interpreter Lock), menambah jumlah thread tidak memberikan percepatan sebesar yang diharapkan
• Interpreter free-threading (3.14) menjadi 3,1x lebih cepat dibanding versi standar
• Pengaruh JIT hampir tidak terlihat
• Hanya hasil PyPy yang diukur; Node.js/Rust tidak dibandingkan pada pengujian ini

Benchmark #4: Bubble sort (multi-thread)

• Free-threading (3.14 FT) menghasilkan performa 2x lebih cepat dibanding versi standar (3.14), terutama menonjol pada pekerjaan yang intensif CPU
• JIT tidak menunjukkan keunggulan performa yang jelas
• Performa free-threading di Mac cukup menonjol

Kesimpulan

• CPython 3.14 menunjukkan performa tercepat di antara CPython yang ada saat ini
• Jika upgrade sulit dilakukan, disarankan memakai versi 3.11 atau lebih baru
• Interpreter JIT dalam praktiknya hanya memberi peningkatan kecepatan yang minim
• Interpreter free-threading punya keunggulan jelas pada kondisi multi-thread yang intensif CPU
• PyPy sangat jauh lebih cepat dan layak dieksplorasi lebih lanjut

Lainnya

• Hasil dapat berbeda tergantung berbagai variabel lingkungan, jadi disarankan melakukan benchmark dan verifikasi sendiri
• Detail lebih lanjut dan kode dapat dilihat di repositori GitHub

[GN⁺]

Opini Hacker News

• Saya ingin bercerita tentang seseorang yang mengubah hidup saya. Saya membuat situs web pertama saya lewat Flask mega tutorial, dan tepat sebelum peluncuran saya mentok di bagian penting penanganan file rusak di Flask. Saya lalu bertanya, mendapat solusi lewat jawaban di Stack Overflow, dan langsung menerapkannya ke situs. Setelah itu situsnya menyebar sangat luas. Untuk referensi, saya tinggalkan tautan jawabannya stackoverflow link

  • Ini tidak ada hubungannya dengan Flask, tetapi saya benar-benar tidak suka logo Flask yang baru. Logo sebelumnya terasa vintage dan seperti dibuat dengan tangan, sedangkan logo baru terlihat seperti karya iseng anak SMA yang bermain-main dengan WordArt. Logo lama, logo baru

  • Saya ingin bertanya apakah situs yang kamu buat itu yout.com. Saya penasaran apakah masih memakai Flask

  • Akan sangat menyenangkan kalau suatu hari bisa vibe coding lagi dan menghidupkan kembali situs microphonetest.com

• Saya menyarankan agar saat menulis benchmark, jangan mengukur waktu di dalam loop lalu menjumlahkannya. Lebih baik ukur waktu eksekusi seluruh loop lalu bagi dengan jumlah iterasi. Jitter dari pengukuran waktu itu sendiri bisa mendistorsi hasil

  • Saya merekomendasikan timeit dari standard library timeit docs

• Saya khawatir Python akan menjadi tetap seperti TeX di versi 3.14 tautan Reddit

  • Saat melihat pendapat yang berharap Python tidak akan "berhenti", saya merasa segar membaca bahwa Donald Knuth lebih menghargai sistem yang terus menghasilkan hasil yang sama daripada perubahan. Di dunia tempat segala sesuatu terasa usang hanya dalam beberapa tahun, obsesi untuk mengganti sesuatu hanya karena ada OOO baru terasa seperti penyakit. Tidak ada alasan kita tidak bisa menulis kode yang dipakai 100 tahun. Kode pada akhirnya adalah matematika. Sama seperti kita tidak dianggap kuno karena memakai polinomial yang ditemukan ribuan tahun lalu, saya rasa kita juga perlu sikap untuk bertahan pada hal yang sudah terbukti. Tidak perlu terobsesi pada setiap versi baru dan alat baru. Menurut saya, orang yang menulis kode yang tidak perlu diubah justru benar-benar memberi kontribusi

  • Komentar bahwa ini sangat cocok dengan lelucon tentang πthon

• Setiap kali ada berita Python, saya merasa sayang karena pada 2025 pun PyPy masih berjalan di jalur terpisah. Saya penasaran apakah Python tanpa GIL someday juga akan memungkinkan C FFI tanpa GIL. Menurut saya itu akan sangat membantu Python

  • C FFI dari dulu bisa melepas GIL secara manual, jadi saya penasaran apa tepatnya maksudnya

  • Saya pikir ekosistem yang sehat adalah yang berawal dari bahasa C lalu melahirkan berbagai dialek lewat banyak implementasi compiler. Itu mendorong eksperimen dan perkembangan. Saya juga menganggap perbedaan PyPy dan CPython tidak terlalu besar, dan kompatibilitasnya tinggi panduan kompatibilitas pypy

  • freethreading memang untuk tujuan itu. Setahu saya, banyak library C FFI masih belum diubah agar bisa berjalan tanpa GIL, jadi freethreading belum bisa dijadikan default

  • Python sudah menambahkan JIT eksperimental, jadi bisa dibilang selangkah lebih dekat ke PyPy. Saya tidak tahu apakah ke depan mereka akan membuat JIT baru sendiri atau menggabungkan PyPy, tetapi saya yakin mereka telah belajar banyak dari PyPy

  • Saya ingin bertanya apakah menurutmu masalah seperti ini—menggabungkan sistem implementasi yang terpisah—bisa berubah. Skenario di mana Python secara tidak sengaja memperkenalkan breaking change lain yang berdampak buruk pada performa akan merugikan banyak pengguna. Saya ragu organisasi Python benar-benar menginginkan itu

• Menarik bahwa PyPy bahkan lebih cepat daripada CPython free-threaded pada kode multithread

• Peralihan ke non-GIL terlihat berjalan sangat mulus. Dibandingkan transisi versi 2→3, kali ini benar-benar luar biasa. Fakta bahwa performanya cepat mendekati kecepatan standar juga sangat menjanjikan, dan saya berharap elemen-elemen yang belum kompatibel segera hilang

• Jika ingin cepat-cepat menjalankan benchmark sendiri, saya merekomendasikan repo fast_langton_ant. Jalankan dengan format seperti python3 server.py -s 10000000 -n

• Saya penasaran apakah fitur komentar terlipat (fold comment) diterapkan berdasarkan karma atau opsi lain. Kisah tentang Miguel membantu tadi sangat berkesan karena itu komentar paling populer, tetapi saat saya hanya ingin melihat pembahasan yang terkait langsung dengan isi tulisan, saya baru sadar tidak ada fitur lipat

• Menilai penggunaan Python yang realistis dengan benchmark yang hanya memakai loop sederhana dan operasi bilangan bulat terasa kurang tepat. Hash map atau pemrosesan string lebih dekat ke kode nyata. Banyak pengguna Python menyerahkan komputasi numerik ke library eksternal

  • Semua benchmark pada dasarnya dirancang untuk mengukur sesuatu menurut kriteria tertentu. Penulis sudah menjelaskan tujuannya di artikel, jadi kalau penasaran saya sarankan melihatnya

  • Saya berharap artikelnya lebih dianalisis secara mendalam, tetapi untuk penggunaan saya sendiri benchmark seperti ini justru lebih cocok. Dalam kasus saya, sebagian besar pekerjaan adalah membuat simulasi Monte Carlo atau komputasi ilmiah sederhana berulang kali untuk berbagai masalah. Untuk simulasi sekali pakai, saya tidak repot memakai algoritme cepat atau library yang tidak familier. Kadang kalau butuh 10 menit pun tidak masalah (ya, saya tetap sering memakai scipy dan numpy). Karena saya sering mengubah asumsi iterasi, saya berusaha sesederhana mungkin. Keterbacaan dan kode spontan itu penting, dan saya tidak terlalu peduli walau optimisasinya kurang baik (misalnya Fibonacci, bubble sort, nested for loops). Kalau benar-benar butuh performa, saya implementasikan sendiri isinya dengan cpp/zmp/pybind/numba

  • Memasukkan contoh populer seperti pemanggilan endpoint FastAPI atau perhitungan numpy ke benchmark akan lebih dekat dengan penggunaan Python yang nyata. Memang bagian seperti itu mungkin bukan pure Python code, tetapi kenyataannya banyak orang memakai Python seperti itu

• Saya ragu seberapa realistis benchmark yang hanya memakai tight loop dan operasi int

• Saya penasaran apakah benchmark ini memasukkan tail call interpreter eksperimental yang baru (opsi --with-tail-call-interp) dokumentasi resmi tail-call-interp. Karena tidak disebutkan dalam hasil pengujian, saya menebak mungkin belum dimasukkan. Saya ingin melihat perbandingan seberapa besar bedanya tail call interpreter terhadap implementasi yang lain

  • Build Python yang dipakai penulis memang dalam keadaan tail call diaktifkan (opsi --with-tail-call-interp). Saya tidak yakin apakah optimisasi itu juga diterapkan pada recursive tail call, tetapi kalau iya seharusnya ada peningkatan performa pada tes Fibonacci