Incremental - Artımlı hesaplama için bir kütüphane

• Incremental, girdiler değiştiğinde karmaşık hesaplamaları verimli biçimde güncellemeyi sağlayan bir kütüphanedir
• Umut Acar ve diğerlerinin self-adjusting computation (kendini ayarlayan hesaplama) araştırmalarından ilham almıştır
• Elektronik tablolar gibi büyük ölçekli hesaplamaların veri değişikliklerine verimli şekilde tepki verecek biçimde yapılandırılmasını sağlar
• GUI uygulamalarının görünümlerine yeni verilerin verimli biçimde yansıtılmasını sağlar
• Filtreleme veya eşlemelerin ters dönüşümü gibi türetilmiş verilerin kaynak verilerle sürekli senkronize kalmasını garanti edebilir

---

Kullanım alanları

• Değişen girdilere yanıt olarak karmaşık hesaplamaları verimli biçimde günceller
• Elektronik tablo biçimindeki büyük ölçekli hesaplamaların veri değişikliklerine tepki verecek şekilde yapılandırılmasını sağlar
• GUI görünümlerine yeni verileri verimli biçimde entegre edebilir
• Kaynaktan hesaplanan türetilmiş verileri sürekli senkronize eder
  • Veri filtreleme
  • Eşlemelerin ters dönüşümü

Tasarım arka planı ve belgeler

• Umut Acar ve diğerlerinin kendini ayarlayan hesaplama araştırmasından ilham almıştır
• Ayrıntılı API ve kullanım bilgileri incremental/src/incremental_intf.ml dosyasında bulunabilir
• Resmî olmayan giriş materyali olarak bir blog yazısı ve tanıtım videosu sunar

[GN⁺]

Hacker News yorumları

• Bu tür reaktif programlama, günümüz JavaScript UI framework’lerinde signals adıyla yaygın biçimde kullanılıyor; ayrıca bir standartlaştırma önerisi de devam ediyor.
  Vue, SolidJS, Svelte, Ember ve Angular bunu kullanıyor; React için de MobX ve Jotai gibi uygulamalar var. Değişiklik yayılımı ve yönlü çevrimsiz grafik (DAG) değerlendirme algoritmalarının da çeşitli türleri var; bildiğim kadarıyla SolidJS 2, Incremental’a benzer yükseklik tabanlı bir algoritma kullanıyor.
  Ben düğümleri bir Int32Array arenasında ayırıp bağlı listeyle birbirine bağlayarak bağımlılık kenarı sayısıyla orantılı GC yükünden kaçınan bir uygulama üzerinde denemeler yapıyorum.
  Rust’ta da çeşitli uygulamalar var; UI framework’ü olarak Leptos, rust-analyzer’ın kullandığı genel amaçlı artımlı hesaplama sistemi olarak da Salsa mevcut. Bunu, bağımlılıkları otomatik izleyen bir build sistemi olarak da görmek mümkün; tup, hangi dosyaların okunduğunu saptamak ve bağımlılık ilişkilerini kurmak için build işlerini enstrümante ediyor. Yazarın yazısı ve klasikleşmiş Build Systems à la Carte da okumaya değer.

  • Hızla boşaltılabilen hafif bir bağımlılık grafiği oluşturulabilir. Bir signal’ın tam olarak nasıl değiştiğini tanımlamaya gerek kalmadan, yalnızca değişmiş olabileceğini işaretleyip değişiklik olduğunda bağımlı hedefleri boşaltmak ve yeni veri istendiğinde yeniden kaydetmek yeterli. Bu süreçte, artık ilgilenilmeyen değişiklikler için bazı aboneler bildirim alabilir.
    Ancak artımlı hesaplama ile fonksiyonel reaktif programlama (FRP) aslında farklı alanlar. Artımlı hesaplama, deltalar üzerinde çalışan fonksiyonları açıkça türetir; FRP ise yalnızca bozulmuş kısımları bulup onarma yöntemini de kullanabilir.
  • Bir başka önemli örnek de JetBrains Noria. Noria’nın özü bir UI framework’ü değil, artımlı hesaplama platformu; ancak şu anda JetBrains Air IDE’nin GUI render optimizasyonunda kullanılıyor.
  • Karmaşık nesnelerin güncellenmesini ele alma konusunda ciddi farklar var gibi görünüyor; zamanlamanın da farklı olması muhtemel.

• Incremental kütüphanesi, kaynak veri değiştiğinde hesaplama grafiğini kısmen yeniden somutlaştırma problemini çözmeye çalışıyor gibi görünüyor. İyi tasarlanmış build sistemlerine benziyor ve fonksiyonel programlamada da sık kullanılan yararlı bir yaklaşım.
  Artımlı hesaplama alanında Differential Dataflow, buna yakın Timely Dataflow ve DBSP de var. Feldera DBSP tabanlı; Materialize ise Differential Dataflow çevresindeki kişiler tarafından yönetiliyor.
  Ben finansal veriler ve iş yüklerine özel ayrı bir yaklaşım olan modolap üzerinde çalışıyorum. Çözülmesi gereken büyük ve önemli çok sayıda problem var. Bu bağlamda Signals and Threads’in build sistemleri bölümü de bakmaya değer.

  • modolap üzerindeki ana düğmeye basınca hiçbir açıklama olmadan 2.000 dolarlık Stripe ödemesine yönlendirmesi epey cesur.
  • openivm, geniş bir toplulaştırma işlemleri kümesini artımlı işlemler olarak uygulayan bir SQL-to-SQL derleyicisi; ayrıca somutlaştırılmış view’ları otomatik olarak koruyan bir DuckDB eklentisi de sunuyor.

• Goldman da yaklaşık 30 yıl önce finansal ürün fiyatlamasında aynı yaklaşımı kullanıyordu. Orada yaklaşık 13 yıl çalışırken Node Purpling hakkında uzun tartışmaları hatırlıyorum.
  Bilgisayar bilimi ilerledi ve bana göre bu bir grafik yaklaşımı değil; ancak türev gibi hesaplamalar maliyetli olduğundan çalıştırma sayısını teorik minimuma olabildiğince yaklaştırmak gerekiyor. İlgili bir HN tartışması da var.

  • Bu, gayriresmî olarak bank python diye adlandırılan ortamın ortaya çıkmasına yol açtı; bu yazı konuyu iyi ele alıyor.
    Özel kurum içi IDE’yi gördüğünüz anda öfkelenip istifa etmiyorsanız bile, yeni başlayanların alışması alışılmadık derecede uzun sürüyor; aylar geçtikten sonra bile temelden farklı unsurları öğrenmeye devam etmek zorunda kalmanız sorunu en iyi anlatan kısım. Benim de yaptığım işi tamamen anlamam yaklaşık iki buçuk yıl sürdü.
    Yeniden eğitim verilmesi gerektiğini fark edene kadar modern eğitim de neredeyse yoktu. En kötü kısmı UI yapmak için kod yazmaktı ve yeni projelerde kullanım onayı verilmiyordu.

• En sevdiğim teknik sunumlardan biri Seven Implementations of Incremental: https://www.janestreet.com/tech-talks/seven-implementations-of-incremental/

• Birkaç yıl önce dataflow programlamaya büyük ilgi vardı ve pek çok kişi bu probleme farklı yönlerden yaklaşıyordu sanki. Bu kütüphaneyi görünce aklıma hemen Clojure’un Javelin’i geldi.

• İlginizi çekiyorsa Incremental üzerine inşa edilmiş UI kütüphanesi Bonsai de bakmaya değer.
  React gibi kütüphaneler sanal DOM ile gereksiz işleri verimli biçimde atlıyor; ancak sanal DOM’un kendisini oluşturmak da zaman alıyor. Bonsai, sanal DOM’u bile artımlı hale getiriyor ve onunla çalışmak da keyifli.
  Ben artık bakımı yapılmayan Revery için bir masaüstü UI kütüphanesi geliştirmiştim, ancak oldukça eski bir Bonsai sürümü kullanıyor.

• Bunun, girdiye yeni bir değer yayımlayıp hesaplamadan geçirerek yeni sonucu abonelere ileten observable pattern’dan nasıl farklı olduğunu tam olarak anlayamadım.
  Değişiklik algılama ve değer aynı kaldığında yayılımı durduran bir optimizasyon vardır, ama observable’larda da bu mümkün. stabilize ile yeniden hesaplamadan önce değişiklikleri toplu işleme kısmı da ilginç, ancak o da observable ile uygulanabilir.
  Temel farkın, iç inceleme yoluyla hesaplama grafiğini otomatik kurmakta mı, yoksa daha köklü bir unsurda mı olduğunu merak ediyorum.

  • Bu, observable pattern’ı nasıl tanımladığınıza bağlı. Buradaki temel unsur tembel değerlendirme ve grafik düğümleri arasındaki zayıf bağlantı. Düğüm değerleri yalnızca gözlemlendiğinde somutlaşır ve çalışma sırasında grafik yapısındaki değişiklikler de esnek biçimde ele alınır.
    Yalnızca bazı düğümler gözlemlendiğinde tüm grafiği somutlaştırmak gerekmez. Hesaplamayı herhangi bir anda durdurup grafiği yalnızca kısmen güncellenmiş durumda bırakabilir, girdilerde ek değişiklikler yaptıktan sonra ilgilendiğiniz düğümlerin somutlaştırılmasına devam edebilirsiniz; algoritma tüm değişiklikleri toparlar.
    Artımlı hesaplama özünde bu tür özellikleri kapsayan bir terimdir; aynı sistem gözlemci ve abone modeliyle de kurulabilir. Klasik Excel elektronik tabloları iyi bir örnektir; Salsa algoritması açıklaması da bakmaya değer.
  • Kabaca observable’lar bir hedefe abone olup değerleri dinleme biçimidir; Incremental ise daha çok hesaplama ve durum DAG’inin tamamına yayılan bir önbellek gibidir. Yalnızca gerekli kısımlar yeniden hesaplanarak optimize edilebilir.
    Ron Minsky’nin sunumu çok iyi.
  • Bu yazı artımlı ve akış sistemlerinin haritasını anlamaya yardımcı oluyor.
  • Ben de benzer düşündüm. İlk bakışta bağımlılık takibi olan reaktif programlamaya çok yakın görünüyor. Asıl avantajın API kullanılabilirliği mi, yoksa genel observable uygulamalarıyla pratikte zor olan iç optimizasyonlar mı olduğunu merak ediyorum.
  • Temelde mesele grafik, evet; ama devasa ve dinamik olarak değişen grafiklerde değişiklikleri doğru ve verimli biçimde hesaplama yöntemi.
    Yüzlerce ara düğüme ayrılıp farklı uzunluktaki yollardan geçerek tekrar birleşen elmas biçimli bir alt grafiği düşünebilirsiniz. Bazı yollarda min(A, B) olup yalnızca maksimum taraftaki değerin değiştiği durumlar da var.
    Basit bir observer yaklaşımı, hesaplama miktarının potansiyel olarak üstel biçimde patlamasına ve eşzamanlılık sorunlarına yol açmaya çok yatkındır. Bu kütüphane, grafik yapısı dinamik olarak değişse bile optimale yakın ve doğru çalışır. Observer vb. ile de aynı sonuç elde edilebilir, ancak performans uçurumlarından kaçınarak doğru şekilde uygulamak çok daha zordur.

• Jane Street projelerinin güçlü yanı, araştırmada ya da niş sistemlerde kalan fikirleri geliştiricilerin gerçekten kullanabileceği bir biçimde paketlemeleri. Kütüphaneyi benimsemeseniz bile tasarım belgeleri genellikle okumaya değer.

• Electric Clojure istemci-sunucu sınırını aşan artımlı rendering sunar. En benzeri bence SolidJS, ancak SolidJS yalnızca frontend tarafıyla ilgilidir.

• Eskiden buna benzer bir şey yaparken neredeyse hiç emsal bulamamıştım. Kullanım amacı ortadan kalkınca projeyi sonlandırdım, ama tekrar bakmak istiyorum; npm’de data-rambler adıyla duruyor.
  Fikir, JavaScript çalışma zamanına yüklenebilen alan-özel bir dile (DSL) veri akışları beslemekti. Modül verileri birden fazla çıktı akışına dönüştürüyor, bunları da ayrı bir rapor kütüphanesine aktararak şablon tabanlı dinamik raporlar üretiyordu.
  İlk sürümden itibaren oldukça güçlüydü, ancak karmaşıklığı azaltmak için JavaScript’e daha uygun bir söz dizimiyle iyileştirmeye yönelik büyük planlarım da vardı.