MSVC’de SPGO Neyi Değiştiriyor: PGO’nun Pratik Hali
Derleyici tarafında performans konuşulunca herkesin aklına aynı cümle geliyor: “Biraz hızlansın, ama build süreci de dağılıp kalmasın.” İşin aslı şu ki, klasik PGO yıllardır baya iş görüyor; buna lafım yok. Ama sahada, özellikle kurumsal ekiplerde, o gücü kullanmak için gereken üç aşamalı süreç bazen işi gereksiz uzatıyordu. Ben bunu ilk kez 2018’de bir finans müşterisinde net gördüm. Kod iyi gidiyordu, fakat profil toplama kısmı yüzünden CI hattı ağırlaşmıştı. Güzel fikir. Zor operasyon. Hani kağıt üstünde süper durur ya, pratikte bakalım ne çıkacak dediğiniz tipten.
Microsoft’un SPGO yaklaşımı tam burada ilginçleşiyor. Klasik enstrümantasyon yerine üretim benzeri gerçek koşullardan örnekleme alıyor;. Derleyiciye “şu fonksiyon sıcak, şu blok soğuk” bilgisini vermek için ayrı bir eğitim seremonisi kurmanız gerekmiyor. Bu bana 2021 yazında Ankara’da görüştüğüm bir savunma sanayi ekibini hatırlattı. Orada asıl dert sadece performans değildi; dert, performansı ölçmek için üretimden sapmadan veri toplayabilmekti. SPGO’nun vaat ettiği şey biraz bu: daha az uğraş, daha çok sinyal. Peki neden önemli? Çünkü bazı ekipler için asıl maliyet kodda değil, uğraşta çıkıyor.
Klasik PGO neden çoğu ekipte yarım kalıyor?
Klasik PGO’nun mantığı aslında oldukça temiz: önce probe ekle, sonra çalıştırıp veri topla, sonra yeniden derle. Optimize et. Düzgün akış gibi dürüyor. Ama gel gelelim gerçek hayatta bu üç adımın her biri ayrı sürpriz çıkarıyor. En çok da büyük ekiplerde build süreleri uzuyor, test ortamları yetmiyor, bir de üstüne “bu profile gerçekten güvenebilir mıyız?” sorusu geliyor.
Şimdi gelelim işin can alıcı noktasına.
Bence en büyük sorun teknik değil, organizasyonel. Küçük bir startup iseniz belki iki senaryo hazırlarsınız geçersiniz. Fakat enterprise yapıda ürünün onlarca kullanım modeli oluyor: bölge bazlı trafik farkı var, müşteri segmenti farklı davranıyor, gece çalışan batch işlerinin profili başka gündüz API trafiğinin başka (kendi tecrübem) — valla güzel iş çıkarmışlar —. Böyle olunca training workload seçmek başlı başına politika konusu oluyor. Şey yanı, teknik konu gibi başlayıp toplantı konusu hâline dönüyor (ciddiyim)
Bir de staleness meselesi var ki can sıkıcıdır. 2020’de İstanbul’da birlikte çalıştığım bir perakende projesinde bunu birebir yaşadık. İlk aldığımız profil gayet iyiydi ama altı hafta sonra yeni kampanya modülü devreye girince sıcak noktalar değişti. E peki, sonuç ne öldü? Yanı profil eskiyince iyileştirme da eskiyor; ayakkabının numarası küçük gelmeye başlıyor resmen.
Kısa bir not düşeyim buraya.
Enstrümantasyonun gizli maliyeti
İnsanlar çoğu zaman sadece runtime overhead’e bakıyor. Oysa asıl maliyet pipeline karmaşıklığında çıkıyor. Instrumented binary’yi ayrı sakla, training ortamını hazır tut, sonuçları versiyonla… E tabi bunların hepsi DevOps disiplinine uyacak diye ekstra uğraş demek. Bir yerde iş kolaylaşıyor gibi görünürken başka yerde dosya sayısı artıyor.
Araya gireyim: Açık konuşayım: bazı projelerde bu işin sonunda kimse profile dokunmuyor bile çünkü süreç fazla zahmetli geliyor (ki bu çoğu kişinin gözünden kaçıyor). Bir optimize etme tekniği kullanılmıyorsa bunun sebebi çoğu zaman “değer yok” değil; değer var ama erişim pahalı.
| Yaklaşım | Artısı | Eksiği |
|---|---|---|
| Klasik PGO | Daha hassas profil verisi verebiliyor | Enstrümantasyon ve eğitim süreci yorucu |
| SPGO | Üretim benzeri koşullardan düşük ek yükle veri alıyor | Sinyal kalitesi çalışma şekline bağlı kalıyor |
SPGO’nun sahadaki farkı ne?
SPGO, benim gözümde derleyici dünyasında “daha az törenle aynı sonuca yaklaşma” denemesi gibi dürüyor. Sampling tabanlı olduğu için gerçek çalışma anındaki davranışı yakalamaya odaklanıyor. Bunu yaparken sisteminizi probe yağmuruna boğmuyor. Bu önemli; çünkü bazı sistemlerde birkaç yüzde performans artışı bile ciddi para demek.
Nisan 2024’te İzmir’deki bir SaaS müşterisinde benzer mantıkla runtime verisi toplamıştık ama o zaman araç zinciri farklıydı ve elde ettiğimiz sinyal beklediğim kadar temiz değildi… Şunu özellikle söyleyeyim: sampling iyi çalışınca çok tatlı sonuç veriyor. Iş yükü dengeli değilse biraz gürültü de taşıyor (özellikle kısa ömürlü patlamalarda). Yanı mükemmel değil; fakat baya işe yarayan bir ara yol.
Bunu biraz açayım.
Performans optimize etmeunda en pahalı hata genelde yanlış veriyle doğru karar vermeye çalışmaktır.
Nerede parlıyor?
Bence SPGO’nun en iyi olduğu yerler uzun yaşayan servisler, yoğun request alan backend’ler ve belirgin hot path’i olan uygulamalar. Örneğin C++ ile yazılmış bir fiyatlama motoru düşünün; belli fonksiyonlar sürekli dönüyor ve call stack neredeyse ezberlenebilir hâle geliyor. İşte orada sampling gerçekten anlamlı sinyal üretiyor.
Dürüst olmak gerekirse, Ama kısa çalışan CLI araçlarında ya da anlık batch job’larda aynı etkiyi beklememek lazım. Çünkü örnekleme penceresi daraldıkça veri seyrekleşiyor. Burada biraz hayal kırıklığı yaşayabilirsiniz—ben yaşadım açıkçası—özellikle ilk denemede “neden beklediğim kadar fark görmedim?” dedirten durumlar öldü.
Türkiye’de kurumlar açısından ne ifade ediyor?
Aslında, Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo netleşiyor: performans ihtiyacı yüksek ama iyileştirme bütçesi sınırlı ekipler için SPGO baya mantıklı dürüyor. Kurumsal müşterilerimde gördüğüm kadarıyla bizim — ki bu tartışılır — pazarda sorun sadece teknoloji seçimi olmuyor; insan kaynağı da kilit oluyor. Yanı derleyicinin sunduğu özelliği anlayacak kişi sayısı sınırlıysa en güzel özellik bile rafta kalabiliyor.
Garip gelecek ama, Büyük yapılarda genelde şöyle ilerliyoruz: önce görünür faydayı gösteriyoruz, sonra yaygınlaştırıyoruz. Mesela tek bir kilit serviste SPGO açıp latency grafiğine bakarsanız yöneticiyi ikna etmek kolaylaşıyor. Fakat startup tarafında iş farklı; orada hız önemli olduğu için kimse altı haftalık tuning projesine sabır göstermiyor. Küçük ekipseniz basit başlayın, büyük kurumsal yapıdaysanız kontrol listesiyle gidin — ikisi aynı oyun değil.
- Kritik servis seçin
- Kullanıcı trafiğini temsil eden örnek alın
- Metrikleri öncesi/sonrası karşılaştırın (bu kritik)
Maliyet tarafını nasıl okumalı?
Açık konuşayım, Azure veya genel bulut harcaması düşünülünce performans kazanımı çoğu zaman doğrudan para tasarrufu demek oluyor. Bir sunucuyu %10-15 daha verimli kullanmak bazen yeni VM almak yerine mevcut kapasiteyle devam etmek anlamına gelir. TL bazında baktığınızda kur dalgalanması yüzünden bu fark küçümsenecek gibi değil.
Ne yalan söyleyeyim, Bence burada doğru soru “kaç puan hızlanırım?” değil; “bu hızlanma aylık faturaya ne getirir?” olmalı. Bir finans kuruluşunda yürüttüğümüz kapasite analizinde küçük görünen iyileştirme yıl sonu bütçesinde oldukça hissedilir olmuştu. Hani Excel’in son satırı vardır ya… tam orası!
Peki nasıl başlamalı?
Lafı gevelemeden söyleyeyim: ilk işiniz neredeyse tüm sistemi değiştirmek olmamalı. Önce tek bir modül seçin,sonra onun sıcak yollarını bulun,sonra build çıktısını kıyaslayın. Ben AZ-305 sınavına hazırlanırken de hep aynı refleksi kullandım; büyük resmî anlamadan detaya dalınca insan boğuluyor.
// Basit yaklaşım mantığı
1) Kritik C/C++ modülü seç
2) Gerçekçi workload ile örnekleme al
3) Öncesi/sonrası CPU time ve latency ölç
4) Kazanç varsa yaygınlaştır
5) Profil yaşlanmasını takvime bağla
Bi saniye — Şimdi gelelim pratik tarafa… Eğer ekibiniz küçükse benim önerim önce manuel gözlem + basit benchmark ile ilerlemek olur. Her şeyi otomasyona boğmaya gerek yok. Ama enterprise seviyede iseniz bunu CI/CD hattına kontrollü şekilde koymak gerekiyor; yoksa birkaç ay sonra kimse profil dosyasının nereden geldiğini hatırlamıyor bile (inanın bana). Sız ne dersiniz?
Şu ufak detaya bakın: tuzaklar
- Aynı workload’a aşırı güvenmeyin: Tek senaryodan çıkan profil genelleme yapmaz.
- Sadece ortalama süreye bakmayın: Tail latency bazen asıl hikâyeyi anlatır.
- Sürüm değişince yeniden ölçün: Kod hareket ettikçe sıcak noktalar da yer değiştirir.
- Ekip içi sahiplik belirleyin: Profil dosyasını kimin yöneteceği belli olsun.
Kendi notum: Bu özellik güzel mi? Evet, ama ham tarafları var!
Bana göre Microsoft burada doğru yönde ciddi bir adım atmış. MSVC tarafında zaten sağlam olan derleyici zekâsını biraz daha erişilebilir hâle getiriyorlar. Visual Studio 2022’den itibaren geniş erişilebilir olması da güzel haber. Fakat şunu saklamayayım:her ekibin hemen fayda görmesini beklemiyorum. Profil toplama yöntemi kolaylaşsa da yorumlama kısmı hâlâ uzmanlık istiyor.
Daha önce Logosoft’ta Windows tabanlı yüksek trafikli bir entegrasyon projesinde benzer optimizasyon denemeleri yaptığımızda asıl kazanç kod satırından çok mimarı kararlardan gelmişti. Bazen derleyici ayarı sizi kurtarır,bazen — itiraz edebilirsiniz tabi — de cache stratejiniz kötüyse hiçbir sihir işe yaramaz. Aslında — dur bir saniye,önce şunu söyleyeyim:performans işi hiç yalnızca compiler işi değildir,ama compiler elindeki kartlardan biri olarak fena hâlde önemli.
Eğer bugün bu konuya başlamak istiyorsanız benim tavsiyem şu:önce profil toplayabileceğiniz en temsilî production benzeri akışı bulun,sonra baseline alın,ardından SPGO sonucu ile kıyaslayın (ben de ilk duyduğumda şaşırmıştım). Azıcık düzen kurarsanız kazanım görünür hâle gelir.
Sıkça Sorulan Sorular
SPGO ile klasik PGO arasındaki temel fark ne?
Bir şey dikkatimi çekti: Klasik PGO hani probe’lar ekleyerek çalışıyor ve ayrıca eğitim koşuları istiyor. SPGO işe doğrudan üretime yakın binary üzerinden örnekleme yapıyor. Yanı operasyonel yük açısından bakınca SPGO açıkçası çok daha hafif kalıyor.
SPGO her uygulamada aynı faydayı verir mi?
Hayır, vermez. Mesela uzun yaşayan servislerde ya da belirgin hot path’i olan uygulamalarda etkisi gerçekten güçlü oluyor. İlginç, değil mi? Aslında kural basit: iş yükünüz iyi temsil ediliyorsa fayda büyür, edilmiyorsa beklentileri düşük tutmak lazım.
Küçük ekipler SPGO kullanmalı mı?
Evet, ama bence kademeli gitmek şart. Önce kritik bir modülde deneyin, sonucu görün, sonra genişletin. Tecrübeme göre topyekûn geçiş yapmak çoğu zaman gereksiz efor yaratıyor ve ekibi bunaltıyor.
Bunu CI/CD içine koymak zor mu?
Tamamen zor demem, ama dikkat istiyor. Profil toplama sıklığı, sürüm eşlemesi ve metrik takibi net tanımlanmazsa süreç çabuk karışıyor. Aslında iyi kurgulanmış bir pipeline ile yönetilebilir seviyede kalıyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder