Proyek penghapusan GIL dan CPython yang lebih cepat

• Python Steering Council menyatakan niat untuk menerima PEP 703, sehingga penghapusan GIL di CPython memasuki prosedur bertahap yang panjang dari build eksperimental hingga menjadi mode default
• Penghapusan GIL dapat membuka performa multi-thread, tetapi juga dapat menimbulkan biaya pada performa single-thread yang mencakup sebagian besar ekosistem yang ada, serta kompatibilitas ekstensi C
• Tim Faster CPython menilai bahwa interpreter adaptif terspesialisasi berbasis PEP 659 bergantung pada GIL, sehingga di lingkungan no-GIL strategi optimasi dan beban pemeliharaan perlu dihitung ulang
• Meta menyatakan akan mengalokasikan 3 engineer-years hingga akhir 2025 jika PEP 703 diterima, dan Anaconda berjanji mendukung pekerjaan packaging seperti pip, cibuildwheel, dan conda-forge
• Transisi diarahkan agar menghindari disrupsi seperti saat Python 2→3, dan dapat dibatalkan sebelum dinyatakan sebagai mode default bila kekacauan no-GIL dinilai lebih besar daripada manfaatnya

---

Pembahasan penghapusan GIL di Python kembali memasuki tahap serius

• Global Interpreter Lock (GIL) di Python menserialkan akses ke mesin virtual interpreter agar hanya satu thread yang dapat mengeksekusi kode Python pada satu waktu
• GIL, yang selama ini menghalangi peningkatan performa melalui pemanfaatan banyak thread, telah lama disebut sebagai kelemahan Python
• Sam Gross merilis versi proof-of-concept no-GIL Python pada Oktober 2021, tetapi setelah minat awal, perkembangan selama lebih dari satu tahun berikutnya terbatas
• Setelah itu Python Steering Council mengumumkan niat untuk menerima fitur no-GIL
  • Akan butuh waktu sebelum masuk ke versi rilis yang sebenarnya
  • Masih ada kemungkinan pekerjaan ini dibatalkan di suatu titik pada masa mendatang
  • Dukungan dari beberapa perusahaan meningkatkan peluang keberhasilannya

Ketegangan antara Faster CPython dan performa single-thread

• Dalam Python Language Summit 2022, Gross mempresentasikan fork no-GIL dan berupaya memperoleh persetujuan implisit atas arah pekerjaan tersebut, tetapi tidak berujung pada konsensus karena dampak detailnya belum cukup dipahami
• Pada saat yang sama proyek Faster CPython berfokus pada peningkatan performa single-thread interpreter
• Mark Shannon menulis PEP 659 “Specialized Adaptive Interpreter”, dan sebagian perubahan ini masuk ke Python 3.10 dan 3.11
• Di PyCon, Brandt Bucher dari tim Faster CPython mempresentasikan instruction adaptif, sementara Shannon mempresentasikan perbaikan layout memori dan teknik optimasi lainnya
• Karena hampir semua program Python yang ada ditulis sebagai single-thread akibat GIL, peningkatan performa single-thread secara langsung memengaruhi performa yang dirasakan di seluruh ekosistem Python

Usulan PEP 703 dan kekhawatiran awal

• Łukasz Langa pada Januari 2023 mempublikasikan versi pertama PEP 703 “Making the Global Interpreter Lock Optional in CPython” yang ditulis oleh Gross
• Bersamaan dengan ekspektasi terhadap no-GIL, modul ekstensi Python yang ditulis dalam C muncul sebagai kekhawatiran utama
  • GIL selama ini berperan mencegah berbagai masalah konkurensi dalam kode ekstensi C
  • Penghapusan GIL dapat menimbulkan bug baru dalam kode tersebut
• Ada kesepahaman bahwa transisi flag day seperti saat pindah dari Python 2 ke 3 harus dihindari
  • Transisi penghapusan GIL harus tetap berjalan mulus bahkan dengan kode yang belum siap
• Shannon menanyakan berapa penurunan performa yang masih dapat diterima untuk kode single-thread, dan perkiraan pribadinya berada di kisaran 15~20%, serta bisa lebih besar tergantung dampaknya terhadap PEP 659
• Eric Snow, yang menulis PEP 684 “Per-Interpreter GIL” dan PEP 683 “Immortal Objects”, memposting analisis panjang dan menilai pendekatan no-GIL dan subinterpreter tidak harus saling bertentangan

Biaya dan manfaat bagi ekstensi C

• Gross menjawab bahwa dampaknya terhadap ekstensi C tidak sepenuhnya negatif
• PEP itu memuat kutipan dari para maintainer ekstensi C API yang banyak digunakan tentang kompleksitas yang mereka hadapi saat mengakali batasan GIL
• Zachary DeVito, core developer PyTorch, mengungkapkan bahwa dalam beberapa bulan terakhir ia tiga kali menghabiskan waktu satu orde lebih besar untuk memahami cara mengakali batasan GIL daripada menyelesaikan masalah yang sebenarnya
• no-GIL dapat menciptakan masalah konkurensi baru bagi maintainer modul ekstensi, tetapi sekaligus dapat mengurangi kompleksitas untuk menghindari GIL

PEP yang diperbarui dan perdebatan performa

• Pada awal Mei 2023, Gross mempublikasikan implementasi PEP 703 berbasis versi pengembangan Python 3.12 dan PEP yang telah diperbarui
• Pada 12 Mei ia meminta keputusan PEP dari Steering Council, tetapi diskusi berlanjut lebih jauh sebelum keputusan diambil
• Pada 2 Juni, Shannon mengevaluasi dampak performa PEP tersebut dan mengajukan kisaran 11~30%, yang memicu perdebatan
• Shannon menilai interpreter spesialisasi adaptif bergantung pada GIL, sehingga jika no-GIL diterima maka strategi optimasi harus dirancang ulang
  • Upaya untuk desain ulang dan implementasi itu tidak bisa dialokasikan ke pekerjaan optimasi yang sebenarnya
• Langa mempublikasikan angka benchmark yang menunjukkan dampak jauh lebih kecil daripada estimasi Shannon, dan hasil tambahan lebih dekat dengan apa yang dilaporkan Gross dalam PEP

Pelajaran dari transisi Python 2→3

• Guido van Rossum menilai transisi akan lebih mudah jika kode Python 2 dan 3 bisa hidup berdampingan dalam interpreter yang sama
• Ia menekankan bahwa jika no-GIL dijalankan, modul ekstensi yang membutuhkan GIL juga harus dapat di-import di interpreter no-GIL tanpa pekerjaan tambahan
  • Kode aplikasi juga tidak boleh perlu diubah
  • Modul ekstensi juga tidak boleh perlu diubah
• Gregory P. Smith dari Steering Council menyatakan bahwa cakupan dampak PEP 703 sangat besar sehingga belum siap diputuskan segera
• Smith mengakui adanya permintaan, tetapi menilai perlu mempertimbangkan seluruh ekosistem dan mencari cara transisi yang tidak merusak dunia
• Gross menanggapi bahwa menunda keputusan tanpa kriteria penerimaan dan jadwal yang jelas pada praktiknya bekerja seperti “no”

Tiga opsi menurut tim Faster CPython

• Dalam diskusi “A fast, free threading Python”, Shannon merangkum tiga opsi ke depan
  • Mengejar interpreter single-thread cepat sesuai rencana saat ini
  • Mengejar interpreter free-threading no-GIL yang berdampak pada performa single-thread, besarnya belum diketahui tetapi bukan nol
  • Mengejar keduanya sekaligus
• Shannon menilai perlu memilih apa yang akan dibatasi di antara performa, paralelisme, dan mutabilitas
  • Ia menyebutnya lebih dekat ke “Performance, parallelism, mutability: pick one to restrict” daripada “pick two”
• Ia memperingatkan bahwa untuk membuat Python cepat di lingkungan free-threading dibutuhkan riset orisinal, dengan biaya dan risiko yang lebih besar
• Opsi yang ia sukai adalah opsi ketiga, tetapi menurutnya tidak boleh memilih no-GIL saja lalu berharap “seseorang akan menyelesaikan masalah performa”
• van Rossum juga menilai yang terbaik adalah memperoleh free threading dan performa per-thread yang cepat sekaligus, tetapi menekankan perlunya sumber daya tambahan

Dukungan perusahaan dan opini para core developer

• van Rossum menyatakan Microsoft akan terus mendukung tim Faster CPython, dan peran tim ini tidak terbatas hanya pada pekerjaan performa single-thread
• Tujuannya adalah menyesuaikan pekerjaan spesialisasi dan optimasi untuk dunia no-GIL, lalu pada akhirnya menjadikan no-GIL sebagai satu-satunya mode build tanpa penurunan performa single-thread
• Carl Meyer dari Meta menyatakan bahwa jika PEP 703 diterima, Meta akan mengalokasikan 3 engineer-years hingga akhir 2025
  • Engineer yang memiliki pengalaman internal CPython akan bekerja sama dengan tim core dev
  • Mengintegrasikan implementasi PEP 703 ke CPython dengan mulus
  • Terus meningkatkan kompatibilitas dan performa no-GIL CPython
• Stan Seibert dari Anaconda menyatakan akan mendukung masalah packaging yang mengikuti adopsi PEP 703
  • Termasuk pekerjaan terkait pip, cibuildwheel, dan conda-forge
  • Termasuk pekerjaan yang diperlukan untuk menyampaikan paket kompatibel no-GIL kepada komunitas Python
• Dalam survei core developer, 87% dari 46 responden menjawab bahwa Python free-threaded harus didorong secara aktif, dan 63% dari 38 responden menjawab bersedia berkontribusi pada dukungan dan pemeliharaan no-GIL Python berbasis PEP 703

Keputusan Steering Council dan transisi bertahap

• Pada 28 Juli, Thomas Wouters mengumumkan bahwa Steering Council memutuskan menerima PEP 703, tetapi rincian penerimaannya masih dikerjakan
• Pendekatannya adalah memperkenalkan interpreter no-GIL terlebih dahulu untuk melihat bagian yang masih kurang, lalu melengkapi pekerjaan yang diperlukan sebelum no-GIL menjadi default dan pada akhirnya satu-satunya versi
• Masa transisi diperkirakan sekitar 5 tahun
• Council tidak menginginkan situasi seperti Python 3, dan menilai perubahan kode pihak ketiga yang diperlukan agar cocok dengan build no-GIL juga harus tetap bekerja apa adanya di build with-GIL
• Dalam jangka pendek, build no-GIL eksperimental yang mungkin hadir pada Python 3.13 diajukan
  • Python 3.13 dijadwalkan pada Oktober 2024
  • Build ini dapat digunakan core developer dan pihak lain untuk bereksperimen
• Dalam jangka menengah, no-GIL akan menjadi opsi yang didukung tetapi bukan default
  • Waktunya sangat bergantung pada seberapa cepat komunitas mengadopsi dan mendukung build no-GIL
• Dalam jangka panjang, no-GIL akan menjadi build default dan GIL akan dihapus sepenuhnya
  • Hal itu harus dilakukan tanpa merusak kompatibilitas ke belakang secara tidak perlu

Pekerjaan yang masih jauh dari selesai

• Wouters menilai penghapusan GIL adalah pekerjaan yang jauh lebih besar daripada sekadar menerima satu PEP
• Para core developer perlu membangun pengalaman dengan no-GIL Python dan berdasarkan itu memimpin komunitas lainnya
• Dalam proses merapikan thread safety kode yang ada, mungkin dibutuhkan C API dan Python API baru
• Selama seluruh proses, kemajuan dan jadwal harus dievaluasi ulang secara berkala
  • Jangan sampai berkembang menjadi perang kompatibilitas mundur selama 10 tahun lagi
  • Jika PEP 703 tampak akan menjadi masalah, prosesnya harus bisa dihentikan dan solusi lain dicari
• Masih banyak riset, coding, testing, eksperimen, dan dokumentasi tersisa sebelum Python no-GIL-only tercapai, dan Python 3.17 yang bisa hadir pada Oktober 2028 disebut sebagai contoh kemungkinan waktunya

[GN⁺]

Komentar Hacker News

• Tulisannya bagus dan merangkum keseluruhan proses dengan baik, tetapi cenderung memberi bobot lebih besar pada sisi penentang penghapusan GIL dan kemungkinan kegagalannya
  Sisi yang berlawanan juga perlu cukup ditekankan. Kualitas kerja Sam Gross sangat tinggi, dan ia juga memasukkan peningkatan kinerja yang tidak terkait langsung dengan no-GIL untuk mengurangi penurunan performa. Ia juga bergerak sangat baik dengan cara open source, dan menunjukkan kesabaran meski responsnya lambat sampai-sampai, tanpa tekanan komunitas, steering committee mungkin akan terus membiarkannya tertahan. Sub-interpreter sejauh ini hampir belum pernah menunjukkan kegunaannya di Python, terutama metrik yang serius, dan ini mendekati upaya pertama yang terdefinisi dan terukur dengan baik. Respons komunitas juga menunjukkan minat besar pada proyek ini, dan steering committee pun menyimpulkan bahwa mereka “berniat menerima PEP 703 dan sedang menyelaraskan ketentuan penerimaan detailnya”. Saya bukan pendukung fanatik no-GIL, tidak masalah jika pada akhirnya GIL tidak dihapus, dan saya berpendapat sub-interpreter sebaiknya dicoba lebih dulu, tetapi ini perlu dilihat secara adil

  • Di sisi sub-interpreter juga banyak pekerjaan sedang berjalan, dan GIL per interpreter masuk ke Python 3.12
    Hasilnya juga cukup mengesankan: https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. Tampaknya hasilnya sebaik yang bisa diharapkan. Pekerjaan sub-interpreter sepertinya akan berjalan paralel dengan pekerjaan free-threading, dan keduanya punya use case yang berbeda
  • Hal yang secara pribadi paling mengganggu saya di Python adalah PEP 582 “Python local packages directory”: https://peps.python.org/pep-0582/
    Sejauh yang saya tahu PDM masih mendukungnya. Saya tidak suka memakai virtualenv untuk build dan deployment, dan berharap Python juga bisa berperilaku seperti JavaScript. Bahwa itu mungkin sudah terbukti. Thread diskusinya ada di https://discuss.python.org/t/pep-582-python-local-packages-d.... Menyebalkan juga ketika “hanya ada tepat satu cara yang benar” dipakai seperti alasan penolakan, padahal saya tidak pernah merasa pernyataan itu benar di Python
  • Saya ingin melihat hanya patch kinerja tanpa bagian no-GIL
  • Saya penasaran mengapa orang menentang penghapusan GIL

• Ini tulisan LWN yang sangat bagus dan sangat layak dibaca. Saat NoGIL dari Sam Gross pertama kali diajukan, saya berharap banyak, tetapi setelah membaca artikel itu dan meninjau pengalaman pribadi, pandangan saya mulai berubah
  Saya pernah membangun sistem backend dalam beberapa bahasa, dan secara umum hanya ada dua jenis. Yang pertama adalah sistem yang membuka endpoint jaringan, menerima request, melakukan komputasi dan request jaringan lain, lalu mengembalikan respons; yang kedua adalah sistem yang membaca pesan dari queue, database, polling API lain, dan semacamnya, lalu melakukan komputasi serta panggilan jaringan sebelum mengirimnya ke queue lain. Pada jenis pertama, latensi penting; pada jenis kedua, throughput penting. Untuk jenis pertama, NoGIL berguna karena ingin membuat thread sesuai request, memastikan endpoint dengan komputasi berat tidak memblokir request lain, dan berbagi pool koneksi database. Untuk jenis kedua, bahkan dalam bahasa tanpa GIL pun saya hampir tidak ingat pernah memakai paralelisme atau konkurensi dalam satu proses dengan resource bersama, karena itu menjadi terlalu sulit dipahami. Optimisasi biasanya berupa batch processing yang cerdas, sedangkan paralelisme dilakukan dengan menjalankan banyak proses independen di banyak mesin. Jika kualitas sistem jenis kedua harus dikompromikan karena NoGIL, saya rasa itu akan cukup mengecewakan, dan memang sebagian besar energi mental saya sekarang dipakai untuk meningkatkan jenis kedua

  • Untuk kasus seperti aplikasi Captain’s Log saya, no-GIL juga menarik pada aplikasi GUI
    Saat ini saya mengimplementasikan JournalParser dengan QThread; parser ini terus membaca event game dari file jurnal pemain yang dibuat oleh Elite: Dangerous dan Odyssey, lalu memunculkan QSignal khusus untuk tiap event agar diproses oleh slot yang mendengarkan Signal tersebut. Di bagian lain aplikasi, tidak adanya GIL juga bisa cukup berguna. https://captainslog.scarygliders.net/captains-log-2/
  • Sebagai pengguna Python untuk hobi, saya mungkin tidak akan memakai konkurensi secara langsung, tetapi seiring waktu standard library dan library eksternal populer kemungkinan besar akan memanfaatkannya
    Dengan begitu, kode semua orang bisa menjadi lebih baik
  • Untuk mendapat manfaat NoGIL, kita tidak harus memakai paralelisme secara langsung. Misalnya web server atau executor tugas asinkron bisa berbagi konteks antar-thread dengan lebih efisien
  • GIL menjadi bottleneck pada aplikasi yang terikat CPU seperti machine learning, jadi wajar jika NoGIL tidak terlalu menarik bagi orang yang menulis aplikasi server
    Tentu saja bisa juga dikatakan bahwa program yang berfokus pada CPU sejak awal seharusnya tidak ditulis dengan Python, tetapi itu cerita lain
  • Saya sedang membangun sistem seperti itu sekarang, dan karena ada resource bersama yang besar, saya harus meninggalkan strategi multiproses
    Jika resource bersama itu read-only, saya tidak terlalu paham mengapa itu akan membingungkan

• Saya meragukan apakah kalimat di thread yang ditautkan, “penghapusan GIL sangat kecil kemungkinannya merusak codebase yang hanya berisi Python,” benar-benar tepat
  Sebagian kode Python multithread bisa saja mengandalkan GIL sehingga operasi tertentu secara implisit dianggap thread-safe. Misalnya, ketika dua thread menambahkan item ke list yang sama, list itu tidak rusak karena GIL mencegah kedua thread menjalankan operasi tersebut secara paralel. Jika GIL dihapus, kode seperti ini bisa tiba-tiba terkena konsekuensi, seperti saat std::vector diubah secara bersamaan di C++. Saya tidak yakin, tapi kalimat ini terasa agak mencurigakan. https://discuss.python.org/t/pep-703-making-the-global-inter...

  • Benar. Ini memang area yang secara sepele dilindungi oleh GIL. Di Go juga ada kasus serupa ketika mengubah map yang sama secara bersamaan bisa menyebabkan panic
    Bagian keamanan thread container dalam PEP 703 membahas masalah ini. Usulannya adalah memberi lock ringan per objek pada setiap list, dictionary, dan set; semua operasi yang memodifikasi objek harus mengambil lock tersebut, dan sebagian besar operasi baca juga harus mengambil lock. Detailnya ada di https://peps.python.org/pep-0703/#container-thread-safety
  • Memang begitu, dan tampaknya tidak banyak cara yang jelas selain melindungi semua operasi struktur data bawaan dengan mutex, seperti struktur data awal Java, yaitu Hashtable dan Vector
    Namun jika begitu, masih tersisa pertanyaan apa yang harus dilakukan ketika membutuhkan [] yang tidak tersinkronisasi
  • append pada list mungkin akan dilindungi dengan lock per instance. Setidaknya di sebagian kode konsep nogil, memang begitu
  • Sebagai solusi naif, mungkin bisa diberi flag yang secara default mengaktifkan GIL, lalu mencetak peringatan jika dimatikan

• Sulit membayangkan batu ujian open source yang lebih berat dari ini
  Keputusannya sendiri masuk akal. Maju dalam mode pengujian, memperlakukan multi-interpreter sebagai eksperimen antara, tetapi menetapkan tujuan pada Python yang bisa berjalan serentak. Namun batasan menjalankan kode lama dan kode baru di mesin virtual yang sama sangat besar. Mengejutkan bahwa ringkasan LWN hampir tidak membahas pengujian, padahal pengujian masih cukup belum terselesaikan dan bisa berujung pada rilis dengan bug serius yang belum diketahui. Microsoft, Facebook/Meta, dan Conda menyediakan sumber daya, dan mayoritas besar kontributor inti ingin maju, tetapi tidak jelas apa yang akan terjadi jika pekerjaannya makin sulit dan dibutuhkan lebih banyak orang. Pada saat yang sama, proyek-proyek raksasa di akademia dan industri, dari situs web hingga big data dan AI, bergantung pada Python, dan biaya yang dialihkan ke developer Python mungkin bisa diukur sebagai persentase PDB. Karena masalah-masalahnya tampaknya bahkan belum diketahui, sebaiknya untuk 3 tahun ke depan atau lebih fokus pada pendekatan Faster CPython yang memberikan perbaikan yang dapat diprediksi, sementara para pendukung Python yang bisa berjalan serentak perlu melampaui prototipe sederhana dan menganalisis masalah apa yang bisa muncul, bagaimana mendeteksinya, dan apa yang bisa dilakukan. Akan lebih adil jika orang-orang dengan latar belakang membuktikan jaminan concurrency meninjaunya, lalu pertanyaan diajukan ke steering committee setelah hal-hal yang belum diketahui setidaknya diidentifikasi. Di open source tidak banyak keputusan berskala manajemen program, dan sering kali keputusannya relatif sederhana yang mengarahkan pasar seperti Apache, Eclipse, dan Linux, tetapi kali ini ada ketidakpastian teknis yang nyata. Pada saat yang sama, saya merasa ABI antarbahasa juga harus ditangani. Masalah besarnya adalah menyesuaikan dengan model eksekusi yang diharapkan C; antarmuka foreign function dan memory Java sudah bertahun-tahun berada dalam inkubasi, dan wrapping C serta C++ di Swift juga membaik, tetapi FFI terkenal sulit dan mungkin juga sulit secara tidak perlu

  • Jika biaya yang dialihkan ke developer Python bisa diukur sebagai persentase PDB, maka manfaatnya juga demikian

• Secara pribadi, saya menganggap penghapusan GIL adalah kesalahan. Tidak banyak aplikasi yang akan mendapat manfaat besar, dan kebanyakan justru akan terkena penalti performa
  Pekerjaan ini akan menyita perhatian dan upaya selama bertahun-tahun, padahal rasanya bisa digunakan dengan lebih bijak. Python tampak seperti punya kecemasan atau rasa inferior terhadap GIL. Menurut saya, lebih baik menerima sepenuhnya model single-thread seperti JavaScript. Sebagian aplikasi akan tetap sulit atau mustahil, tetapi saya rasa Python bukan pilihan bagus untuk aplikasi yang membutuhkan performa tinggi atau skalabilitas tinggi. Menjadi agak terspesialisasi dan tidak mendukung semua use case bukan berarti buruk

  • Sudah terlalu terlambat untuk membatasi cakupan Python secara artifisial seperti itu. Python sudah banyak digunakan dalam data science dan machine learning
    Orang-orang membutuhkan performa untuk pekerjaan yang saat ini sudah mereka lakukan dengan Python. Kita tidak bisa kembali ke masa ketika itu belum benar. Kini itu adalah salah satu use case Python yang paling umum, dan orang-orang menggantungkan karier mereka pada bidang ini
  • PEP membahas motivasi dan keterbatasan model single-thread secara rinci: https://peps.python.org/pep-0703/#motivation
    Orang-orang sudah mencoba melakukan pekerjaan paralel dengan Python. Memaksa mereka memakai bahasa lain tidak banyak membantu
  • Di era ketika multiprosesor sudah umum selama lebih dari 10 tahun, kini saatnya menerimanya. Apalagi jika berkat para engineer interpreter yang hebat biayanya hampir tidak ada atau rendah; secara pribadi saya menyambutnya
  • Akan lebih baik kalau sejak awal sudah ada dukungan Unicode, tetapi apa boleh buat, semuanya sudah terlanjur seperti itu. Saya senang pekerjaan ini diambil
  • Saya selalu berpikir bahwa JIT yang kuat yang kompatibel dengan Cython dan juga cocok dengan proyek ekstensi C utama seperti numpy dan scipy akan menjadi upaya yang lebih bernilai
    Banyak pekerjaan intensif data bisa dijalankan dengan mudah sebagai proses paralel di Python, jadi saya tidak begitu yakin penghapusan GIL akan memberi manfaat sebesar itu

• Performa single-thread seharusnya lebih diprioritaskan karena jauh lebih sulit ditingkatkan hanya dengan menambah uang
  Performa multi-thread bisa menambahkan satu core lagi untuk mengimbangi overhead paralelisasi berbasis proses. Menurut saya, dikotomi GIL vs no-GIL itu sendiri keliru. Masalah terbesar pada multiprocessing adalah tidak bisa berbagi memori. Jadi yang perlu dilakukan adalah menambahkan proses virtual dengan mekanisme berbagi memori yang eksplisit. Dengan begitu objek tetap berada di satu thread, sehingga optimisasi single-thread seperti reference counting tanpa barrier bisa dipertahankan

  • Kesalahannya di sini adalah menganggap ini sebagai trade-off yang mendasar
    Performa single-thread tetap bisa bagus tanpa GIL. Rust memiliki konsep zero-cost abstraction dan juga menangani thread dengan baik. Java juga bagus untuk pekerjaan single-thread. Ada banyak bahasa lain juga, dan ini bukan fiksi ilmiah. Lock bisa dihilangkan lewat optimisasi, kita juga bisa memilih kode yang sama sekali tanpa lock, dan concurrency yang halus atau terstruktur juga dimungkinkan. Apa yang thread-safe pada dasarnya adalah kontrak API. Optimistic locking juga ada. Tidak ada alasan kuat mengapa Python tidak bisa melakukan hal serupa, tetapi GIL harus dihapus dulu. Penurunan performa Python tanpa GIL sebagian besar lebih mirip utang teknis yang belum diselesaikan dan bisa diperbaiki seiring waktu. Menambahkan banyak lock terasa seperti solusi sementara dan membuat lambat, tetapi solusi yang tepat kemungkinan adalah memikirkan ulang cara kerja internal atau memiliki kontrak API yang mendokumentasikan apakah sesuatu thread-safe. Runtime dan compiler Python yang lebih cepat juga dapat memungkinkan banyak hal yang saat ini bergantung pada library native untuk diimplementasikan ulang dalam Python. Interaksi dengan kode native justru merupakan area yang banyak membutuhkan lock, dan jika caranya tidak diubah, ini akan terus menjadi masalah. Inti dari penghapusan GIL adalah menemukan dan memperbaiki hal-hal seperti ini secara sistematis, dan akan membaik seiring waktu
  • Setuju. Jika sekarang membutuhkan concurrency, orang mungkin sudah pindah ke multiprocessing, jadi multi-threading no-GIL tidak terlalu berguna
    Satu-satunya masalah Python/multiprocessing adalah kadang yang dibutuhkan bukan queue, melainkan shared mutable state. Cara saat ini untuk menaruh objek Python di shared memory rumit, terbatas, dan tidak efisien. Itulah bagian yang perlu diperbaiki, dan Python membutuhkan dukungan yang lebih baik untuk menempatkan instance native di shared memory

• Untuk pertanyaan “seberapa besar penurunan performa yang dapat diterima pada kode single-thread”, Shannon memperkirakan sekitar 15–20%, tetapi pertanyaan itu pada umumnya belum terjawab
  Jadi apakah sebagian orang dalam proyek yang sedang membuat “CPython lebih cepat” menganggap dapat diterima jika sebagian besar kode Python yang ada menjadi 15–20% lebih lambat dalam semalam? Menurut saya batasnya sekitar 5% paling tinggi. Itu pun hanya jika penghapusan GIL membantu optimisasi lain di masa depan. Namun katanya perubahan itu justru membuat optimisasi lain lebih rumit dan tertunda. Di sisi lain, pada 2020 Shannon secara pribadi pernah mengajukan penggalangan dana untuk membuat CPython 5 kali lebih cepat, dan sekarang seluruh tim dengan dukungan perusahaan yang jauh lebih besar sedang mempercepat CPython, tetapi targetnya terlihat jauh lebih kecil

  • Sekitar 99% kode Python saat ini mungkin tidak terlalu peduli pada performa tinggi kode Python murni
    Ketika performa benar-benar penting, bisa mendapatkan peningkatan kecepatan sekitar 20 kali tanpa menulis ulang dalam bahasa lain adalah hal yang sangat berarti
  • Sebagian peningkatan performa terbaru berasal dari kubu no-GIL yang ingin menunjukkan bahwa masih ada ruang besar untuk perbaikan meski GIL dihapus
    Jika optimisasi lain bukan dihentikan, melainkan hanya memakan waktu sedikit lebih lama, itu mungkin masih bisa diterima
  • Menurut saya proyek Faster CPython terlalu dibesar-besarkan
    Jika membandingkan kode nyata yang melakukan operasi numerik dan string tanpa akses jaringan atau disk, beta 3.12 hanya membutuhkan waktu sekitar 20–25% lebih sedikit dibanding 3.8. Itu setara level 2.7. Orang-orang inti lama tampak seperti sedang mati-matian mencari fitur bullet point untuk ditunjukkan kepada sponsor perusahaan pada rilis berikutnya. Karena itu mereka memakai pekerjaan Sam Gross, tetapi seiring waktu tampaknya kreditnya perlahan akan mereka ambil

• Ringkasan yang sangat bagus, khas LWN
  Saya menyukai komunitas Python. Ini adalah contoh terdepan perangkat lunak open source, dan menunjukkan apa yang bisa dicapai oleh transparansi dan tata kelola yang baik. Waktu engineering yang diberikan Meta, Microsoft, dan lainnya memang patut disyukuri, tetapi dibandingkan nilai yang didapat seluruh industri teknologi dan bidang yang lebih luas termasuk data science dari Python dan perangkat lunak open source, itu masih terlalu kecil

  • Hal itu bisa diubah di dalam organisasi masing-masing
    Delapan tahun lalu di JPMorgan, saya meyakinkan tim kepemimpinan teknologi untuk mensponsori PyCon UK, membuka booth rekrutmen, dan mendukung kehadiran developer junior JPMorgan dari seluruh Inggris. Saya keluar dari JPM lima tahun lalu, tetapi mereka masih menjadi sponsor utama PyCon UK. Dibandingkan manfaat besar yang diperoleh dari ekosistem Python dan open source, biayanya benar-benar nyaris bisa diabaikan
  • Menurut saya mereka hanya berpura-pura transparan; keputusan sebenarnya semuanya dibuat di balik pintu tertutup
    Mailing list disensor, dan lingkaran dalam tidak bisa dikritik. Para kontributor sungguhan dieksploitasi oleh orang-orang yang berada di perusahaan yang tepat, tidak banyak melakukan apa pun, tetapi menduduki posisi kewenangan administratif. Artikel LWN sangat bersahabat dan selalu menyebut nama para pengambil keputusan, jadi jangan tertipu. Menurut saya itu lebih mirip peliputan selektif

• Cara Sam Gross mendorong ini cukup mengesankan. Setelah mendapat respons positif tetapi tanpa kepastian dari steering committee, ia bisa saja duduk diam menunggu kemajuan, tetapi fakta bahwa ia menentang dan menekan patut sangat diapresiasi

• Sangat menarik. Langkah Sam Gross yang mengatakan “memang tidak perlu yes/no sekarang juga, tetapi kita perlu tahu seperti apa bentuk penerimaannya, dan isu ini sudah terlalu lama dibiarkan” adalah manuver yang sangat berani: https://github.com/python/steering-council/issues/188#issuec...
  Interaksi itu bisa saja mengalir ke berbagai arah, tetapi tampaknya itulah dorongan yang tepat yang dibutuhkan Steering Council. Jalan menuju Python tanpa GIL masih panjang dan berliku, dan mungkin membutuhkan skala dua digit engineer-year, tetapi setidaknya kini tampaknya sudah ada jalur yang benar. Bagian tersulitnya adalah memastikan kebenaran codebase yang sudah ada. Mengatakan bahwa kita tidak ingin mengulang transisi dari Python 2 ke 3 adalah satu hal, tetapi benar-benar menghindari upgrade karena takut bug, meski diklaim tidak ada perubahan yang merusak kompatibilitas, adalah persoalan yang sama sekali berbeda. Menjadikan GIL/no-GIL hanya sebagai switch saat kompilasi pun jelas akan meningkatkan biaya pemeliharaan. Meski begitu, dalam jangka panjang saya rasa upaya ini akan sepadan. GIL adalah semacam penangkal petir bagi kritik terhadap Python, dan itu terlihat jelas dari thread HN tentang Python dan paralelisme. Mungkin karena orang bisa langsung menunjuknya sebagai “inilah alasan Python tidak bisa dibuat lebih cepat” tanpa perlu memahami konteks puluhan tahun. Dalam arti itu, ini mirip bos terakhir pagar Chesterton

  • Saya tidak melihatnya seoptimistis itu. Keputusan Steering Council terlihat ragu-ragu
    Bahkan di bawah panduan baru, masih ada kemungkinan upaya bertahun-tahun untuk menghapus GIL pada akhirnya ditolak