MSVC Build Tools Haziran 2026 Önizleme: Sessiz Ama Derin İyileştirmeler
Açık konuşayım: MSVC tarafındaki preview güncellemeleri çoğu zaman benim de “bir bakıp geçeyim” dediğim listenin başında dürüyor. Çünkü release notları öyle teknik, öyle madde madde akıyor ki, normal bir geliştiricinin gözü bir süre sonra kayıyor (ilk duyduğumda inanamadım). Ama bu sefer 14.52 preview’ünü biraz daha dikkatli okudum — ve içinde gerçekten konuşmaya değer şeyler buldum. Yanı sadece “şu bug fix edildi” listesinin biraz üstü var burada.
- Vektör inşasında duplicate instruction’lardan sonra gereksiz insert operasyonları elenerek vector construction iyileştirildi.
- SSA Optimizer artık SVE (Scalable Vector Extension) tiplerini destekliyor.
- Bitfield instruction’larında (
BFI,BFXIL,UBFIZ,UBFX,SBFIZ,SBFX) immediate operand’ların genişliği daraltılarak daha kompakt kod üretiliyor. - Vector memory intrinsic’leri standart load/store operasyonlarına dönüştürülerek hedef benchmark’larda %2-3 iyileştirme sağlandı.
Küçük bir detay: %2-3 kulağa küçük gelebilir. Ama derleyici dünyasında bu rakamlar hiç fena değil (ki bu çoğu kişinin gözünden kaçıyor). Hele binary size küçülmesiyle birlikte gelirse — embedded. Mobile tarafında cache hit oranlarını bile etkileyen bir kazanıma dönüşebiliyor bu iş.
SVE desteği neden önemli?
SVE, ARM’ın değişken uzunluklu vektör mimarisi. Yanı sabit 128-bit ya da 256-bit vektör yerine, donanım hangi genişliği destekliyorsa ona göre çalışan kod yazabiliyorsunuz; güzel tarafı da bu zaten. SSA Optimizer’ın bunu artık doğru şekilde optimize edebilmesi, ARM64 üzerinde HPC ve sinyal işleme uygulamaları yazanların ilgisini çekecek türden bir gelişme. Neden önemli bu? Bizim coğrafyada bu tip iş yapan ekip az ama gelecekte özellikle savunma sanayii ve telekom tarafında ARM64’e ciddi yatırım göreceğiz gibi dürüyor, ona göre.
x64/x86 tarafında düzeltmeler — Bazıları gerçekten önemli
x64/x86 tarafında daha çok bug fix ağırlıklı bir liste var ama içlerinden biri baya kritik:
- Multi-byte copy propagation’da miscompile: Destination address capture edildiğinde yanlış kod üretiliyordu. Bu tehlikeli bir bug — sessiz sessiz yanlış sonuç üreten kod demek bu, compiler bug’larının en sevimsiz türü.
- Multiply’ları shift’e indirgerken overflow flag’lerin korunmaması sorunu giderildi.
- x86’da non-register destination’lı LEA kullanımında IÇE düzeltildi.
- Amd64’te SIMD C dosyaları derlerken IÇE düzeltildi.
- x86 için SSA Optimizer copy propagation tune edildi.
- x86’da 16-bit overflow intrinsic’lerinde codegen bug’ı giderildi.
Daha ilk maddeyi özellikle vurgulamak istiyorum. Eğer üretimde uzun süredir çalışan bir servisiniz varsa. “arada sırada garip davranıyor ama yeniden üretemiyoruz” diyorsanız, compiler bug ihtimalini de kenara atmayın derim açıkçası. Geliştiriciler genelde “bizim kodda hata vardır” diye düşünür — ki çoğu zaman öyledir —. Derleyicinin de yanılabildiğini unutmamak gerekiyor.
Optimizer iyileştirmeleri: Inliner akıllanıyor mu?
Şöyle söyleyeyim, Bence bu bölümün en dikkat çekici maddesi şu: inliner heuristics’e return value cost analysis eklendi. Yanı derleyici artık bir fonksiyonu inline etmeden önce dönüş değerinin maliyetini de hesaba katıyor; küçük görünüyor. Tam da böyle ayrıntılar performansı oynatıyor. Bakın, en çok da template ağırlıklı kodlarda bunun etkisini hissedebiliyorsunuz.
Daha ilginç olan başka bir nokta var: inliner’ın memory model’i, function pointer devirtualization mümkün olacak şekilde geliştirildi. Yanı bazı durumlarda virtual function call’ları statik olarak çözmek daha kolay hâle geliyor. C++ tarafında devirtualization yıllardır LLVM’in (Clang’ın) güçlü olduğu, MSVC’nın biraz geriden geldiği alanlardan biri sayılıyordu; bu adım o farkı biraz kapatmaya çalışıyor gibi dürüyor (ben de ilk duyduğumda şaşırmıştım)
Neyse uzatmayalım; diğer optimizer notları da şöyle:
| Iyileştirme | Etkisi | |
|---|---|---|
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| COROUTINE inlining assertion düzeltildi | ||
| >Coroutine inline assert fixi | ||
| >Constant type conversion folding (/fp:fast olmadan) | ||
| Loop unswitching + vectorization birleşim hatası düzeltildi | \ |
Sıkça Sorulan Sorular
MSVC Build Tools Preview’ü production’da kullanabilir mıyım?
Resmî olarak önerilmiyor. Preview, adından da belli olduğu gibi henüz tam stabil değil — bazı şeyler düzelirken yeni regresyonlar da çıkabiliyor. Bence production build’lerinizi stable kanal MSVC ile yapın, preview’ü ayrı bir CI pipeline’ında test ortamı olarak kullanın (buna dikkat edin). Açıkçası karışık kullanmak başınızı ağrıtır.
C++ modules’a geçmek için şimdi doğru zaman mı?
Yeni bir proje başlatıyorsanız ve bağımlılıklarınız modules’u destekliyorsa, evet — denemeye değer. Ama mevcut büyük bir kod tabanınız varsa, bence en azından 14.52’nın stable kanala düşmesini beklemenizi öneririm. Neden önemli bu? import std‘nın artık düzgün çalışıyor olması yanı önemli bir kilometre taşı, tecrübeme göre bu tür geçişlerde zamanlama çok şey değiştiriyor.
ARM64EC ile ARM64 arasındaki fark ne?
ARM64EC (Emulation Compatible), x64 binary’lerle aynı süreçte çalışabilen ARM64 kodu üretiyor. Yanı uygulamanızın bir kısmı native ARM64’te koşarken, x64 bağımlılıklarınız emülasyonla aynı process içinde devam edebiliyor. Bu özellikle eski kütüphaneleri kullanan uygulamaları ARM64’e taşırken çok değerli — aslında geçiş sürecini epey kolaylaştıran bir özellik.
Preview’ü kurduktan sonra eski stable’a nasıl dönerim?
Visual Studio Installer üzerinden Preview bileşenini kaldırman yeterli. Eğer PATH ve developer command prompt ayarlarını preview için değiştirdiysen, onları da geri almayı unutma. İki versiyon yan yana yaşayabiliyor, mesela benim tercihim de bu şekilde — kritik olan hangisinin aktif olduğunu doğru bilmek.
14.52 ne zaman stable’a düşer?
Microsoft net tarih vermiyor. Ama tipik döngüye bakarsak, preview’deki bir versiyon genelde 2-4 ay içinde stable’a iniyor. Tabi karşılaşılan regresyonlara göre bu süre uzayabiliyor. Stable’a düşme tarihi için Visual Studio release notlarını takip etmek en sağlıklısı — açıkçası başka güvenilir bir kaynak da yok.
Kaynaklar ve İleri Okuma
MSVC Build Tools Preview updates – June 2026 (Microsoft C++ Team Blog)
Microsoft C++ Language Conformance Tablosu
MSVC Build Tools Preview Kurulum. Konfigürasyon Rehberi
Garip gelecek ama, ARM64EC ABI Conventions (Microsoft Learn)
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.
4 comments