Yazılım neden yavaş? Casey Muratori'ye göre performans sonradan eklenmiyor

Konuk kim?

Casey Muratori bir oyun geliştiricisi. Molly Rocket’ın kurucusu, bir oyunu sıfırdan yazdığı uzun soluklu Handmade Hero serisinin de yapımcısı. Computer, Enhance! adlı bültenini neredeyse tamamen yazılım performansına ayırıyor. The Pragmatic Engineer’dan Gergely Orosz ile yaptığı yaklaşık iki saatlik sohbetin ilk yarısı tek bir soru etrafında dönüyor: Hız bu kadar önemliyse neden herkes onu erteliyor?

“Hızlandırmaya gerek yok” bahaneleri

Casey 2023’te bu soruya bir yazıyla cevap vermişti. Duyduğu bahaneleri beş başlıkta topladı: “Donanım zaten hızlı”, “kazanç en fazla yüzde 5-10”, “parasal getirisi yok”, “sadece oyunlarda önemli” ve “sorun birkaç sıcak noktada, onları düzeltiriz”. Sonra her birini büyük şirketlerin kendi mühendislik yazılarıyla çürüttü. Örneğin Facebook 2020’de Messenger’ın iOS uygulamasını baştan yazdı. Uygulama yaklaşık dörtte bir boyuta indi, açılışı da iki kat hızlandı. Facebook’un Relay derleyicisi 2021’de yeniden yazıldı ve ortalamada yaklaşık 5 kat hızlandı. Casey’nin vurgusu şu: Bunlar küçük ayarlar değil, baştan yazmalar. Yani sorun “birkaç sıcak nokta” değildi.

Casey’ye göre işin garip yanı, bu kanıtları gösterdiğinde insanlar ona hak veriyor ama alışkanlıklar değişmiyor.

Tasarımda düşün, sonra değil

Bölümün ana fikri bu. Casey’ye göre performansı sona bırakırsan elinde düzeltebileceğin tek şey sıcak noktalar kalıyor. Yavaşlığın asıl sebebi mimarideyse, yani verinin nasıl dolaştığında, kaç katmandan geçtiğinde, profiler bunu tek bir satırda göstermiyor. O noktada tek çare yeniden yazmak oluyor. Bu yüzden sistemi baştan hızı hesaba katarak kurmayı öneriyor. Bunun iyi bir örneğini, milyon satırlık diff’leri tarayıcıda gösteren bir kütüphaneyi anlattığımız diffs yazısında görebilirsin.

“Clean code” eleştirisi de buradan geliyor. Casey 2023’te basit bir örnekle ölçmüştü: şekillerin alanını hesaplayan, sınıf hiyerarşisiyle yazılmış “temiz” bir kod. Aynı işi switch ile yazmak yaklaşık 1,5 kat, bir tabloyla yazmak 10 kattan fazla hız kazandırdı. Ona göre bu kurallar okunabilirlik için öğretiliyorsa bedelleri de söylenmeli.

Pratik olarak ne yapabilirsin?

• Assembly okumayı öğren, yazmayı değil. Casey’ye göre temel assembly’yi okumak için 20–30 komut yetiyor. Amaç, yazdığın kodun işlemcide neye dönüştüğünü görebilmek.
• İşlemcinin üç derdini bil. Verinin taşınması (önbellekler, yükleme ve yazma), komut akışı (dallanma tahmini) ve her işlem türünün ne kadar hızlı yürütüldüğü. Bu üçünü bilen biri bir kodun kabaca ne kadar hızlı çalışacağını tahmin edebiliyor.
• Önce sınırı hesapla. Klasik yol ölçmek, en yavaş yeri düzeltmek ve tekrar ölçmek. Casey’ye göre bu seni sadece yerel bir iyiye götürüyor. Tanıdığı en iyi optimizasyoncular önce donanımın o iş için teorik sınırını hesaplıyor, sonra o farkı kapatana kadar devam ediyor.

Casey bu işe “performance-aware programming” diyor. Amacı son damlayı sıkmak değil, ortalama yazılımı “korkunç verimsiz” olmaktan çıkarmak. Kendi tahminine göre bugün sıradan yazılımlar olabileceklerinden kat kat yavaş.

“Erken optimizasyon her kötülüğün anasıdır”

Bu söz performans tartışmalarında hep karşına çıkar. Kaynağı genelde Donald Knuth’un 1974 tarihli “Structured Programming with go to Statements” makalesi olarak gösteriliyor. Bağlamıyla okuyunca söylediği şey epey farklı. Knuth zamanın yaklaşık %97’sinde küçük verimlilikleri unutmamız gerektiğini, ama kritik %3’teki fırsatları kaçırmamamız gerektiğini yazıyor. Birkaç cümle önce de kolayca elde edilen %12’lik bir hızlanmanın yerleşik mühendislik dallarında asla önemsiz sayılmadığını söylüyor. Kritik kodun nerede olduğunu tahmin yerine ölçerek bulmayı öneriyor.

Casey’ye göre söz bugün genelde performansı hiç düşünmemenin bahanesi olarak kullanılıyor. Aynı gün yayımladığı “The Root of the Root of All Evil” konuşmasında da sözün hangi tartışmanın içinde doğduğunu tarihsel kaynaklarla takip ediyor.

Düşün

• Son yazdığın özellikte veri kaç katmandan geçiyor? Bunu bir profiler’da görebilir miydin?
• Bir işin donanımda en hızlı ne kadar sürebileceğini hiç kabaca hesapladın mı?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.