Sorunun yanıtı.
Rust, enum ayrımcılarının depolama aşamasını ortadan kaldırmak için niş değer doldurma olarak bilinen bir düzenleme optimizasyon stratejisi uygular. Derleyici, türün temsil edilebilir aralığında yer alan "niş" değerleri belirler; bunlar arasında NonZeroU32 için sıfır değeri veya referanslar için null işaretçi yer alır ve bu bit desenlerini None gibi diğer enum varyantlarını kodlamak için yeniden kullanır. Bu dönüşüm, yük türünün, kendi iç özellikleri veya iç rustc_layout öznitelikleri tarafından tanımlanan sınırlı bir geçerlilik aralığına sahip olmasını gerektirir. Bir türün geçerli bir niş taşıyıcısı olması için, oluşturulması veya okunması tanımsız davranış oluşturan en az bir bit deseni sergilemesi gerekir; böylece derleyici, bu deseni enum'un alternatif varyantları için ayırabilir ve ek ayrımcı alanı tahsis etmeden kullanılabilir.
Hayattan bir durum
Yüksek frekanslı bir ticaret motoru geliştirirken, ekibimiz, milyonlarca sipariş zaman damgasını depolarken ciddi önbellek baskısı ile karşılaştı. Her opsiyonel zaman damgası, hizalama ve ayrımcı aşırı yükü nedeniyle 16 byte tüketiyordu, oysa zaman damgaları kendileri kesinlikle pozitif Unix çağ değeri oluyordu. Güvenliği riske atmadan veya Send ve Sync garantilerini karmaşıklaştıran ham işaretçilere başvurmadan bellek izini azaltmamız acil bir ihtiyaç haline geldi.
Değerlendirilen yaklaşımlardan biri, ham u64 değerlerini ve güvenliksiz dönüşüm işlevleri ile gönderilen sıfır değerlerini kullanarak manuel bit paketlemeyi içeriyordu. Bu çözüm, maksimum bellek verimliliği vaat ediyordu ama felaket riskleri de getiriyordu: bir mantık hatası geçersiz bir NonZeroU64 oluşturabilir veya sıfıra gizlenmiş bir null işaretçiyi dereferanslayabilirdi, bu da Rust'ın bellek güvenliği invarinatlarını ihlal ederdi. Ayrıca, ekibin kaçınmaya çalıştığı kapsamlı denetim izleri ve unsafe blokları gerektirecekti.
Bir diğer aday, standart kütüphanenin garantili niş optimizasyonunu kullanarak doğrudan Optionstd::num::NonZeroU64 kullanmaktı. Bu yaklaşım, tam tür güvenliğini ve ergonomik match ifadelerini koruyarak Option'ın tam olarak 8 byte kaplamasını sağlıyordu. Ana kısıtlama, zaman damgalarının asla sıfır olmalarını garanti etmekti ve bu, tüm zaman damgalarının 1970 sonrası olduğu için alan mantığımızda geçerliydi.
İkinci çözümü seçtik ve Timestamp yeni türümüzü NonZeroU64 ile sarmalayarak sistem sınırında girdileri doğruladık. Sonuç olarak, ana sipariş defteri önbelleğimizde %50'lik bir bellek kullanımı azaldı. Bu optimizasyon, önbellek terleme sorununu ortadan kaldırdı ve %30'luk bir arama gecikmesi iyileştirmesi sağladı; tüm bunlar tek bir unsafe kod satırı olmadan gerçekleştirildi.
Adayların genellikle gözden kaçırdığı şeyler
Option<u32> neden 8 byte tüketirken Option<NonZeroU32> sadece 4 byte tüketiyor ve bu optimizasyon Option<Option<NonZeroU32>> gibi iç içe yapılarla nasıl bir davranış gösteriyor?
u32 türü, geçerli olan tüm 2^32 bit desenini kabul ettiğinden, derleyicinin None varyantı olarak yeniden kullanabileceği herhangi bir "boş" bit deseni kalmıyor. Sonuç olarak, derleyici, ayrımcı bir byte eklemek zorunda kalıyor (hizalama için 4 byte'a kadar dolduruluyor), bu da toplamda 8 byte ediyor. Tersine, NonZeroU32 açıkça 0x00000000 bit deseninin geçersiz olduğunu beyan ederek, Rust'ın None kodlamak için kullandığı bir niş oluşturuyor; bu, elde edilen Option'ın tam olarak 4 byte kaplamasını sağlıyor.
İç içe yapılar için optimizasyon etkili bir şekilde zincirleme halinde çalışıyor: Option<Option<NonZeroU32>> 4 byte'ta kalıyor çünkü dış Option, NonZeroU32'nin mevcut niş alanından farklı geçersiz bir bit desenini (örneğin, 0x00000001) kullanıyor. Bu özyinelemeli optimizasyon, taşıyıcı tür yeterli geçersiz bit desenine sahip olduğu sürece tüm enum ayrımcı değerlerini barındıracak şekilde devam eder.
#[repr(C)] veya #[repr(u8)] gibi açık düzenleme nitelikleri, niş optimizasyonu ile nasıl etkileşiyor ve bu etkileşim FFI sınırları için neden önemlidir?
#[repr(C)] veya #[repr(u8)] uygulandığında programcı, ayrımcının belirli bir ofsetle ve tanımlanmış bir boyutla yer kapladığı sabit bir bellek düzeni zorunlu kılar. Bu açık temsil, niş optimizasyonunu etkili bir şekilde devre dışı bırakır; zira ABI uyumu için C yapılarına, açık etiketler bekleyen bir yapı sağlamak zorundadır, fakat bu durum enum'un ayrımcı için ek alan tüketmesine sebep olur.
FFI bağlamlarında bu ayrım kritik hale gelir, çünkü C kodu ayrımcının öngörülebilir, sabit bir ofsette olmasını bekler. Niş ile optimize edilmiş bir Rust enum'unun açık repr nitelikleri olmadan sınırdan geçişi tanımsız davranış yaratır, oysa #[repr(C)] bellek verimliliği pahasına gerekli düzen istikrarını garanti eder.
MaybeUninit<T>'in enum optimizasyonu için niş taşıyıcısı olmasını ne engelliyor, T kendisi geçersiz bit desenlerine sahip olsa bile, mesela Option<MaybeUninit<NonZeroU32>> içinde?
MaybeUninit<T>, tanımsız davranışa yol açmadan her türlü bit desenini tutacak şekilde mimari olarak tasarlanmıştır; çünkü amacı potansiyel olarak başlatılmamış belleği temsil etmektir. Sonuç olarak, derleyici MaybeUninit<T>'i geçersiz bit desenlerine sahipmiş gibi değerlendirir; bu da geçerlilik aralığının tüm 2^(8*sizeof(T)) olası bit kombinasyonlarını kapsadığı anlamına gelir. Bu toplam geçerlilik, enum optimizasyonu için tekrar kullanılabilecek herhangi bir nişin ortadan kalkmasına sebep olur, T'nin özelliklerinden bağımsız olarak.
Bu nedenle, Option<MaybeUninit<NonZeroU32>> 8 byte kaplar—MaybeUninit<u32>'nin boyutu artı ayrımcı dolgusu—oysa altta yatan NonZeroU32 sınırlı bir geçerliliğe sahiptir. Bu davranış, niş optimizasyonunun yalnızca doğrudan türün geçerlilik kısıtlamalarına dayanarak çalıştığını, içeriğinin olası özelliklerinin geçişken niteliklerine dayanmadığını göstermektedir.