Pustaka NativeJIT milik Microsoft, yang awalnya dikembangkan oleh tim Bing untuk kompilasi just-in-time berkinerja tinggi, telah memicu diskusi signifikan dalam komunitas pengembang mengenai kondisi saat ini dan keterbatasan praktisnya. Meskipun pustaka open-source ini menjanjikan kompilasi cepat ekspresi menjadi kode x64 yang dioptimalkan, umpan balik komunitas terbaru mengungkapkan beberapa kekhawatiran tentang lintasan pengembangan dan implementasi teknisnya.
Fitur Utama:
- Pustaka kompilasi JIT lintas platform
- Tidak memiliki dependensi selain runtime C++ standar
- Alokasi register yang dioptimalkan
- Dukungan untuk operasi aritmatika/logika, kondisional, akses field struktur
- Kemampuan pemanggilan fungsi ke fungsi C
Kesenjangan Versi Internal vs Open Source
Kekhawatiran utama yang diangkat oleh para pengembang adalah ketidaksesuaian yang jelas antara versi internal Microsoft dan kode yang tersedia untuk publik. Anggota komunitas telah menemukan bahwa Bing menggunakan versi internal NativeJIT yang jauh lebih baik, namun peningkatan ini tidak digabungkan kembali ke dalam repositori GitHub. Hal ini menciptakan situasi yang membuat frustrasi di mana komunitas open-source tidak dapat memanfaatkan perbaikan dunia nyata yang telah dikembangkan Microsoft untuk penggunaan produksi.
Pertanyaan Kualitas Generasi Kode
Kemampuan generasi kode pustaka ini telah mendapat sorotan dari pengembang yang fokus pada performa. Analisis kode assembly yang dihasilkan mengungkapkan output yang tidak optimal, terutama mengenai operasi setup dan teardown stack frame yang tidak perlu yang biasanya akan dioptimalkan oleh kompiler modern. Hal ini menimbulkan pertanyaan apakah NativeJIT memberikan keuntungan yang berarti dibandingkan pendekatan tradisional seperti mengkompilasi kode dan menggunakan dynamic loading melalui fungsi dlopen atau LoadLibrary.
Perdebatan Desain API
Antarmuka pemrograman pustaka ini telah memicu perdebatan tentang kegunaan dan praktik C++ modern. Sementara NativeJIT mengharuskan pengembang membangun ekspresi menggunakan pemanggilan metode seperti expression.Mul(), beberapa anggota komunitas berargumen untuk dukungan operator overloading yang akan memungkinkan sintaks yang lebih alami mirip dengan pustaka seperti Eigen atau z3 milik Python. Hal ini akan memungkinkan pengembang menulis ekspresi menggunakan notasi matematika yang familiar daripada rantai metode yang bertele-tele.
Ya, tapi yang saya duga dimaksud oleh komentator adalah bahwa Anda dapat membangun ekspresi menggunakan operator overloading juga, jadi Anda dapat mengetik 'a + b', bukan 'a.Add(b)'
Determinisme dan Potensi Caching
Diskusi teknis yang menarik telah muncul seputar sifat deterministik dari generasi kode NativeJIT. Para pengembang mempertanyakan apakah memberikan pohon ekspresi yang identik ke kompiler menghasilkan output yang identik byte demi byte di beberapa kali menjalankan. Jika outputnya deterministik, hal ini dapat memungkinkan strategi memoization yang kuat di mana kode yang dikompilasi dapat di-cache dan digunakan kembali, secara signifikan meningkatkan performa untuk ekspresi yang berulang.
Solusi Alternatif dan Kompetisi
Diskusi komunitas telah menyoroti beberapa pendekatan dan alat yang bersaing dalam ruang kompilasi JIT. Para pengembang telah menyebutkan proyek ORC milik LLVM, Clang-REPL, dan libgccjit sebagai alternatif yang layak dipertimbangkan. Beberapa bahkan menyarankan bahwa bahasa dengan implementasi JIT yang matang, seperti HotSpot VM milik Java, mungkin lebih cocok untuk skenario yang memerlukan kompilasi dan optimisasi ekspresi runtime.
Meskipun NativeJIT mewakili pendekatan yang menarik untuk generasi kode runtime, umpan balik komunitas menunjukkan bahwa calon pengguna harus dengan hati-hati mengevaluasi apakah keterbatasan saat ini lebih besar daripada manfaatnya. Kesenjangan antara versi internal dan publik, dikombinasikan dengan kekhawatiran kualitas generasi kode, dapat mendorong pengembang menuju alternatif yang lebih matang sampai masalah-masalah ini diatasi.
Referensi: NativeJIT