Meninjau Tahun Pertama Python Free-Threaded

• Python free-threaded dirancang agar dapat memanfaatkan perangkat keras multicore secara efisien
• Di CPython 3.14, keamanan thread dan performa pada modul inti meningkat secara signifikan
• Masih ada banyak paket penting yang belum mendukung build free-threaded
• Siapa pun dapat ikut mendorong perkembangannya melalui laporan dari lingkungan penggunaan nyata dan kontribusi komunitas

---

Gambaran umum

Minggu lalu CPython 3.14.0b1 dirilis, dan minggu ini PyCon 2025 dimulai di Pittsburgh
Dua peristiwa ini menjadi tonggak penting bagi distribusi dan stabilisasi Python free-threaded
Tulisan ini meninjau perjalanan satu tahun terakhir, serta menjelaskan bagaimana tim Quansight memainkan peran kunci dalam menerapkan build free-threaded secara eksperimental ke workflow produksi nyata dengan dependensi yang kompleks

Arti dan pentingnya Python free-threaded

• Dukungan Python free-threaded memungkinkan pemanfaatan penuh sumber daya komputasi pada perangkat keras modern, ketika CPU dan GPU multicore sudah menjadi hal umum
• Dengan pendekatan GIL (Global Interpreter Lock) yang lama, pemanfaatan penuh algoritme paralel memerlukan solusi penghindaran dan tuning terpisah
• Biasanya orang memakai multiprocessing alih-alih modul threading, tetapi ini memiliki biaya pembuatan proses yang besar, dan penyalinan data juga tidak efisien
• Pada paket Python yang menyertakan kode native, build free-threaded tidak otomatis kompatibel, sehingga audit kode wajib dilakukan untuk menjamin keamanan thread
• Penghapusan GIL memerlukan perubahan struktural yang mendalam pada interpreter CPython, dan sekaligus menyingkap masalah struktural pada paket-paket yang sudah ada

Pencapaian utama

• Bersama tim Python runtime Meta, dukungan Python free-threaded telah dikontribusikan ke berbagai paket dan proyek berikut
  • Alat packaging dan workflow seperti meson, meson-python, setup-python GitHub Actions, packaging, pip, setuptools
  • Generator binding seperti Cython, pybind11, f2py, PyO3
  • Paket inti ekosistem PyData seperti NumPy, SciPy, PyArrow, Matplotlib, pandas, scikit-learn, scikit-image
  • Dependensi utama dengan unduhan tinggi di PyPI seperti Pillow, PyYAML, yarl, multidict, frozenlist
• Paket populer yang masih belum didukung (CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, grpcio, dan lain-lain) serta library machine learning (safetensors, tokenizers, dan lain-lain) juga sedang dikerjakan secara bertahap
• Core developer CPython dari tim Quansight telah memasukkan perbaikan berikut ke versi 3.14
  • Modul warnings kini bekerja aman terhadap thread secara default pada build free-threaded
  • Perbaikan masalah keamanan thread yang serius pada asyncio serta peningkatan skalabilitas paralel
  • Peningkatan menyeluruh keamanan thread pada modul ctypes
  • Peningkatan performa garbage collector free-threaded
  • Optimalisasi skema deferred reference counting dan adaptive specializing interpreter
  • Banyak perbaikan bug dan penguatan keamanan thread lainnya
• Mereka juga menulis panduan komprehensif1 untuk dukungan Python free-threaded, menyediakan dokumentasi yang bisa menjadi rujukan praktis bagi lebih banyak paket ke depannya

Kondisi ekosistem Python free-threaded

• Satu tahun lalu (saat 3.13.0b1 dirilis), instalasi sebagian besar paket Python pada build free-threaded rusak total
• Penyebab kegagalan build bukan terutama masalah mendasar, melainkan karena opsi default yang belum didukung atau asumsi-asumsi kecil yang runtuh
• Selama setahun terakhir, banyak masalah telah diselesaikan bersama komunitas, dan dukungan resmi Cython 3.1.0 menjadi titik balik besar
• Masih ada paket yang menyertakan kode terkompilasi tetapi belum menyediakan wheel free-threaded
  Perkembangannya dapat dilihat pada tabel pelacakan manual dan otomatis2

Tantangan yang dihadapi

• Saat ini, build Python free-threaded berada pada tahap yang membutuhkan eksperimen dan umpan balik dari workflow nyata
• Potensi peningkatan performa sangat besar, terutama pada workflow dengan biaya penggunaan multiprocessing yang tinggi, tetapi audit keamanan thread yang rinci untuk tiap paket tetap wajib
• Banyak library menyediakan struktur data yang dapat diubah tanpa dokumentasi keamanan thread yang memadai atau jaminan keamanan yang nyata
• Pada paket yang besar dan sarat legacy, dukungan sering terlambat karena kurangnya orang yang benar-benar memahami keseluruhan kode
• Diperlukan upaya tingkat komunitas untuk menjaga keberlanjutan pemeliharaan paket inti

Cara berkontribusi

• Anda dapat merujuk ke panduan kontribusi pada panduan resmi
• Pelacakan isu di seluruh ekosistem dan dokumen kompatibilitas utama dikelola di repositori free-threaded-compatibility5
• Diskusi dan kontribusi juga dapat dilakukan melalui Discord komunitas yang dikelola Quansight-Labs6

Pengumuman presentasi di PyCon

• Penulis dan rekan satu timnya, Lysandros Nikolaou, dijadwalkan memberikan presentasi di PyCon 2025
• Mereka berencana membagikan contoh porting praktis dan kiat yang lahir dari pengalaman langsung, dan rekaman video di YouTube juga akan disediakan
• Mereka meyakini build free-threaded adalah masa depan bahasa Python, dan sangat antusias bisa ikut berkontribusi mewujudkannya
• Mereka berharap upaya hari ini menjadi titik balik yang membuka masa depan bagi paket-paket yang beragam dan sangat luas, yang digunakan jutaan developer setiap hari

[GN⁺]

Opini Hacker News

• Banyak orang menggunakan multiprocessing, dan disebutkan bahwa biaya pembuatan proses itu mahal

  • Ada fitur SharedMemory, tetapi tidak paham mengapa itu tidak lebih sering digunakan

  • Menekankan bahwa pengalaman menggunakan ShareableList cukup baik

  • Di Unix, kecepatan pembuatan proses berada di bawah 1 ms

    • Namun memulai proses interpreter PYTHON bisa memakan 30 ms~300 ms tergantung jumlah import
    • Karena perbedaannya bisa mencapai satu hingga dua digit orde besaran, angka yang akurat itu penting
    • CGI adalah pengecualian dalam hal ini, dan dengan C·Rust·Go tidak ada masalah
    • Dibagikan contoh bahwa sqlite.org juga menggunakan pendekatan proses terpisah untuk setiap request

  • ShareableList hanya bisa berbagi skalar atomik serta bytes·string

    • Objek terstruktur Python menimbulkan biaya serialisasi seperti pickle dump dan biaya memori duplikasi per proses

  • Ada pengalaman sukses besar dalam berbagi array numpy

    • Pendekatan berbagi yang eksplisit bukanlah beban besar dibanding sulitnya men-debug masalah akibat berbagi data antarthread secara tidak sengaja
    • Banyak orang melebih-lebihkan seberapa bagus thread dibanding multiprocessing
    • Khawatir kalau setelah GIL dilepas, debugging segfault yang acak akan makin sering
    • Disebutkan bahwa orang-orang tidak terlalu banyak mengeluh karena JavaScript tidak mendukung threading berbasis shared memory
    • Ditafsirkan bahwa JavaScript cukup cepat sehingga kebutuhan itu lebih kecil
    • Ada harapan agar lebih banyak upaya dicurahkan untuk meningkatkan performa dasar Python

  • Karena proses mati secara independen, jika sebuah proses mati saat sedang memodifikasi struktur data shared memory sambil memegang lock, pemulihannya akan sulit

    • Dicontohkan struktur shared memory Postgres dan perlunya menghentikan seluruh proses backend
    • Pada thread, karena semuanya mati bersama, masalah seperti ini kurang terasa keberadaannya

  • Shared memory hanya bekerja pada perangkat keras khusus

    • Di lingkungan seperti AWS Fargate tidak ada shared memory, sehingga harus memakai jaringan atau file system dan latensi pun meningkat
    • Replikasi proses dengan metode fork membawa masalah lain
    • Berdasarkan pengalaman nyata, green thread dan model actor jauh lebih efektif

• Ada rasa penasaran apakah penghapusan GIL punya dampak lain pada kode Python multithread selain pemrosesan paralel

  • Pemahaman yang ada adalah GIL dipertahankan bukan karena multithread bergantung padanya, melainkan karena penghapusan GIL menyebabkan kerumitan implementasi interpreter dan ekstensi C, serta menurunkan kecepatan kode single-thread

  • Ingin tahu apakah Free-threaded Python tetap memberi jaminan lama bahwa preemption bisa terjadi kapan saja di batas bytecode

  • Atau apakah cara menulisnya akan berubah, misalnya perlu lebih banyak lock

  • Free-threaded Python pada dasarnya memberi jaminan yang sama

    • Hanya saja, tanpa free-threading orang cenderung lebih jarang memakai threading, sehingga bug preemption di batas eksekusi tidak terlalu sering muncul dalam praktik
    • Dengan hadirnya free-threading, lebih banyak bug akan terekspos
    • Kode pengguna menjadi lebih sederhana karena tidak perlu lagi memakai jalan memutar multiproses; dianggap cukup sepadan dengan bertambahnya kompleksitas interpreter
    • Masalah bertambah rumitnya ekstensi C justru lebih parah pada sub-interpreter daripada free-threading; tim numpy telah menyatakan dengan jelas bahwa mereka tidak bisa mendukung sub-interpreter
    • numpy sudah mendukung free-threading dan sedang memperbaiki bug yang tersisa
    • Sedikit penurunan kecepatan single-thread (beberapa persen satu digit) dianggap trade-off yang layak

  • Pemakaian multicore memang jadi mungkin, tetapi performa per thread menurun dan library perlu dikerjakan ulang

    • Saat bereksperimen dengan PyTorch, ada pengalaman penggunaan CPU 10 kali lipat tetapi throughput kerja hanya setengahnya
    • Diharapkan akan membaik seiring waktu, dan tetap disambut baik karena ini telah ditunggu selama 20 tahun

  • Race condition bisa muncul lebih sering, jadi untuk menjaga keandalan perlu lebih berhati-hati saat menulis Python multithread

• Disampaikan kabar bahwa Microsoft membubarkan tim Faster Python

  • Itu terjadi karena proyeksi kinerja 2025 tidak memenuhi harapan sehingga tim tidak dipertahankan

  • Akan dilihat apakah peningkatan performa tetap masuk ke CPython ke depan, atau apakah ada perusahaan lain yang akan mensponsori

  • Facebook (Meta) tampaknya masih memberi sebagian dukungan

  • Disebutkan bahwa jadwal Microsoft sangat tertinggal dibanding komitmennya

    • Belakangan ini mereka pasti mengetahui adanya masalah politik·tata kelola yang serius; ada pendapat bahwa pegawai yang kompeten tentu tidak ingin berkontribusi lalu difitnah oleh kelompok itu
    • Ada kritik bahwa organisasi CPython terlalu banyak berjanji, menumpuk pekerjaan ke kubu yang patuh, dan menyingkirkan penentang yang kompeten
    • Dulu masalah seperti ini tidak ada; sekarang merupakan masalah yang mereka timbulkan sendiri

  • Hasil seperti ini disayangkan, tetapi disebutkan juga bahwa perkiraan pribadi yang sejak awal tidak percaya pada komitmen jangka panjang Microsoft ternyata benar

  • Ada rumor bahwa baru-baru ini Google juga tampaknya memecat seluruh tim pengembangan Python mereka

    • Muncul pertanyaan apakah keduanya memiliki penyebab zaman atau faktor kesamaan tertentu

  • Sangat disayangkan, tetapi nuansanya adalah setelah embrace & extend, hanya tinggal satu hal lagi

• Ada yang bertanya apakah hanya dirinya yang khawatir melihat GIL hilang dari Python

  • Kode multithread yang kompleks sulit dipercaya di bahasa apa pun, dan Python terasa lebih mengkhawatirkan karena sifatnya yang dinamis

  • Ditekankan bahwa bukan dia saja yang takut terhadap perubahan ini, meskipun alasannya mungkin tidak sepenuhnya rasional

    • GIL adalah utang teknis murni, jadi perlu dihapus demi kepentingan komunitas
    • Belakangan ini di Python kebanyakan orang memakai non blocking IO dan async alih-alih thread
    • Jika tidak memakai thread, penghapusan GIL tidak membawa perubahan; library C juga aman dalam mode single-thread
    • Perlu berhati-hati hanya jika benar-benar memakai thread
    • Kode Python thread yang naif selama ini bertindak seperti single-thread karena dibatasi GIL, tetapi sekarang mungkin akan sedikit lebih cepat sekaligus berpotensi punya lebih banyak bug
    • Solusinya adalah tidak memakai thread, atau kalau memakainya, pelajari dengan benar
    • Ke depan diharapkan akan ada abstraksi yang lebih baik, dan ada harapan komunitas akan membahas structured concurrency dan semacamnya

  • Ia sendiri aktif menggunakan asyncio

    • Walau single-thread, Python yang concurrent tetap bisa ditulis dengan nyaman; dipakai seperti Node.js
    • Untuk pekerjaan web·jaringan, pendekatan seperti ini direkomendasikan

  • Diperkirakan akan muncul pola seperti di bidang ML/AI, di mana para ahli lebih dulu membuat library yang kompleks lalu menyerahkannya kepada pengguna umum

    • Ada semakin banyak kasus di mana GIL Python menjadi bottleneck yang serius
    • Karena itu ia belajar bahasa Go; bisa dibilang memiliki dukungan thread yang benar, dengan abstraksi lebih rendah dari Python namun lebih tinggi dari C/C++
    • Model compiler juga menjadi latar belakang penting, tak kalah dari threading itu sendiri

  • Mungkin terdengar seperti menebar kecemasan yang tidak perlu, tetapi diingatkan bahwa LLM dilatih menggunakan kode Python yang selama beberapa dekade mengasumsikan keberadaan GIL

  • Ada atau tidaknya GIL hanya relevan bagi orang yang ingin memanfaatkan multicore

    • Jika saat ini juga tidak terlalu memikirkan threading·multiprocessing, praktis tidak ada perubahan nyata
    • Isu race condition tetap bisa terjadi terlepas dari ada atau tidaknya GIL

• Ada yang cukup sering memakai Python tetapi bukan ahli, dan kadang hanya menjalankan beberapa fungsi sederhana secara bersamaan lewat concurrent.futures

  • Ia ingin tahu apa yang perlu diubah pengguna seperti itu ke depannya

  • Thread tidak lagi terikat GIL sehingga secara keseluruhan akan lebih cepat

    • Jika lock untuk objek bersama sudah ditangani dengan benar, tidak ada hal tambahan yang perlu dikhawatirkan

• Dibagikan pandangan dari pengalaman 20 tahun sebagai pengembang profesional dengan Python

  • Thread benar-benar hanya diperlukan saat message passing tidak bisa dihindari

    • Ekosistem Python sudah menyediakan jalan memutar untuk semua situasi seperti itu
    • Karena banyak jebakan dalam menangani banyak thread (seperti lock), ke depannya ini mungkin hanya perlu di domain atau library tertentu
    • Jika ingin memaksimalkan performa sejauh mungkin dengan Python murni, bisa memanfaatkan library berbasis native code (mis. Pypy, numba)
    • Terobosan performa Python pada akhirnya adalah pemrograman async; sangat direkomendasikan untuk dipelajari

  • Ada yang sudah memakai Python selama waktu yang mirip dan setuju, tetapi mengungkapkannya sedikit berbeda

    • Karena thread Python memang sangat buruk, berkembanglah berbagai jalan memutar untuk menghindarinya
    • Saat mencoba mempercepat pekerjaan CPU-bound 2 kali dengan thread, ia terbentur masalah GIL lalu beralih ke multiprocessing; timbul biaya karena serialisasi struktur data, dan hasilnya tidak efisien seperti 2 kali core hanya memberi kecepatan 1,5 kali
    • Jika ada dukungan thread yang baik, ada banyak lingkungan tempat itu ingin dimanfaatkan; karena selama ini tidak ada, berbagai pendekatan alternatif pun dipakai
    • Jika cocok dengan situasinya, async sangat direkomendasikan (glyph, Anda benar!)

• Walau gambar itu buatan AI, terasa aneh karena ular pada gambar punya dua ekor

  • Ada komentar dukungan agar hal itu didiamkan saja; sambil bercanda disebut bahwa kalau artikel Python memakai gambar ular, biasanya itu sudah menjadi sinyal yang tidak terlalu layak dipedulikan

  • Diusulkan nama bercanda, "Confusoborus"

• Ada yang menunjuk bahwa ular pada gambar header tampak memiliki dua ekor

  • Dijawab secara jenaka bahwa mungkin itu wujud thread kedua yang dibuat di dalam proses yang sama

• Selain dukungan library, ada yang penasaran apakah ada batasan lain untuk menjalankan worker WSGI dan Celery dalam satu proses tunggal

  • Tidak ada batasan, tetapi pendekatan seperti itu bukan fitur kelas satu dari bahasa ini
    • Dijelaskan bahwa GIL adalah isu utang teknis
    • Selain paralelisme, ada elemen lain juga yang menuntut pelepasan GIL

• Dianggap sebagai pekerjaan fondasi yang sangat besar untuk era performa berikutnya