Kesalahpahaman Umum tentang Compiler

Kesalahpahaman tentang optimisasi compiler

• Optimisasi menghasilkan program yang optimal?
  • Tujuan compiler bukan menghasilkan program yang optimal, melainkan memperbaiki program yang telah disederhanakan.
  • Optimisasi ukuran kode mungkin dilakukan, tetapi optimisasi waktu eksekusi sulit karena sulit diukur, tidak adanya optimal substructure, dan ketidakakuratan model hardware.
  • Waktu eksekusi, tidak seperti ukuran kode, sulit diukur secara akurat, dipengaruhi banyak faktor, dan tidak memiliki optimal substructure. Misalnya, meskipun dua loop dioptimalkan secara terpisah, untuk mengoptimalkan seluruh program keduanya mungkin justru perlu digabungkan. Selain itu, optimisasi juga sulit karena tidak ada model yang akurat untuk hardware target kompilasi. Sebagai contoh, goSLP menghasilkan kode vektorisasi SLP yang dioptimalkan secara global, tetapi karena model hardware yang tidak akurat, program yang dihasilkan bukan hanya tidak optimal, bahkan bisa lebih lambat daripada LLVM.

Kesalahpahaman terkait prediksi cabang

• Bobot cabang digunakan oleh branch predictor CPU?
  • Pada arsitektur x86, compiler tidak menghasilkan branch hint.
  • Bobot cabang digunakan untuk penempatan blok kode oleh compiler. (contoh: jika sebuah cabang sangat mungkin diambil, blok target ditempatkan tepat di bawah blok saat ini untuk meningkatkan locality instruction cache)
  • Pada arsitektur Intel Redwood Cove terbaru, branch hint kembali menjadi relevan, tetapi dalam praktiknya compiler jarang menghasilkan hint semacam ini.

Kesalahpahaman tentang level optimisasi

• -O3 menghasilkan kode yang jauh lebih cepat daripada -O2?
  • Untuk Clang, perbedaan performa antara -O2 dan -O3 tidak besar, dan untuk GCC ada sedikit perbedaan karena -O2 pada GCC kurang agresif dibanding Clang.
  • -O3 hampir tidak mempertimbangkan ukuran kode, sehingga bisa memunculkan masalah instruction cache.
  • Sebaiknya pastikan lewat benchmarking.

Kesalahpahaman tentang interpreter Javascript dan compiler JIT

• Interpreter Javascript melakukan kompilasi JIT saat runtime karena tidak bisa tahu sebelumnya jalur mana yang hot?
  • Mengetahui hot path saja tidak cukup; informasi tipe juga dibutuhkan.
  • Informasi tipe hanya bisa diketahui saat runtime, sehingga compiler JIT mengompilasi kode pada saat runtime.

Kesalahpahaman tentang hubungan compiler dan interpreter

• Jika ada compiler, interpreter tidak diperlukan?
  • Untuk C/C++, interpreter memang tidak terlalu berguna, tetapi pada kasus seperti WebAssembly, interpreter dapat memberi keuntungan dalam kemudahan pengembangan dan penggunaan, debugging, serta keamanan.

Kesalahpahaman tentang tahap tengah compiler

• Tahap tengah (middle-end) bersifat independen dari target/platform?
  • Dalam LLVM, tahap tengah tidak sepenuhnya independen dari target/platform.

Kesalahpahaman tentang optimisasi locality data

• Compiler mengoptimalkan locality data?
  • Compiler mengoptimalkan locality instruction cache, tetapi hampir tidak mengoptimalkan locality data.
  • Optimisasi locality data memerlukan perubahan besar pada kode, dan compiler C/C++ tidak dapat melakukan perubahan seperti itu.
  • Untuk meningkatkan locality data, perlu menggunakan teknik seperti data-oriented design.

Kesalahpahaman tentang kecepatan kompilasi

• -O0 memberikan kompilasi yang cepat?
  • -O0 menghasilkan kode yang mudah di-debug dan dapat diprediksi, tetapi tidak selalu menjamin kompilasi yang cepat.
  • Secara umum -O0 lebih cepat daripada -O2, tetapi hal ini bisa berbeda tergantung skala proyek dan compilernya.
  • Untuk kompilasi cepat, bisa dipertimbangkan untuk melewati pipeline kompilasi standar (misalnya TinyCC) atau langsung menghasilkan LLVM IR.

Kesalahpahaman tentang kecepatan kompilasi template

• Template membuat kompilasi menjadi lambat?
  • Lambatnya kompilasi template C++ disebabkan oleh model kompilasi C++ itu sendiri.
  • Template itu sendiri tidak secara signifikan memperlambat kompilasi.
  • Pustaka standar Dlang, Phobos, menggunakan banyak template tetapi tetap dapat dikompilasi dengan cepat.

Kesalahpahaman tentang kegunaan separate compilation

• Separate compilation selalu bernilai?
  • Separate compilation dapat menyebabkan waktu linking menjadi lama.
  • Pada banyak proyek, unity build (memasukkan seluruh kode ke dalam satu file) memberikan performa yang lebih baik.
  • Unity build memberi keuntungan seperti optimisasi seluruh program, peningkatan kecepatan kompilasi, dan perbaikan log error.
  • Kasus di mana separate compilation lebih baik daripada unity build jarang terjadi.

Kesalahpahaman tentang link-time optimization (LTO)

• Mengapa link-time optimization (LTO) terjadi pada waktu linking?
  • LTO dilakukan untuk optimisasi seluruh program.
  • Secara teori lebih masuk akal melakukan optimisasi seluruh program di tahap tengah, tetapi karena masalah praktis pada build system C/C++ (sulit menemukan source file dan mengetahui relasi pemanggilan), hal ini dilakukan saat linking.
  • Karena linker dapat menemukan semua object file, compiler menyertakan representasi bahasa antara seperti LLVM IR ke dalam object file agar linker dapat mengaksesnya.

Kesalahpahaman tentang optimisasi inlining

• Inlining berguna terutama karena menghilangkan instruksi pemanggilan fungsi?
  • Menghilangkan instruksi pemanggilan fungsi memang bermanfaat, tetapi keuntungan terbesar dari inlining adalah memungkinkan optimisasi lain.
  • Inlining memungkinkan optimisasi antar fungsi.
  • Jika lewat inlining kode dari beberapa fungsi digabung menjadi satu fungsi, teknik optimisasi intrafungsi yang sudah ada dapat diterapkan.

Kesalahpahaman tentang peran keyword inline

• Apakah keyword inline berkaitan dengan optimisasi inlining?
  • Keyword inline di C++ awalnya digunakan sebagai hint untuk optimizer, tetapi sejak C++98 maknanya berubah menjadi “multiple definitions allowed”.
  • Pada LLVM, jika keyword inline ada maka atribut inlinehint ditambahkan dan threshold inlining dinaikkan, tetapi dampaknya tidak besar.
  • Jika ingin sebuah fungsi selalu di-inline, harus menggunakan specifier always_inline.

Kesalahpahaman tentang materi belajar compiler

• LLVM adalah compiler terbaik untuk dipelajari?
  • LLVM memang punya sisi edukatif, tetapi ia kompleks dan sangat besar karena mendukung beragam use case.
  • Untuk belajar pengembangan compiler, lebih baik lebih dulu melihat compiler yang lebih kecil dan sederhana seperti Go compiler, LDC, atau DMD.

Kesalahpahaman tentang undefined behavior

• Undefined behavior hanya memungkinkan optimisasi?

  • Undefined behavior juga bisa menonaktifkan optimisasi.

• Compiler bisa “begitu saja” mendefinisikan undefined behavior?

  • Compiler memang bisa mendefinisikan undefined behavior, tetapi hal itu dapat memengaruhi performa.
  • Akan ideal jika compiler mendefinisikan semua undefined behavior sesuai perilaku platform, tetapi secara realistis itu tidak mudah.

Kesalahpahaman tentang pembuatan kode berbasis AI

• Generasi kode dengan akurasi 99% itu sudah cukup baik?
  • Akurasi 99% pada kode yang dihasilkan compiler pada praktiknya sulit digunakan.
  • Kesalahan 1% dalam kode menimbulkan kesulitan besar dalam debugging dan maintenance.
  • Pada proyek skala besar, kesalahan 1% dapat menimbulkan masalah yang sangat serius.
  • Karena LLM saat ini jauh lebih lambat daripada compiler, mereka tidak cocok untuk generasi kode online.