Pengumuman Steering Council mengenai proyek JIT

• Kompiler JIT eksperimental CPython telah dikembangkan di branch main selama beberapa tahun dan baru-baru ini menunjukkan peningkatan kinerja yang nyata, tetapi untuk tetap menjadi fitur yang didukung masih memerlukan peninjauan PEP resmi
• PEP 744 membahas desain awal dan kriteria transisi menjadi fitur permanen, tetapi masih belum ada kesepakatan tentang pemelihara jangka panjang, tinjauan keamanan, dukungan debugging dan alat proses eksternal, jaminan runtime, serta kewajiban bagi redistributor dan downstream packager
• Python Steering Council secara resmi meminta penulisan Standards Track PEP untuk menjadikan JIT sebagai fitur CPython non-eksperimental yang didukung, dan meminta penghentian penggabungan fitur baru, optimisasi, dan pekerjaan performa ke main sampai PEP diterima
• PEP baru harus membahas pemeliharaan jangka panjang, kompatibilitas dengan fitur dan alat CPython yang ada, metrik keberhasilan yang terukur beserta jadwalnya, hubungan dengan JIT pihak ketiga seperti CinderX·Numba·PyTorch, serta stabilitas arsitektur saat ini
• Jika dalam 6 bulan PEP tidak diajukan, tidak diselesaikan, atau tidak diterima, maka kode JIT akan dihapus dari branch main dan pengembangannya harus dilanjutkan di luar repositori Python utama

---

Latar belakang dan permintaan resmi

• Kompiler Just-In-Time eksperimental CPython adalah pekerjaan yang telah dikembangkan di branch main selama beberapa tahun oleh sejumlah core developer dan kontributor, dan peningkatan performa terbaru merupakan hasil yang nyata dan menggembirakan
• Langkah ini bukan kritik terhadap pekerjaan JIT atau para pesertanya; karena proyek ini telah berjalan lama dan beberapa kali mengalami perancangan ulang, kini dinilai sebagai saat yang tepat untuk meninjau kembali status informal JIT di dalam proyek CPython
• JIT masuk ke main pertama kali sebagai eksperimen, dan PEP terkait, yaitu PEP 744, merupakan Informational PEP
• PEP 744 membahas desain awal dan secara garis besar membahas kriteria agar JIT bisa menjadi fitur permanen, tetapi masih membuka pertanyaan tentang pemelihara jangka panjang, tinjauan keamanan, dukungan debugging dan alat proses eksternal, jaminan runtime, serta kewajiban bagi redistributor dan downstream packager
• Python Steering Council menilai bahwa perubahan dengan tingkat kompleksitas dan cakupan seperti ini memerlukan proses yang lebih ketat, dan bahwa pertanyaan-pertanyaan yang belum terselesaikan tersebut adalah komitmen yang harus ditelaah dan disepakati komunitas melalui proses PEP
• Untuk menjadikan JIT sebagai fitur CPython non-eksperimental yang didukung, diperlukan Standards Track PEP yang juga membahas jaminan, komitmen pemeliharaan, serta dampak terhadap redistributor, diikuti proses penerimaan atau penolakan resmi oleh Steering Council setelah diskusi komunitas
• Sampai PEP tersebut diterima, pengembangan JIT baru tidak boleh digabungkan ke branch main; fitur baru, optimisasi, dan pekerjaan performa termasuk dalam cakupan penghentian ini
• Perbaikan bug dan perbaikan keamanan tetap dapat dilakukan, dan cakupan penghentian ini terbatas pada penambahan fitur JIT lebih lanjut sebelum PEP diterima

Isu yang harus dibahas PEP dan jadwal 6 bulan

• Tujuannya bukan untuk menuntut proposal yang saling bersaing, tetapi saat ini juga merupakan waktu yang baik untuk mendiskusikan usulan alternatif, dan hal ini sejalan dengan pandangan yang sudah ada bahwa eksperimen di branch main CPython tidak seharusnya dilakukan tanpa PEP
• Alih-alih mengusulkan satu implementasi JIT tunggal, bisa jadi lebih tepat jika PEP menjelaskan infrastruktur JIT yang dapat mendukung beberapa strategi implementasi
• Karena beberapa pendekatan tracing JIT yang menjanjikan terus diusulkan, infrastrukturnya sebaiknya tidak terikat kuat pada satu strategi, melainkan memungkinkan pendekatan seperti itu diuji dan dievaluasi dengan mudah di dalam CPython
• PEP harus menetapkan rencana yang jelas tentang bagaimana subsistem dengan skala dan kompleksitas seperti ini akan dipertahankan dan dipelihara dalam jangka panjang, serta dampaknya terhadap pemelihara dan kontributor yang tidak berkontribusi langsung ke JIT
• PEP harus membahas kompatibilitas dengan fitur dan alat CPython yang ada, serta mengulas secara luas dan rinci interaksi dan jaminan antara JIT dengan fitur seperti free-threading, profiler, dan debugger
• PEP harus mencakup metrik keberhasilan dan jadwal yang jelas serta terukur, termasuk target dan tenggat terkait sasaran performa, cakupan dukungan platform, dan overhead memori
• PEP harus membahas hubungan dengan kompiler JIT lain, termasuk apakah desainnya menyediakan infrastruktur umum yang bisa dijadikan dasar oleh upaya lain, dan apakah ia mengantisipasi kompatibilitas atau ketidakcocokan dengan JIT pihak ketiga seperti CinderX, Numba, dan PyTorch
• PEP harus membahas apakah arsitektur JIT saat ini dianggap stabil, atau justru masih besar kemungkinan akan berubah lebih lanjut
• Daftar ini bukan daftar lengkap, dan isu tambahan dapat muncul seiring berjalannya diskusi komunitas
• Ditetapkan periode 6 bulan untuk pengajuan dan penyelesaian PEP, dan jika dalam periode itu PEP terkait tidak diterima, kode JIT akan dihapus dari branch main dan pengembangannya harus dilanjutkan di luar repositori Python utama
• Persyaratan ini bukan penghentian proyek, melainkan prosedur untuk memberikan kejelasan dan komitmen eksplisit dari komunitas yang diperlukan bagi perubahan besar pada runtime CPython

[GN⁺]

Komentar Lobste.rs

• Tidak terlihat terlalu buruk, tetapi memang agak canggung. Jika JIT masih merupakan fitur eksperimental, kelanjutan penggabungan tampaknya bukan masalah besar.
  Jika orang seperti Shannon berkata, “Kami akan membawa PEP, tetapi tolong hindari benturan yang canggung,” rasanya mereka cukup bisa dipercaya sehingga tidak perlu diberi penguncian keras agar tak bisa melangkah lebih jauh. Mungkin pengumuman publik ini muncul setelah percakapan tertutup, tetapi semoga semuanya berjalan baik tanpa menimbulkan luka yang tidak perlu

• Usulan antarmuka yang memungkinkan implementasi JIT yang berbeda tampaknya sangat salah paham tentang apa yang dibutuhkan JIT berperforma tinggi. Para penggarap JIT mungkin punya banyak masalah, tetapi salah satu masalah besar tampaknya adalah mereka tidak bisa atau tidak mau banyak mengubah struktur data runtime inti.
  Tentu saja, Python juga punya masalah karena pada praktiknya mengekspos seluruh implementasinya seperti API. Meski begitu, jika seseorang berbuat hal buruk, kita masih bisa memaksa mereka menulis ulang tipe, tetapi untuk itu dibutuhkan komunitas yang benar-benar peduli pada performa. Secara historis, Python bertahan dengan cara tidak menulis library yang butuh performa tinggi dalam Python, dan itu memengaruhi prioritas. Saya masih ingat perbandingan performa bahasa di masa lalu yang membandingkan implementasi algoritme dasar dengan implementasi Python yang sebenarnya hanya membungkus implementasi C library yang sudah dipoles dan berperforma tinggi

  • Usulan antarmuka JIT tampaknya terinspirasi dari Ruby, dan kesannya di Ruby itu berjalan cukup baik. Jadi mungkin Ruby tidak punya JIT yang super tinggi performanya, tetapi mungkin itu sudah cukup baik. Sepertinya banyak orang akan puas jika JIT Python bekerja setidaknya sebaik JIT Ruby

  • Saya kurang paham mengapa pernyataan “usulan antarmuka yang memungkinkan implementasi JIT berbeda sangat salah paham tentang apa yang dibutuhkan JIT berperforma tinggi” benar adanya.
    Seperti yang dikatakan, memang ada situasi di mana Python mengekspos implementasinya seperti API, tetapi dengan alasan yang sama JIT juga memanggil API-API itu. Faktanya, beberapa fungsi bahkan diekspos ke linker sebagai simbol publik karena dibutuhkan JIT. Secara pribadi saya mengerjakan method JIT, bukan tracing JIT, dan selama ini secara terbuka mendukung gagasan JIT yang dapat dipasangkan sebagai plug-in

• Saya penasaran kenapa ini diposting sebagai pengumuman publik alih-alih dikirim sebagai permintaan tertutup kepada para pengembang JIT inti

  • Karena Python adalah proyek open source yang digerakkan komunitas. Bahkan di proyek berpemilik pun pengumuman serupa pernah bocor

• Rasanya perlu ada antropolog di suatu tempat yang menulis buku tentang birokrasi dalam proyek perangkat lunak open source, dan Python serta Debian seharusnya menjadi objek studi utama.
  Ini bukan celaan. Birokrasi seperti ini pada akhirnya adalah proses pengambilan keputusan terdistribusi dan pembentukan konsensus, dan membuatnya berjalan baik pada skala sebesar ini itu sulit

  • Gabriella Coleman adalah antropolog yang melakukan kerja lapangan pada Debian. Hasilnya adalah buku berjudul “Coding Freedom”, dan saya sangat merekomendasikannya

• Sejujurnya ini terlihat seperti sindrom yang mengarah ke Python 3, tetapi dengan efek yang berlawanan. CPython tampaknya terutama ada demi kesenangan para implementor, dan perubahan ini rasanya akan cukup merepotkan bagi orang-orang yang sudah terbiasa mengutak-atik dengan cara sekarang.
  Mungkin arah yang benar adalah mendukung versi JIT sebagai implementasi terpisah, membiarkannya menerima perubahan, sambil tetap mengupayakan kompatibilitas dengan CPython asli sebisa mungkin

  • Saya kurang paham maksud tepat dari ungkapan “seperti sindrom yang mengarah ke Python 3, tetapi dengan efek yang berlawanan”.
    Soal bagian “CPython terutama ada demi kesenangan para implementor,” kesan yang saya dapat dari interaksi terbatas dengan SC dan para pengembang inti justru kebalikannya. Secara umum, mereka tampak cukup berkomitmen untuk secara masuk akal menyeimbangkan dukungan berkelanjutan bagi komunitas yang ada sambil tetap bergerak maju