Yaygın derleyici yanlış anlamaları

Derleyici optimizasyonlarıyla ilgili yanlış anlamalar

• Optimizasyon en iyi programı üretir mi?
  • Derleyiciler en iyi programı üretmeyi değil, basitleştirilmiş programı iyileştirmeyi hedefler.
  • Kod boyutu optimizasyonu mümkün olsa da çalışma süresi optimizasyonu; ölçüm zorluğu, optimal alt yapı eksikliği ve donanım modelinin doğruluğundaki sorunlar nedeniyle zordur.
  • Çalışma süresi, kod boyutunun aksine kesin olarak ölçülmesi zordur; birçok etkene bağlıdır ve optimal alt yapı özelliğine sahip değildir. Örneğin iki döngüyü ayrı ayrı optimize etseniz bile, tüm programı optimize etmek için bu iki döngünün birleştirilmesi gerekebilir. Ayrıca hedef donanıma dair doğru bir model olmadığı için optimizasyon zordur. Örneğin goSLP, küresel olarak optimize edilmiş SLP vektörleştirme kodu üretir; ancak donanım modeli doğru olmadığından ortaya çıkan program yalnızca optimal olmamakla kalmaz, LLVM'den daha yavaş bile olabilir.

Dallanma tahminiyle ilgili yanlış anlamalar

• Dallanma ağırlıkları CPU'nun dallanma tahmincisinde mi kullanılır?
  • x86 mimarisinde derleyiciler dallanma ipuçları üretmez.
  • Dallanma ağırlıkları, derleyicinin kod bloklarını yerleştirmesinde kullanılır. (Örn. bir dallanmanın olasılığı yüksekse, komut önbelleği yerelliğini artırmak için hedef blok mevcut bloğun hemen altına yerleştirilir.)
  • Son Intel Redwood Cove mimarisinde dallanma ipuçları yeniden önem kazanmış olsa da, derleyicilerin bu tür ipuçlarını gerçekten üretmesi nadirdir.

Optimizasyon seviyeleriyle ilgili yanlış anlamalar

• -O3, -O2'ye göre çok daha hızlı kod mu üretir?
  • Clang için -O2 ile -O3 arasındaki performans farkı büyük değildir; GCC tarafında ise -O2, Clang'e göre daha az agresif olduğundan küçük bir fark olabilir.
  • -O3, kod boyutunu neredeyse hiç dikkate almadığı için komut önbelleği sorunlarına yol açabilir.
  • Bunu benchmark ile doğrulamak en iyisidir.

Javascript yorumlayıcıları ve JIT derleyicilerle ilgili yanlış anlamalar

• Javascript yorumlayıcıları çalışma zamanında JIT derleme yapar çünkü hangi yolun hot olduğunu önceden bilemezler mi?
  • Yalnızca hot path'leri bilmek yeterli değildir; tür bilgisi de gerekir.
  • Tür bilgisi ancak çalışma zamanında bilinebildiği için JIT derleyiciler kodu çalışma zamanında derler.

Derleyici ve yorumlayıcı ilişkisiyle ilgili yanlış anlamalar

• Derleyici varsa yorumlayıcıya gerek yok mudur?
  • C/C++ için yorumlayıcı çok yararlı olmayabilir; ancak WebAssembly gibi durumlarda yorumlayıcılar geliştirme ve kullanım kolaylığı, debug ve güvenlik gibi avantajlar sağlayabilir.

Derleyicinin middle-end aşamasıyla ilgili yanlış anlamalar

• Middle-end hedefe/platforma bağımsız mıdır?
  • LLVM'de middle-end, hedef/platformdan tamamen bağımsız değildir.

Veri yerelliği optimizasyonuyla ilgili yanlış anlamalar

• Derleyiciler veri yerelliğini optimize eder mi?
  • Derleyiciler komut önbelleği yerelliğini optimize eder, ancak veri yerelliğini neredeyse hiç optimize etmez.
  • Veri yerelliği optimizasyonu kodda büyük ölçekli değişiklikler gerektirir ve C/C++ derleyicileri bu tür değişiklikleri yapamaz.
  • Veri yerelliğini iyileştirmek için data-oriented design gibi teknikler kullanılmalıdır.

Derleme hızıyla ilgili yanlış anlamalar

• -O0 hızlı derleme sağlar mı?
  • -O0, debug edilebilir ve öngörülebilir kod üretir; ancak her zaman hızlı derlemeyi garanti etmez.
  • Genel olarak -O0, -O2'den daha hızlıdır; ancak bu proje ölçeğine ve derleyiciye göre değişebilir.
  • Hızlı derleme için standart derleme hattını atlamak (örn. TinyCC) ya da doğrudan LLVM IR üretmek düşünülebilir.

Template derleme hızıyla ilgili yanlış anlamalar

• Template'ler derlemeyi yavaşlatır mı?
  • C++ template'lerinin derlemeyi yavaşlatmasının nedeni C++'ın derleme modelidir.
  • Template'lerin kendisi derleme hızını büyük ölçüde düşürmez.
  • Dlang'in standart kütüphanesi Phobos çok sayıda template kullanmasına rağmen hızlı derlenir.

Ayrı derlemenin faydasıyla ilgili yanlış anlamalar

• Ayrı derleme her zaman değerli midir?
  • Ayrı derlemede link süresi uzun olabilir.
  • Birçok projede unity build (tüm kodun tek bir dosyada birleştirilmesi) daha iyi performans sunar.
  • Unity build; tüm program optimizasyonu, daha hızlı derleme ve daha iyi hata logları gibi avantajlar sağlar.
  • Ayrı derlemenin unity build'den daha iyi olduğu durumlar nadirdir.

Link-time optimization (LTO) ile ilgili yanlış anlamalar

• Link-time optimization (LTO) neden link aşamasında yapılır?
  • LTO, tüm program optimizasyonu için uygulanır.
  • Teoride tüm program optimizasyonunu middle-end aşamasında yapmak daha mantıklı görünse de, C/C++ build sistemlerinin pratik sorunları (kaynak dosyaları bulmanın ve çağrı ilişkilerini çıkarmanın zorluğu) nedeniyle bu işlem link aşamasında yapılır.
  • Linker tüm object file'ları bulabildiği için derleyici, linker'ın erişebilmesi amacıyla object file'ların içine LLVM IR gibi ara dil temsillerini koyar.

Inlining optimizasyonuyla ilgili yanlış anlamalar

• Inlining esas olarak fonksiyon çağrısı komutunu kaldırdığı için mi faydalıdır?
  • Fonksiyon çağrısı komutunu kaldırmak bir avantajdır; ancak inlining'in en büyük faydası başka optimizasyonların önünü açmasıdır.
  • Inlining, fonksiyonlar arası optimizasyonu mümkün kılar.
  • Inlining sayesinde birden fazla fonksiyonun kodu tek bir fonksiyonda birleştiğinde, mevcut fonksiyon içi optimizasyon teknikleri uygulanabilir.

inline anahtar sözcüğünün rolüyle ilgili yanlış anlamalar

• inline anahtar sözcüğü inlining optimizasyonuyla ilişkili midir?
  • C++'ta inline anahtar sözcüğü başlangıçta optimize ediciye ipucu vermek için kullanılıyordu; ancak C++98'den sonra "birden fazla tanıma izin verilir" anlamına geldi.
  • LLVM'de inline anahtar sözcüğü varsa inlinehint özniteliği eklenir ve inlining eşiği yükseltilir; ancak etkisi büyük değildir.
  • Bir fonksiyonu her zaman inline etmek için always_inline belirteci kullanılmalıdır.

Derleyici öğrenme kaynaklarıyla ilgili yanlış anlamalar

• LLVM öğrenmek için en iyi derleyici midir?
  • LLVM eğitsel yönler taşısa da, çok çeşitli kullanım senaryolarını desteklediği için karmaşık ve çok geniş kapsamlıdır.
  • Derleyici geliştirmeyi öğrenmek için önce Go derleyicisi, LDC, DMD gibi daha küçük ve daha basit derleyicilere bakmak daha iyidir.

Tanımsız davranış (Undefined Behavior) ile ilgili yanlış anlamalar

• Tanımsız davranış yalnızca optimizasyonu mümkün mü kılar?

  • Tanımsız davranış optimizasyonu devre dışı da bırakabilir.

• Derleyiciler tanımsız davranışı "sadece" tanımlayabilir mi?

  • Derleyiciler tanımsız davranışı tanımlayabilir; ancak bu performansı etkileyebilir.
  • Bir derleyicinin tüm tanımsız davranışları platform davranışı olarak tanımlaması ideal olurdu; ancak bunu pratikte yapmak kolay değildir.

Yapay zeka tabanlı kod üretimiyle ilgili yanlış anlamalar

• %99 doğrulukta kod üretimi yeterince iyi midir?
  • Derleyicilerde üretilen kod için %99 doğruluk gerçekte kullanımı zor bir seviyedir.
  • Koddaki %1 hata, debug ve bakım açısından büyük zorluklar doğurur.
  • Büyük ölçekli projelerde %1 hata çok ciddi sorunlara yol açabilir.
  • Mevcut LLM'ler derleyicilere kıyasla çok yavaş olduğundan çevrimiçi kod üretimi için uygun değildir.