Soru, C++20 öncesi döneme dayanıyor; bu dönemde geliştiriciler, döngüleri bellek tamponları üzerinde vektörleştirmek için __builtin_assume_aligned (GCC/Clang) veya __assume_aligned (MSVC) gibi derleyiciye özgü içsel işlevlere dayanıyordu. C++20, bir işaretçinin tür sisteminin garanti ettiğinden daha katı bir hizalama sözleşmesini karşıladığını derleyiciye bildirmek için taşınabilir bir mekanizma sağlamak amacıyla <memory> içinde bu yeteneği standartlaştırdı. Bu, std::malloc, ağ tamponları veya hizalanmış (örneğin, önbellek satırları veya SIMD kayıt genişlikleri ile hizalanmış) DMA bölgelerinden gelen ham belleği işlerken karşılaşılan performans açığını giderir; ancak derleyici bunları yalnızca byte-hizalı void* işaretçileri olarak algıladı.
Problem, derleyici ihtiyatının üzerinedir: hizalama hakkında açık bir bilgi olmadan, optimize edici hizalanmamış yükleme/depolama talimatları (örneğin, x86-64 üzerinde movups) üretmek zorundadır veya donanım tuzaklarını önlemek için vektörleştirmeden tamamen kaçınmalıdır. Bu, özellikle maksimum verimlilik için katı hizalama gerektiren AVX-512 veya NEON işlemleri için altoptimal kod üretimi ile sonuçlanır. Derleyici, dış depolama ile türetilen bir işaretçinin 64 byte hizalı olduğunu statik olarak kanıtlayamaz, uygulama mantığı bunu garanti etse bile.
Çözüm, [[nodiscard]] constexpr bir işlev olan std::assume_aligned<N>(ptr) dir; bu işlev ptr değerini değiştirmeden geri döndürür, ancak derleyicinin ara temsilinde bir hizalama varsayımı ekler. Bu sözleşme, optimize ediciye hizalanmış SIMD talimatlarını (örneğin, vmovdqa) yayma ve adresin N modülünde sıfır olduğuna dair garantiye dayanarak bellek işlemlerini yeniden düzenleme izni verir. Eğer programcı bu sözleşmeyi ihlal ederse—gerçekte N byte hizalı olmayan bir işaretçi geçirirse—program, ARM veya SPARC gibi sıkı RISC mimarilerinde SIGBUS olarak tezahür eden veya x86-64 üzerinde sessiz veri bozulmasına yol açan tanımsız bir davranış sergiler.
#include <memory> #include <immintrin.h> void scale_aligned(float* data) { // Programcı 32 byte hizalama (AVX gereksinimi) varsayıyor auto* ptr = std::assume_aligned<32>(data); // Derleyici vmovaps (hizalanmış yükleme) talimatını çalışma zamanı kontrolleri olmadan üretir __m256 vec = _mm256_load_ps(ptr); vec = _mm256_mul_ps(vec, _mm256_set1_ps(2.0f)); _mm256_store_ps(ptr, vec); }
Problem tanımı, bir çekirdek-atlatma ağ sürücüsünden sabit genişlikte piyasa verisi kayıtlarını işleyen bir yüksek frekanslı ticaret (HFT) sistemi içeriyordu. Sürücü, gelen tamponların sayfa hizalı (4KB) olduğunu garanti ediyordu; bu, AVX-512 ayrıştırması için gerekli 64 byte hizalamayı ima ediyordu. Ancak, API bu tamponları std::byte* olarak açığa çıkarıyordu. Hizalama bilgisi olmadan, derleyici ihtiyatlı hizalanmamış taşıma talimatlarını (vmovdqu8) üretti, bu da kritik yolun her paket için 120 nanosekondan fazla sürmesine neden oldu, bu da 80ns gecikme bütçesini aşıyordu.
Düşünülen çözümlerden biri, reinterpret_cast<uintptr_t>(ptr) % 64 == 0 kullanarak manuel çalışma zamanı hizalama kontrolü yapmak ve hizalı ile hizalanmamış işleme için ikili kod yolları oluşturmaktı. Bu yaklaşım güvenliği garanti ediyordu ancak sıcak döngüde bir dalga tahmin hatası cezası getirdi ve talimat önbellek alanını iki katına çıkardı. Performans, ön yüz duraklamaları nedeniyle her paket için daha da kötüleşti ve 140ns'ye ulaştı, bu da gecikme hedefi için kabul edilemez hale getiriyordu.
Başka bir alternatif, alıcı bellek içinde düzgün hizalanmış bir alt tampon oluşturmak için std::align kullanmaktı, başlangıç baytlarını atlayarak. Bu, tanımsız davranışı ortadan kaldırsa da, her paket başına 63 bayta kadar israf ediyordu ve sıfır-kopya mimarisini karmaşık hale getiriyordu, çünkü aşağıdaki bileşenler verileri DMA tamponu içindeki belirli kaymalarda bekliyordu. Bellek parçalanması ve işaretçi aritmetiği aşırı yüke 15ns gecikme ekleyerek yine bütçeyi aşmasına neden oldu.
Seçilen çözüm, sürücü sözleşmesini doğrulayan bir hata ayıklama için sadece assert sonrası std::assume_aligned<64>(ptr) uygulamaktı. Yayın sürümlerinde, değerlendirme kayboldu ve sadece optimize edici ipucu kaldı. Bu, derleyicinin vmovdqa64 talimatlarıyaymasını ve ayrıştırma döngüsünü ZMM kayıtları boyunca tamamen açmasını sağladı. Donanım spesifikasyonu, sayfa hizalamasının değişmez bir garantisini sağladığı için bu yaklaşım, varsayımın inşa yoluyla kanıtlanabilir şekilde güvenli olmasını sağlıyordu.
Elde edilen sonuç, paket başına 65ns'lik stabil bir işleme süresi oldu, bu da 80ns eşik değerinin oldukça altındaydı. Profiling, AVX-512 birimlerinin %100 kullanımını ve sıfır hizalanmamış erişim cezasını doğruladı. Sistem, hata ayıklama derlemelerinde kodun netliğini veya güvenliğini feda etmeden belirleyici gecikmeyi korudu.
std::assume_aligned, çalışma zamanı hizalama kontrolü yapar mı yoksa işaretçi adresini mi değiştirir?
Hayır. std::assume_aligned, sıfır çalışma zamanı aşırı yükü ile tamamen bir derleyici yönergesidir. Bellek içinde hizalı bir kaydırmadaki yeni bir işaretçi hesaplayan ve döndüren std::align'ın aksine, std::assume_aligned aldığı tam adresi geri döndürür. İşlev, yalnızca işaretçi değerini derleyicinin içsel temsilinde işaretler. Eğer hizalama garantisi çalışma zamanında ihlal edilirse, nazik bir degrade veya istisna yoktur; program hemen tanımsız bir davranışa girer ve bu, ARM üzerinde SIGBUS ile çökmesine veya katı hizalama gereksinimleri olan mimarilerde yasadışı talimatlar yürütmesine neden olabilir.
alignas ile std::assume_aligned arasında nesne ömrü ve depolama süresi açısından ne fark var?
alignas, bir türün veya değişkenin hizalama gereksinimini etkileyen bir beyan belirleyicisidir; bu, derleyicinin nesne yaratılırken depolama düzenini nasıl düzenleyeceğini etkiler. Bu, alignof tarafından döndürülen değeri etkiler ve yığın veya statik depolama üzerindeki değişkenlerin düzgün bir şekilde hizalanmasını sağlar. std::assume_aligned, tersine, bellek düzeninde veya nesne ömründe herhangi bir değişiklik yapmaz; mevcut bir işaretçi değeri üzerine uygulanan bir optimizasyon ipucudur. std::malloc tarafından döndürülen belleği geriye dönük olarak hizalamak için alignas kullanamazsınız, ancak dış bilgiye sahip olduğunuzda std::assume_aligned'ı kullanarak derleyiciye atamanın sözleşmeyi karşıladığını vaat edebilirsiniz (örneğin, posix_memalign kullanarak).
std::assume_aligned, std::vector<T> veya standart new T[] ile güvenli bir şekilde kullanılabilir mi?
Genel olarak, bu güvenli değildir, ancak T'nin genişletilmiş hizalaması yoksa veya özel bir hizalanmış ayırıcı kullanılıyorsa. C++23 öncesinde, std::allocator ( std::vector tarafından kullanılan) hizalama gereksinimlerinin alignas belirleyicileri alignof(std::max_align_t)'den büyük olan türler için doğru bir şekilde gönderileceğini garanti etmezdi. new ( C++17'den beri), ::operator new(size_t, std::align_val_t) aracılığıyla aşırı hizalamayı destekler, ancak std::vector geçmişte, bu gereksinimleri ayırıcıya doğru bir şekilde iletmekte başarısız oldu. Bu nedenle, vec.data() için temel hizalama ötesinde bir hizalamayı varsaymak, std::pmr gibi bir polimorfik kaynak kullanmadığı veya bu tür garantiler sağlayan özel bir ayırıcı kullanılmadığı sürece tanımsız bir davranışa yol açar.