Daha Fazla Dilin OxCaml’ın Sıfır Tahsisli Fonksiyon Denetimini Öğrenmesi Gerekiyor

 (theconsensus.dev)
2 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Jane Street’in OCaml üst kümesi olan OxCaml, [@zero_alloc] ile bir fonksiyon çağrı ağacının tamamında heap tahsisini yasakladığını derleyiciye bildirmeyi mümkün kılıyor
  • Bildirilen çağrı yolunda tahsis oluşursa bu durum doğrudan derleme hatası olarak ortaya çıkıyor; böylece regresyonlar, sonradan profiler ile aramaya kıyasla daha hızlı engellenebiliyor
  • C, C++, Java, Go, C#, Rust, Zig, OCaml gibi dillerde genelde hot path üzerindeki tahsisleri profiler ile bulup azaltma yaklaşımı öne çıkıyor
  • Hot path kodu küçük bir değişiklikle yeniden tahsis üretmeye başlayabildiği için, önceki optimizasyon bağlamı unutulursa aynı incelemeyi tekrar yapmak gerekebiliyor
  • Zig ya da modern Rust’ın bazı bölümlerindeki allocator aktarma geleneği de yardımcı oluyor, ancak derleyici denetimi gelenekten daha doğrudan bir güvence sağlıyor

[@zero_alloc] tahsis yönetimini nasıl değiştiriyor

  • OxCaml, Jane Street’in OCaml üst kümesidir ve bir fonksiyonun heap’e tahsis yapmadığını beyan etmeyi destekler
  • Bir fonksiyona [@zero_alloc] eklendiğinde, derleyici yalnızca o fonksiyonu değil, onun altındaki çağrı ağacını da heap tahsisi açısından denetler
  • Çağrı ağacı içinde tahsis oluşursa derleme başarısız olur ve derleyici tahsisin nerede oluştuğunu bildirir
  • Benzer denetimlerin statik analizle oluşturulması mümkün olabilir, ancak üretilen özetlere dayanarak böyle bir özelliği doğrudan derleyiciye koyan ana akım diller nadirdir

Profiler merkezli yaklaşımdan farkı

  • Diğer dillerde genelde profiler ile tahsisler bulunur, ardından özellikle milyonlarca kez çalışan döngüler içindeki tahsisler kaldırılır ya da azaltılır
  • C, C++, Java, Go, C#, Rust, Zig ve OCaml, profiler merkezli yaklaşımın örnekleri olarak sıralanır
  • Hot path içindeki tek bir satırı değiştirmek bile yeniden tahsis ekleyebilir ve bunun nedenini bulmak için profiler’a geri dönmek gerekebilir
  • Zig ve modern Rust’ın bazı bölümlerinde allocator’ı fonksiyona aktarmama yaklaşımı regresyonları azaltabilir, ancak bu yöntem geleneklere dayanır
  • [@zero_alloc] farkını yaratan şey, sonradan yapılan analiz ya da ekip kuralları değil, derleyicinin derleme anında tahsis regresyonlarını engellemesidir

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs yorumları

  • Zig’de allocator’ın fonksiyon argümanı olarak geçirilmesinin nedeninin, argüman olarak allocator almayan fonksiyonların heap allocation yapamamasını sağlamak olduğunu anlamıştım; doğru mu merak ediyorum
    “Kurallar göz ardı edilebilir” sözü gerçekten doğruysa, amaçtan farklı gibi görünüyor

    • Doğru, sonuçta yalnızca bir kural
      Fonksiyonun içinde de dışarıda yapıldığı gibi yeni bir allocator oluşturulabilir

  • gift link: https://theconsensus.dev/p/2026/…

  • Rust’ta yalnızca core kullanmak da allocation’dan kaçınmanın bir yolu

    • “Allocation’dan kaçınmak” hikâyenin yalnızca bir kısmı
      Bu yaklaşım sonunda daha çok “bağımlılıkları kontrol et” ya da “tüm çağrı grafiğini elle denetle” demeye geliyor
      Yazının odağı, derleyici gibi araçların belirli özellikleri statik olarak zorunlu kılması ve bu özelliğin bozulduğu noktaları üretken biçimde bulmayı sağlayan bir iş akışı sunması üzerinde

  • D’de @nogc var; bundan sonrası, net allocation pattern’larına sahip ve doğrudan kontrol edilebilen abstraction’ları kullanma meselesi

  • Makale başlıklarını açıklayıcı biçimde koyma yetimizi kaybettiğimiz için ekleyeyim: Asıl nokta, bir fonksiyona [@zero_alloc] ekleyip o fonksiyonun çağrı ağacı heap’e dokunursa derleyicinin programı reddetmesini sağlayan özellik

  • Bu yöntemin “exception fırlatmaz veya panic etmez”, “lock yok”, “her zaman sonlanır” gibi çeşitli koşullara da uygulanıp uygulanamayacağını merak ediyorum