Photoshop’ta MSVC ve SPGO ile %20 Hız Artışı: Nasıl Oldu?
Bakın, ben senelerdir Azure tarafında çalışan biri olarak compiler iyileştirmeu haberlerine genelde “iyi bari” deyip geçerdim. Ama bu Adobe-Microsoft işbirliği biraz daha dikkatimi çekti. Sebebi de şu: Photoshop gibi 30 yıllık, devasa bir C++ uygulamasında fırça gecikmesini %20 azaltmak — kulağa basit geliyor ama altında ciddi bir mühendislik var.
Vallahi, Avantajları şöyle sıralayayım:
- Production binary’sinden profil toplanıyor — yanı temsil ediciliği yüksek
- Build pipeline’da özel bir konfigürasyona gerek yok
- Sampling overhead’i çok düşük kalıyor; gerçek kullanıcı senaryoları rahatça çalışabiliyor
- Kaynak kodda değişiklik gerekmiyor; sadece compiler flag’leri yetiyor
Bir de tabi MSVC’nın peak-performance ayarlarının üstüne geliyor bu iş. Yanı /GL ile whole program optimization ve LTCG (link-time code generation) zaten açık olmalı. SPGO bunların üstüne binen ekstra bir katman gibi davranıyor. Adobe ekibi önce temel ayarların düzgün olduğundan emin olmuş, sonra SPGO’ya geçmiş; sıralama burada önemliymiş.
Peki MSVC Tarafında Nasıl Etkinleştiriliyor?
Araya gireyim: Genel akış kabaca şöyle ilerliyor. Tabiî Photoshop ölçeğinde her adımın içinde ayrı mühendislik var (buna dikkat edin). Mantığı görmek için aşağıdaki iskelet yeterli oluyor: (en azından benim deneyimim böyle)
# 1. Release build'i peak-performance flag'leriyle derle
cl /O2 /GL /Gw /Gy main.cpp
link /LTCG main.obj
# 2. Production binary'sini representative workload ile çalıştır
# ETW tabanlı sampling ile profil topla
xperf -on PROC_THREAD+LOADER+PROFILE
#... workload çalıştırılır...
xperf -d profile.etl
# 3. Profil verisini SPGO formatına dönüştür ve yeniden derle
cl /O2 /GL /Gw /Gy /GENPROFILE:PATH=profile.pgd main.cpp
link /LTCG /USEPROFILE:PGD=profile.pgd main.obj
Bu sadece kavramsal bir taslak — gerçek üretimde toolchain biraz daha karmaşık oluyor ama mantık aynı kalıyor. Ve dikkat edin: kod tek satır değişmedi; yalnızca derleyiciye “şu binary böyle çalışıyor, buna göre optimize et” dedik.
x64 vs ARM64 Farkı Niye Önemli?
Yanı, x64’te %20, ARM64’te %13 çıkmış olması ilk bakışta “neden ARM daha az kazandı?” sorusunu getiriyor olabilir. Aslında işin doğası biraz böyle ilerliyor; ARM64 mimarisi daha fazla register’a sahip ve instruction set’i daha düzenli olduğu için baseline’da zaten görece iyi kod üretiyor. x64 tarafında işe legacy mimariden gelen kısıtlar (az register meselesi, complex instruction encoding falan) iyileştirme için daha fazla manevra alanı bırakabiliyor.
ARM64 tarafında %13 bile az değil hani. Hele bir de — ki bu tartışılır — Surface Pro X ya da Copilot+ PC’ler gibi ARM tabanlı Windows cihazlarda Photoshop’un akıcı çalışması Microsoft açısından stratejik kalıyor. Bu cihazlar pil ömrü için optimize ediliyor ama performans yine kritik; SPGO burada hem hız hem de enerji verimliliği kazandırabiliyor çünkü daha az instruction çalıştırılıyor ve doğal olarak daha az enerji gidiyor.
Türkiye’deki C++ Ekipleri İçin Ne Anlama Geliyor?
Şimdi gelelim asıl soruya bence burada dönüp dolaşıp ona geliyoruz zaten Türkiye’de native C++ ile büyük masaüstü uygulaması geliştiren ekip sayısı çok fazla değil ama olanlar — finans tarafında risk hesaplama sistemleri, oyun stüdyoları, CAD/CAM yazılımları, medikal görüntüleme işleri — bu tarz iyileştirmelardan ciddi fayda görebilirler.
Performans-kritik uygulamalarda hâlâ alternatif yok gibi düşünün; web güzel tamam ama bazı işler var ki orada CPU’nun nefesi doğrudan hissediliyor.
Kurumsal C++ ekiplerinde gördüğüm en yaygın hata şu: MSVC’nın gelişmiş iyileştirme flag’lerini açmayı unutuyorlar ya da “build süremiz uzar” diye kapatıyorlar.
/GL. /LTCG kapalı bir release build’ınız varsa masada ciddi performans bırakıyorsunuz demektir.
SPGO’ya gelmeden önce şu temel kontrolü yapın:
| Flag | Ne Yapar? | Maliyet |
|---|---|---|
/O2 |
Hız için tam iyileştirme | Build süresi az artar |
/GL |
Whole program optimization | Build süresi belirgin artar |
/LTCG |
Link-time code generation | LInk süresi çok artar |
/Gw |
Optimize global data | Ihmal edilebilir |
/Gy |
Function-level linking | Ihmal edilebilir |
| SPGO | P rofile-driven optimization | P rofil toplama altyapısı gerekir |
Küçük ekipseniz — diyelim 5-10 kişilik bir oyun stüdyosu — SPGO’ya hemen atlamayın.
Önce /O2 /GL /LTCG kombinasyonunu doğru yapılandırın.
Bu bile birçok projede %5-10 kazandırabiliyor.
Enterprise seviyede ve büyük binary’lere sahip projelerdeyse SPGO için yatırım yapmaya değer oluyor.
representative workload seçimi sonucun kalitesini doğrudan belirliyor.
Yanı sadece “uygulamayı beş dakika açık tut” yetmiyor;
gerçek kullanıcı senaryolarını otomatize etmeniz gerekiyor.
Yoksa ölçüm var gibi görünür ama elde kalan şey biraz zayıf olur.
SPGO’nun Görünmeyen Maliyeti
Açık konuşayım:
SPGO bedava değil.
Profil toplama altyapısı kurmak gerekiyor.
Yanı sadece compiler flag açıp bitmiyor.
Şunları planlamanız lazım:
- [ ] Representative workload üretmek için otomasyon
Kullanıcı senaryolarını UI seviyesinde simüle eden test suite’leri gerekir;
- [ ] ETW veya benzeri sampling profiler entegrasyonu
CI/CD pipeline’a sokulması gerekir;
- [ ] Profil verisinin versiyonlanması
Kod değiştikçe profilin de güncellenmesi gerekir;
- [ ] İki aşamalı build pipeline
Önce baseline build,
sonra profil ile rebuild gerekir;
Bütün bunlar küçük ekip için fazla olabilir.
Ama Photoshop ölçeğinde bir ürününüz varsa bu yatırımın geri dönüşü hızlı olur;
%1 performans artışı bile milyonlarca kullanıcıda toplamda devasa enerji ve zaman tasarrufu demek olabilir.
Bu arada konu MSVC olunca,
eğer build toolchain’inizle ilgili güncellemeleri de takip ediyorsanız MSVC Build Tools Haziran 2026 Önizleme: Sessiz Ama Derin İyileştirmeler
yazımdaki değişikliklere de göz atmanızı öneririm.
Orada da benzer
“sessiz ama etkili”
iyileştirmeler vardı.
GPU Varken CPU Optimizasyonu Hâlâ Önemli mi?
Birinin
”
günümüzde her şey GPU’ya kayıyor, CPU optimize etmeu eski moda”
diyeceğini duyar gibiyim.
Yanılıyorsun.
Photoshop örneği tam da bunu gösteriyor.
Evet, image processing filtreleri büyük oranda GPU’ya taşındı.
Ama kullanıcının latency hissettiği yerler
— fırça anlık tepkisi, dosya açma, UI responsiveness
— hâlâ CPU’ya bağlı.
Çünkü bu işlemlerin GPU’ya gitme overhead’i, işlemin kendisinden büyük olabiliyor.
Bence bu önemli bir ders.
AI ve GPU coşkusu içinde
”
CPU artık önemli değil”
gibi bir algı oluşuyor.
Halbuki uygulamanızın kullanıcıya hissettirdiği gecikmenin çoğu hâlâ CPU tarafında kalıyor. Hot path’leriniz hangi tarafta işe oraya yatırım yapacaksınız. Profil olmadan bunu bilemezsiniz. SPGO bu yüzden değerli — varsayım yapmıyor, ölçüyor.
Eleştirim : Daha Kolay Olabilirdi
Adobe-Microsoft hikâyesi güzel ama dürüst olalım :
SPGO’nun setup’ı hâlâ küçük ekipler için yorucu.
Microsoft’un bu konuda daha hazır şablonlar,
Visual Studio entegrasyonu sunmasını isterdim.
Linux tarafında AutoFDO benzer yaklaşımıyla zaten yıllardır var ve toolchain’i biraz daha olgun dürüyor.
MSVC tarafında SPGO yeni kapı açıyor ama hâlâ “advanced users only” hissi veriyor.
Umarım önümüzdeki sürümlerde bu olgunlaşır. Çünkü potansiyeli büyük.
Eğer Visual Studio’da tek checkbox ile açılabilir hâle gelirse çok daha fazla ekip faydalanır.
Şu anki hâliyle biraz “elit kulüp” gibi dürüyor.
Geliştirici verimliliği açısından da bakacak olursak,
Visual Studio’dan Çıkmadan Pull Request İncelemek : Artık Daha Rahat
yazımda da değindiğim gibi,
Microsoft son dönemde IDE deneyimine baya yatırım yapıyor.
SP GO’nun da bu yolculuğa en kısa zamanda katılması lazım.
Sıkça Sorulan Sorular
SPGO ile klasik PGO arasında ne fark var?
Klasik PGO’da özel bir instrumented binary derliyorsunuz, sonra o binary’yi çalıştırarak profil topluyorsunuz (buna dikkat edin). SPGO işe normal release binary’nizden sampling yaparak profil topluyor. Yanı aslında SPGO çok daha düşük overhead’e sahip — production ortamında çalışabiliyor ve build pipeline’a entegre etmesi de çok daha kolay.
Küçük projeler için SPGO kullanmak mantıklı mı?
Açıkçası, Açıkçası, genelde hayır. Projeniz birkaç on bin satırın altındaysa önce /O2 /GL /LTCG gibi temel iyileştirme flag’lerini deneyin. Hani profil toplama, representative workload otomasyonu, iki aşamalı build derken SPGO’nun getirdiği ekstra altyapı maliyeti küçük projelerde ROI’yi ciddi anlamda bozuyor.
Her uygulamada %20 performans artışı bekleyebilir mıyım?
Net bir şekilde hayır. Photoshop’taki %20 rakamı biraz özel bir durum — hem devasa bir kod tabanı var hem de CPU-bound hot path’ler çok yoğun. Bence bu rakamı baz almak yanıltıcı olabilir. Mesela GPU ağırlıklı çalışan (belki yanılıyorum ama) uygulamalarda kazanım çok daha düşük kalabiliyor. Genel beklenti %5-15 aralığında, ama profil olmadan tahmin yapmak gerçekten riskli — dürüst olayım, biraz hayal kırıklığı —
SPGO için Visual Studio 2026 şart mı?
SPGO desteği MSVC’nın son sürümlerinde mevcut. Tecrübeme göre flag’ler. Workflow sürümler arasında değişebildiğinden, tam toolchain detayları için Microsoft’un resmî dokümantasyonunu takip etmenizi öneririm.
Photoshop’un ARM64 sürümünde kazanım neden daha az öldü?
İlginç olan şu ki, ARM64 mimarisi zaten daha fazla register sunuyor. Instruction set’i daha düzenli — bu yüzden baseline kod kalitesi baştan daha yüksek. x64 mimarisinde işe optimizasyon için çok daha fazla manevra alanı kalıyor. Yanı aslında %13 ARM64 kazanımı hiç de kötü değil bence — bu rakam, baseline’ın. Oldukça iyi olduğunu gösteriyor.
Kaynaklar ve İleri Okuma
Ne yalan söyleyeyim, Microsoft C++ Team Blog: Boosting Adobe Photoshop’s Performance with MSVC and SPGO
Microsoft Learn: Profile-Guided Optimizations Resmî Dokümantasyonu
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.
3 comments