Terjemahan publikasi Titus Winters di Kelompok Kerja 21 (WG21) - C ++ Komite Standardisasi Bahasa. Penulis membahas masalah penting: dukungan untuk kompatibilitas mundur biner atau ABI (antarmuka biner aplikasi).
Selama beberapa tahun terakhir di WG21, saya secara aktif mempromosikan bahwa kemajuan lebih penting daripada kompatibilitas ke belakang. Tapi saya sendiri tidak lagi percaya akan hal ini, terutama yang berkaitan dengan menjaga kompatibilitas biner (ABI). Dalam tiga rilis terakhir (C ++ 14, C ++ 17 dan C ++ 20) ABI stabil seperti yang kami mampu. Bahkan jika WG21 memutuskan untuk memutus kompatibilitas ABI di C ++ 23, kami telah menyediakan kompatibilitas biner pada banyak platform selama lebih dari 10 tahun. Menurut pendapat saya, hukum Hyrum mendominasi perubahan besar-besaran sistem perangkat lunak. Sekarang Anda tidak dapat memberi tahu berapa banyak pengguna yang memiliki asumsi stabilitas perpustakaan standar ABI (tidak peduli seberapa bijak atau seberapa eksplisit atau implisit) dengan tegas "dijahit dalam subkorteks", mungkin setengah dari pengembang C ++ di dunia.
Saya menyimpan daftar apa yang bisa diperbaiki oleh WG21 dalam bahasa ini jika kami memutuskan untuk "memecahkan" ABI. Dan saya tidak bisa mengatakan dengan yakin bahwa total biaya pengerjaan ulang, yang akan memerlukan hanya penerapan daftar ini, sebanding dengan biaya pelanggaran ABI di seluruh ekosistem. Kami melihat banyak perbaikan kecil dalam konsistensi API, kualitas kode perpustakaan standar, dll., Tetapi tanpa keraguan tidak ada satu pun perubahan "terobosan" yang akan membenarkan biaya ini untuk pengembang rata-rata. Mungkin kita akan mendapatkan implementasi standar yang lebih baik, memberikan kesempatan untuk menyelesaikan masalah implementasi yang tidak memenuhi spesifikasi standar saat ini. Tetapi tidak ada satu perbaikan pun dalam daftar saya yang jelas sepadan dengan biayanya.
Lebih penting lagi, karena keterbatasan ABI, kami tidak dapat menghilangkan kerugian kinerja yang signifikan. Kami tidak dapat menghilangkan biaya signifikan mentransmisikan unique_ptr dengan nilai [Performa Chandler pada CppCon 2019, yang akan diterbitkan kemudian], kami tidak dapat mengubah std :: hash atau penempatan kelas dalam memori untuk unordered_map tanpa memaksa semua orang untuk mengkompilasi ulang semuanya di mana pun. Kinerja hash telah dipelajari secara ekstensif selama bertahun-tahun dan, dengan mempertimbangkan optimalisasi pencarian dalam tabel dan hashing yang tepat, kami yakin bahwa kami dapat menyediakan implementasi hash unordered_map / std :: hash yang kompatibel dengan API dan menyediakan peningkatan kinerja 200-300%. Tetapi pembatasan ABI tidak mengizinkan ini. Studi tambahan tentang pengoptimalan dan penyetelan SSO untuk std :: string menunjukkan peningkatan kinerja yang tidak sepele (1% dalam microbenchmark dan penskalaan) - API tidak terpengaruh, tetapi pembatasan ABI tidak mengizinkan hal ini.
Hilangnya total produktivitas yang diblokir secara eksklusif oleh ABI mencapai beberapa poin persentase - mungkin hingga 5-10%. Ini bukan sesuatu yang secara keseluruhan tidak dapat dilakukan ekosistem tanpa, tetapi mungkin tidak dapat diterima oleh beberapa organisasi (Google di antaranya). Ini, tentu saja, adalah kehilangan kinerja besar daripada yang dapat diterima untuk C ++: ingat bahwa ini adalah bahasa yang mengklaim bahwa ia tidak meninggalkan ruang untuk pesaing yang lebih produktif. Sebagian besar pengguna tampaknya tidak peduli dengan penurunan kinerja ini: ada implementasi tabel hash lainnya untuk mereka yang khawatir tentang kinerja absolut. Inefisiensi umum yang terkait dengan melewatkan unique_ptr dalam nilai dan masalah lain dari bahasa ABI mengemuka dalam sejumlah tugas yang sangat kecil. Organisasi yang membutuhkan produktivitas maksimum dapat berjalan sendiri (dan melakukannya), menggunakan perpustakaan non-standar dan alat konfigurasi non-standar. Ini wajar dan harus dipahami dengan jelas.
Perubahan ABI akan memengaruhi jumlah pengguna yang relatif lebih besar. Saya menduga sebagian besar pengguna ini tidak menduga seberapa kuat ketergantungan mereka pada ABI. Dalam ekosistem server Google, hampir semuanya dikumpulkan dari sumbernya, ada beberapa ketergantungan eksternal dan ada peluang yang lebih baik daripada rata-rata untuk melakukan refactoring skala besar. Tetapi bahkan bagi kami, perubahan ABI baru-baru ini pada perpustakaan standar menghabiskan biaya 5-10 tahun teknik.
Total biaya pemecahan kompatibilitas ABI untuk seluruh ekosistem C ++ dapat diperkirakan secara konservatif dalam " Millennium Engineer ": mengoordinasikan pembangunan kembali untuk setiap penyedia plug-in, .so atau dll di dunia akan membutuhkan sumber daya manusia yang sangat besar. Bersama dengan pemisahan ekosistem karena modul C ++ 20, mengubah ABI dalam waktu pengembangan dan implementasi C ++ 23 dapat menyebabkan pemisahan ekosistem yang keras.
Ada banyak pertanyaan yang tidak bisa dijawab dengan diskusi ini. Berapa lama kita bisa terus ke titik di mana mengubah ABI dari hanya berguna akan menjadi kebutuhan penting? Jika kita secara eksplisit memilih dukungan stabilitas ABI, seberapa mahal perubahan itu kapan dan kapan kebutuhan kritis seperti itu muncul? Jika masalah keamanan seperti Specter dan Meltdown memerlukan perubahan pada konvensi pemanggilan, berapa biaya C ++ untuk mengatasi tonggak sejarah ini? Berapa proporsi pengembang yang menggunakan C ++ karena kami mengklaim menempatkan kinerja di atas segalanya? Lebih buruk lagi: berapa lama C ++ mengklaim sebagai bahasa tercepat dan tidak harus melakukan optimasi seperti itu?
Jika kita secara sadar tidak dapat mengizinkan atau tidak ingin mengubah ABI, maka keputusan ini harus disuarakan dengan keras. Kita harus dengan jelas mengatakan bahwa ini adalah bahasa yang menempatkan stabilitas ABI di atas beberapa persen produktivitas terakhir. Saya bersedia berargumen bahwa dalam praktiknya ini telah terjadi selama beberapa tahun terakhir. Kami perlu memberi tahu pengguna apa yang diharapkan dari kami, dan memberi tahu mereka bahwa perpustakaan seperti Boost, Folly atau Absail diharapkan untuk membuat pilihan yang tepat jika kinerja diperlukan. Tapi ini tidak membantu dengan pembatasan terkait ABI dalam bahasa itu sendiri sebagai biaya pengiriman unique_ptr. Perpustakaan standar mempertahankan signifikansi dalam model pengembangan ini: perpustakaan standar adalah apa yang kami gunakan untuk kompatibilitas dan stabilitas. Ini mungkin memerlukan perubahan fokus dan arah pengembangan: kita mungkin ingin merancang lebih banyak fleksibilitas dalam kondisi yang berubah, dan bukan untuk kinerja "bersih".
Jika kami berpendapat bahwa produktivitas lebih penting daripada stabilitas ABI, kita harus segera memutuskan kapan tepatnya kita akan "mematahkan" kompatibilitas ke belakang dan melakukan segala yang mungkin agar ekosistem menerima perubahan seperti itu. Dan dengan jelas dan keras menyatakan bahwa kita akan pergi dengan cara ini. Anda perlu memahami bahwa semakin banyak waktu berlalu di antara perubahan seperti itu, semakin mahal jadinya - karena seiring waktu akan semakin banyak ketergantungan yang tidak didukung pada ABI. “Implementer” kami membuatnya sangat jelas bahwa perubahan yang merusak kompatibilitas C ++ 11 itu menyakitkan dan mahal. Keinginan untuk menghindari pengulangan biaya semacam itu adalah wajar, tetapi Anda harus memilih: apakah kami tidak mengulanginya, karena kami tidak mengubah ABI, atau membuat biayanya lebih murah.
Intinya, ada tiga kemungkinan untuk WG21:
- Memutuskan di mana rilis ABI akan diubah tidak masalah di C ++ 23 atau C ++ 26. Peringatkan orang dan segera kembangkan alat dan diagnostik untuk membantu mengidentifikasi tempat yang akan rusak. Berfokus pada praktik dan alat yang lebih konsisten untuk mendukung perubahan ABI di masa depan. Bukan kepentingan pelaksana tertentu untuk mengekspos penggunanya pada konsekuensi mengubah ABI, jika implementasi lain tidak, mengubah ABI harus menjadi kegiatan yang terkoordinasi untuk keuntungan pengguna di masa mendatang. Idealnya, Anda harus menghancurkan semuanya - untuk membuatnya jelas bahwa kode yang dikompilasi dalam mode C ++ 23 tidak kompatibel dengan kode yang dikompilasi dalam mode sebelumnya. Jika seseorang dapat melakukannya tanpa membangun kembali, dan orang lain akan memiliki kesalahan dalam tata letak atau pada waktu berjalan - ini hanya akan meningkatkan kesalahpahaman dan kekecewaan.
- Memutuskan bahwa kami mengupayakan stabilitas ABI dengan memformalkan praktik hari ini. Ini telah menjadi kasus selama bertahun-tahun ketika pelaksana standar memiliki hak untuk memveto perubahan ABI - kami telah menetapkan kompatibilitas ABI di atas kebersihan dan kinerja desain. Jika kami mengenali ini dan memberi tahu pengguna dengan jelas, ekosistem akan lebih baik. Nilai perpustakaan tambahan akan tumbuh bagi mereka yang perlu memeras tetes kinerja terakhir, tetapi tidak memerlukan stabilitas yang disediakan oleh standar. Bahasa berorientasi kinerja lain mungkin menantang posisi kami di masa depan.
- Tidak dapat memilih arah dan menyimpan status quo. Ini adalah skenario terburuk bagi saya: kami terus secara implisit lebih memperhatikan kompatibilitas ABI. Kami mengatakan "kinerja" dan memilih "kompatibilitas biner". Disonansi seperti itu membahayakan ekosistem dan menyiratkan kurangnya kesepakatan tentang prioritas bahasa. Saya dengan tulus berharap bahwa melalui upaya pelaksana dan Dirjen, kami akan mencapai konsensus yang diperlukan.
Saya percaya bahwa opsi No. 1 lebih cocok untuk pengguna yang membutuhkan kinerja maksimal, tetapi memiliki biaya yang luar biasa bagi ekosistem dan dapat menyebabkan fragmentasi bahasa di masa depan. Opsi nomor 2 adalah pilihan yang membosankan, bertanggung jawab, dan layak: menyedihkan untuk mengakui bahwa kita melukis diri kita sendiri di sudut ruangan dan mencoba meminimalkan kerugian yang terkait dengan ini. Memilih opsi No. 3 berarti tidak mengelola, dan saya berdoa semoga ini akan dihindari: setiap pilihan eksplisit lebih baik daripada disonansi saat ini dan ketidakmampuan untuk mencapai kesepakatan mengenai pilihan tujuan jangka panjang.
Saya mengerti bahwa kami telah mencapai posisi kami saat ini melalui banyak tindakan kecil yang tampaknya tidak masuk akal. Selama 10 tahun terakhir, tidak ada satu pun perubahan yang dibuat yang dapat membenarkan pelanggaran kompatibilitas biner, tetapi kebijakan implisit mempertahankan kompatibilitas mundur telah menjadi merusak bagi ekosistem. Namun, dengan mengadopsi kebijakan seperti itu secara eksplisit, kami akan membuka kemungkinan lain bagi C ++ untuk secara bertahap meninggalkan panggung: Anda tidak bisa menjadi bahasa yang berorientasi sistem, berorientasi pada kinerja, menyisakan begitu banyak ruang untuk bahasa yang lebih produktif. Secara teori, masing-masing vendor dapat memutuskan untuk "mematahkan" ABI dalam rilis apa pun di masa mendatang, tetapi arah pemikiran umum tampaknya berbeda. Saya yakin bahwa diskusi dan konsensus antara para pelaksana standar dan WG21 diperlukan: prioritas apa yang harus saya pilih?