OCaml için daha iyi bir derleme sistemine, Dune’a giden yol

 (blog.janestreet.com)
1 puan yazan GN⁺ 2025-02-01 | 1 yorum | WhatsApp'ta paylaş
  • Jane Street, OMake’e duyduğu memnuniyetsizlikten Jenga’yı geliştirdi; ancak dışarıda benimsenmesi zayıf kaldı. Uyumluluk için oluşturulan Jbuilder ise beklenmedik şekilde OCaml topluluğunun temel araçlarından birine dönüştü
  • Jbuilder’ın ilk çekiciliği özelliklerinden çok hızı ve taşınabilirliğiydi; Jane Street projelerinde OCamlbuild’e göre yaklaşık 5 kat daha hızlı derleme, benimsenmesini sağladı
  • Jbuilder, OCaml Labs ile iş birliği içinde tam teşekküllü bir derleme sistemine evrildi ve mevcut Borland Java IDE’siyle yaşanan ad çakışması nedeniyle topluluk tartışmalarının ardından Dune adını aldı
  • Jane Street bir süre Jenga ve Dune’u birlikte sürdürdü; ancak kod tabanı 65M satır OCaml ve 5M satır Python düzeyine büyüyünce kurum içi geçişin zorluğu ciddi ölçüde arttı
  • Bir yılı aşan yoğun çalışmanın sonunda Jane Street’in kod tabanı Dune ile derlenir hale geldi; önbelleğin büyük ölçüde dolu olduğu derlemeler 2–3 kat hızlandı

OMake memnuniyetsizliğinden doğan Jenga

  • Derleme sistemi, birden çok kaynak dosyadan çalıştırılabilir programlar üreten; derleyici çağrılarını ve test çalıştırmayı da üstlenen, geliştiricilerin günlük aracıdır
  • Jane Street, 2012 civarında OCaml’in standart derleme sistemlerinden biri olan OMake’ten memnun kalmayarak kendi derleme sistemi Jenga’yı geliştirdi
  • Jenga kurum içinde iyi çalıştığı için Jane Street, topluluğun da bundan faydalanabileceğini düşünerek onu açık hale getirmeye karar verdi
    • Dış kullanıcıların Jenga’yı deneyip katkıda bulunmasını bekledi
    • Jane Street kodunu açık kaynak olarak yayımlamanın da kolaylaşacağını düşündü
  • Gerçekte dışarıdaki benimsenme beklentilerin altında kaldı
    • Windows’ta çalışmıyordu
    • Jenga’yı benimsemek, fiilen OCaml derlemenin Jane Street yönteminin tamamını kabul etmeyi gerektiriyordu
  • Dış kullanım artmayınca Jane Street, Jenga’yı yeniden kapalı hale getirdi; açık kaynak kodu derleme sorunu ise devam etti

Uyumluluk katmanı olarak geliştirilen Jbuilder

  • 2016’da Jane Street, dış kullanıcıların Jenga’nın tamamını benimsemeden kendi kodlarını derleyebilmesini sağlayacak basit, çapraz platform bir araç olan Jbuilder’ı geliştirmeye karar verdi
  • Bu araç aynı zamanda, o dönemde OCaml projelerini derlemede yeni standart olarak öne çıkan OCamlbuild’e uyacak şekilde derlemeleri yeniden yazma yükünü azaltmayı amaçlıyordu
  • Jbuilder, Jenga’nın derleme yapılandırması için kullandığı jbuild dosyalarını anlıyor ve gerekli derleme komutlarını topolojik sıralama düzeninde çalıştırıyordu
  • İlk Jbuilder, genel anlamda bir derleme sistemi olmaktan uzaktı
    • Yalnızca girdisi değişen komutları seçip yeniden çalıştırmıyordu
    • Her seferinde tüm komutları yeniden çalıştıran bir yaklaşıma sahipti

Jbuilder’ın Dune’a dönüşme süreci

  • Jbuilder başlangıçta küçük bir uyumluluk katmanı olarak tasarlanmıştı; ancak kullanıcılar onu Jane Street paketlerinin ötesinde kendi projelerini derlemek için de kullanmaya başladı
  • Benimsenmeyi sağlayan en büyük etken hızdı
    • Jane Street projelerini derlerken OCamlbuild’e göre yaklaşık 5 kat daha hızlıydı
    • Taşınabilirliği iyiydi
    • Yapısı basitti, bu yüzden değiştirmesi kolaydı
  • Jane Street, Jbuilder’ı daha eksiksiz bir derleme sistemine dönüştürmek için OCaml Labs, bugünkü Tarides ile iş birliği yapmaya başladı
  • Ad ayrı bir sorun haline geldi
    • Borland’ın Java IDE’si JBuilder zaten vardı
    • Bu sistem uzun zaman önce fiilen ortadan kalkmış olsa da, adın kullanımı için telif hakkı sahibine başvurulduğunda izin alınamadı
  • Topluluk tartışmalarının sonunda yeni ad olarak Dune seçildi

İki derleme sistemini birlikte sürdürmenin maliyeti

  • Dune’un popülerliği arttıkça Jane Street, kendi geliştirdiği iki eksiksiz derleme sistemi olan Jenga ve Dune’u aynı anda sürdürüp destekler hale geldi
  • Dune; yeniden tasarlanmış yapısı, çoğu kullanıcı derlemesindeki yüksek performansı, daha geniş benimsenmesi, daha iyi API’leri ve kullanıcı deneyimiyle yerleşik bir sistem haline geldi
  • İçeride ne zaman Dune’a geçileceği doğal bir konuya dönüştü; ancak derleme sistemi ekibi, büyüyen kod tabanına yetişmekle bile meşguldü
    • Dune’un başladığı 2016’da OCaml kodu 4M satırdı
    • Bugün 65M satır OCaml ve 5M satır Python bulunuyor
  • Dune’a geçiş büyük bir yük olduğu için ciddi şekilde ele alınamadı; yalnızca “önümüzdeki 6–12 ay içinde mümkün olabilir” şeklindeki iyimser tahminler tekrarlandı
  • Geçen yıl Jane Street, derleme sistemi ekibini 5 tam zamanlı mühendise çıkardıktan sonra uzun süredir ertelenen geçiş çalışmasına başladı

Jane Street içinde Jenga’nın yerini alan Dune

  • En büyük işlerden biri, Dune’un Jane Street’in dev kod tabanına uygun şekilde ölçeklenmesini sağlamaktı
  • Dune’un dışarıda hızlı olmasının nedenlerinden biri, çoğu kullanıcının Jane Street’in 70M satırlık deposundan çok daha küçük projeler derlemesiydi
  • Jenga da 10 yıl boyunca yerinde saymamıştı
    • Jane Street, kod tabanının büyümesine paralel olarak Jenga uygulamasını sürekli iyileştirdi
    • Jenga, büyük ölçekli monorepo gereksinimlerine göre oldukça optimize edilmiş durumdaydı
    • Bu optimizasyon çalışmalarının önemli bir kısmının Dune’a taşınması gerekiyordu
  • Günlük entegrasyon çalışmaları da hiç kolay değildi
    • Derleme sistemi birçok iş akışında çağrılıyordu
    • Vim, Emacs ve VSCode adlı üç editörün her birinde Jenga için özel entegrasyonlar vardı
    • Her entegrasyonun tek tek Dune’a geçirilmesi gerekiyordu
  • Bir yılı aşan yoğun çalışmanın sonunda Jane Street’in kod tabanı artık Dune ile derleniyor
    • Geçiş anındaki Dune performansı genel olarak Jenga ile aynıydı ya da daha iyiydi
    • Bazı durumlarda çok daha iyi performans gösterdi
    • Derleme işlerinin çoğu zaten önbellekte olduğunda derlemeler 2–3 kat hızlandı

Tek bir sistem üzerinde mümkün hale gelen sonraki iyileştirmeler

  • Jane Street, Dune performans iyileştirmelerinin önemli bir bölümünü açık kaynak olarak yayımlamayı planlıyor; bazıları şimdiden yayımlandı
  • Jane Street’e özel bir Dune fork’u ve dışarıdaki Dune olmak üzere yeniden iki sistem oluşmaması için, mümkün olan değişiklikleri upstream’e aktarmaya özen gösteriyor
  • Dune, yeni özellikler geliştirmek için daha uygun bir temel haline geldi
    • Kod tabanı daha basit ve üzerinde çalışması daha kolay
    • Tek bir sisteme odaklanmak mümkün
  • Aşağıdaki özellikler de artık daha yakın

    • Dağıtık derleme

      • Sığ derleme, yani “builds without the bytes”
      • Derleme grafiğinin kendisinin önbellekten yüklenmesi
      • Derleme sistemi ekibi New York, Londra ve Singapur’daki 12 tam zamanlı mühendise büyüdü ve Dune iyileştirme hızı da arttı

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-01
Hacker News yorumları

  • Dune’un çökme mesajı:

    Segfault üretmeyeceğim. Belirsizlik zihni öldürendir. İstisna, bütünüyle yok oluşu çağıran küçük ölümdür. Tüm durumları eksiksiz ifade edeceğim. Yürütme benden geçecek ve içimden akacak. O geçtikten sonra, izlediği yol boyunca stack’i geri saracağım. Durumların işlendiği yerde hiçbir şey kalmayacak. Yalnızca ben kalacağım

  • Jane Street’in teknoloji podcast’i Signals and Threads’te 2020’de build sistemlerini ele alan bir bölüm vardı; şiddetle tavsiye ederim
    Diğer bölümler de iyi; özellikle Richard Eisenberg’in konuk olduğu The Future of Programming ve Anil Madhavapeddy’nin konuk olduğu What is an Operating System?’ı da öneririm
    ¥https://signalsandthreads.com/build-systems/
    °https://signalsandthreads.com/future-of-programming/
    §https://signalsandthreads.com/what-is-an-operating-system/

  • Jane Street’in HM tipli fonksiyonel programlamanın da üzerine yeterince emek verildiğinde production’a hazır ve çok hızlı olabileceğini kanıtlamış olması saygıyı hak ediyor
    Hâlâ bazen daha akademik tarzdaki fonksiyonel dillerin production’da kullanılamayacağı söyleniyor, ama OCaml yüksek performans gereksinimleri olsa bile bunun gayet mümkün olduğunu gösteriyor

    • Mercury de backend’de Haskell kullanıyor
      https://mercury.com/
    • Doğru. F# da production’da epey kullanılıyor
      Mevcut sistemlerle geniş çapta birlikte çalışırken yüksek kaliteli programlar üretmek için harika bir seçenek
    • NoRedInk de backend’in bir kısmında Haskell, frontend’in büyük bölümünde ise Elm kullanıyor
      Birkaç yıl önceki bir blog yazısına göre Roc ile de ilgilenmişlerdi; şu anda kullanıyorlar mı bilmiyorum
      [0] https://blog.noredink.com
    • pandoc da Haskell ile yazıldı. Facebook da bir dönem spam önleme için Haskell kullanmıştı; hâlâ kullanıyor mu bilmiyorum
    • Tip sisteminin çalışma hızını etkilediği mi söyleniyor? Bildiğim kadarıyla tip sistemi sadece statik analiz; runtime hızına etkisi yok

  • Janestreet blog yazılarını her gördüğümde, Jane’de finans sektöründe çalışmanın sözde teknoloji sektörü işlerindeki pozisyonların %90’ından daha eğlenceli ve daha iyi ödüllendirilen bir iş olabileceğini düşünüp içimden gülüyorum

    • Jane Street ve birkaç elit şirket, finans sektöründeki teknik çalışanların sadece çok küçük bir oranı
      Finans alanındaki teknoloji işlerinde, bırak Jane Street’i, ortalama bir teknoloji şirketi kadar bile eğlenceli ya da iyi ücretli olmayan çok daha fazla iş var
    • Komşunun tavuğu komşuya kaz görünür
      Finans sektöründeki işlerin çoğu 20 yıllık Java kodunu düzeltmekten ya da özel raporlar için Excel dosyalarına veri koyup çıkarmanın yeni yollarını bulmaktan ibaret
    • Kanıtlanamaz bir anekdot ama bir iş arkadaşım JS’de 6 ay çalıştıktan sonra iş çok sıkıcı olduğu için FAANG’e geçti. Maaşı daha yüksek olmasına rağmen böyle yaptı
      Ayrıca JS’ye girmenin Google/Meta’ya girmekten çok daha zor olduğunu duydum
      Ben de eskiden başvurmuştum; mülakatçı oldukça nahoştu ve Big Tech mülakatlarında böyle bir şey yaşamamıştım, o yüzden iyi bir izlenim bırakmadı
    • Gerçekten öyle mi? Çalışma saatleri uzun, standartlar çok katı ve nihayetinde kâr için sayılarla oynama işi; çoğu kişi için pek anlamlı bir iş değil
      Yine de insanlara reklam tıklatmaya çalışmaktan daha değerli görüyorum
    • İnsanlar Jane Street’te ya da benzer şekilde seçici yüksek frekanslı işlem şirketlerinde yapılan işleri fazlasıyla abartıyor
      Diğer şirketlerde olduğu gibi ilginç projelerle sıkıcı işlerin bir karışımı var

  • Karmaşık bir kod tabanından daha kötü olan tek şey karmaşık bir build sistemidir. CMake tiksindirici
    “Bu dili derlemek için bir de başka yeni bir dil öğren!” durumu

    • Karmaşık bir build sisteminden daha kötü olan şey, ihtiyacın olanı build edemeyen basit bir build sistemidir :(
    • Daha çok “bu berbat yeni dili öğren” gibi
    • CMake’ten nefret etmiyorum. Korkunç, ama zaten C ya da C++ kullanıyoruz; dolayısıyla çıta oldukça düşük
      Doğru yaptığı birkaç şey var ve yanlış yaptığı bazı şeyler yönetilebilir
      İnsanların düzenleyebileceği tek bir yapılandırma dosyası setiyle birden fazla platform için build süreci elde edebiliyorsam, bir miktar acıya katlanabilirim
    • Modern hedef odaklı CMake içindeki fikirler değerli
      Korkunç script dili ayağına dolanıyor, ama yeterli motivasyon olursa iyileştirilebilir

  • Eskiden Lisp’ten sonraki ilk fonksiyonel programlama deneyimim olarak birkaç yıl Haskell tarafında geçirdim.
    OCaml bana pek hitap etmemişti; ayrıca nadir görülen türden bir noktalı virgül alerjim vardı, bu yüzden Haskell gözüme çok daha iyi görünüyordu.
    Ama yakın zamanda Reason’ı denedim ve çok hoşuma gitti; birden OCaml ile ilgili her şey ilgimi çekmeye başladı.

    • F#, OCaml’in daha ilginç özelliklerinden bazılarını, örneğin modül sisteminin ifade gücünü barındırmıyor; ama girintiye duyarlı sözdizimi sayesinde çoğu durumda noktalı virgül de dahil birçok yapıyı ortadan kaldırıyor.
      https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
    • “Amacınız bir dosyayı script olarak derlemek ya da yorumlatmaksa, OCaml’de çift noktalı virgülden kaçınabilirsiniz ve kaçınmalısınız. Bıraksanız hata vermez ama işe de yaramaz. Derleyicinin buna izin vermesinin nedeni, UTop’tan bir dosyaya kopyalayıp yapıştırırken bunları kaldırmak zorunda kalmamanızdır.”
      https://ocaml.org/docs/toplevel-introduction#loading-librari...
      https://reasonml.github.io/ havalı görünüyor; JavaScript hissi veren OCaml gibi.
    • İlginç olan şu: Haskell’de beni hep iten şey, yapıyı anlamayı sağlayan görsel ipuçları olmadan boşluk ve tanımlayıcı akışı gibi hissettirmesiydi.
      O çizgiyi kavrayınca sorun olmayabilir; ama sanki Lisp’te olduğu gibi o yapıyla düşünmeyi öğrenmek gerekiyor. Yine de ekranı kaplayan Haskell kodu görünce gözüm korkuyor.
      Bunların arasında SML/NJ bana en okunabilir geleniydi.
    • Keşke Reason sözdizimi varsayılan sözdizimi olsaydı.

  • Jane Street’in açık kaynak OCaml kütüphanelerini ve araçlarını az çok ciddi bir projede kullanan var mı merak ediyorum.
    Kısa bir bakıştan edindiğim izlenim, ekosistem oluşturmak ve kodu açık kaynak yayımlamak için çok çaba harcadıkları; ancak Jane Street dışındaki insanların kullanması için “hazır” durumda olmadığı yönündeydi.

    • Kullanıyorum. OCaml’i ilk öğrendiğim projede onların standart kütüphane yerine geçen paketlerini kullanmıştım, o yüzden kullanmaya devam ettim.
      Bir şeyi bulmak için fonksiyon imzalarını epey iyi okuyabilmeniz gerekiyor; bunun dışında şikâyetim yok. Örneğin tüm temel tipler için s-expression’a dönüştürme ve geri dönüştürme fonksiyonları, varlıklarını bilip önceden plan yaparsanız muazzam zaman kazandırıyor.
      Başka kütüphanelerini de kullandım; logging ve birim testi ppx’leri, OCaml dünyasında böyle bir şey mümkünse fiilen standarda yakın. Kod biçimlendirici, bir test framework’ü ve gelişmiş veri yapısı implementasyonları da kullandım.
      Bazen, başka bir yorumda söylendiği gibi, gerçekten çalışmayan şeylerle de karşılaşıyorum. Ayrı dağıtılan, dokümante edilmemiş bir şeye bağımlı olması ya da gizli bir ayar gerektirmesi gibi. Kötü niyet yok; issue açıp 1-2 yıl sonra geri dönerseniz çoğu zaman çalışır hale gelmiş oluyor.
      Hiç hayal kırıklığı yok değil; ama kaynakları daha az sayıda sürümü test edip cilalamaya harcamak yerine her şeyi açık yayımlama yaklaşımlarını takdir ediyorum. Kod kalitesi genel olarak çok yüksek ve kendiniz çalıştıramasanız bile titiz, doğrulanmış örnek implementasyonlar oluyor.
    • Ciddi bir proje değil ama kişisel statik site üreticimde onların stdlib’ini kullanıyorum.
      API’sinin standart stdlib’den çok daha iyi olduğunu düşünüyorum.
    • magic-trace aracını denemeye çalıştım; basit bir dotnet programında bile en az 4 farklı çökme yaşadım.
    • Bloomberg’de kullanmıştım.
    • Karmaşık bir matematik araştırma projesinin testlerini çalıştırıyorum; çalışma süresi şaşırtıcı biçimde şu ana kadar Lean 4 << Haskell << OCaml sırasına göre.
      Lean 4’ü seviyorum ama yapay zekadan yardım almak kolay değil. Bugünkü işim, referans kılavuzunu 200K bağlam penceresine güzelce sığacak şekilde sindirmek. Faydalı olup olmayacağını göreceğim.

  • Kendi yeni build sistemini geliştirip ona migrate etmenin, buck2 ya da bazel gibi hazır araçları benimsemekten hâlâ daha mantıklı olabilmesi epey şaşırtıcı.
    Bu tür gelişmiş build araçlarını devreye almanın kolay olduğu anlamına gelmiyor; ama kendiniz yapmakla kıyaslayınca durum nasıl? dune’u çok farklı kılan özel bir şey var mı merak ediyorum.

    • Ayrıntıları deneyimli kişiler daha iyi anlatabilir; ama JS 2012’de kendi aracını yapmaya başladığında ne buck ne de bzl vardı.
      Bazel’in ilk sürümü 2015’te, Buck’ınki 2013’te çıktı.
      JS’de biraz NIH kültürü var ama burada bunun etkili olup olmadığını bilmiyorum. O dönemde iyi build araçları çok değildi; özellikle de alışılmışın dışında teknoloji yığını kullanan şirketler için.
    • OCaml’i özel olarak çok iyi bilmiyorum; ama adı geçenler arasında OCaml’i doğru derleyecek semantiğe gerçekten sahip build sisteminin yalnızca buck2 olduğunu anlıyorum.
      Özellikle önceden ocamldep çalıştırabilmek ya da iki kez derlemek gerektiğini biliyorum; buck2 bunu yapabiliyor, Bazel’de ise yanlış hatırlamıyorsam hack gerekiyor.
    • Bizim ekibin büyük bir OCaml kod tabanı ve ikili build sistemi var: buck2 ve dune.
      İkisi kabaca benzer. OCaml build araçlarını çağırma saf hızı açısından dune hızlı; çok şeyi yeniden build etmek gerektiğinde ve dağıtık build sistemi kullanıldığında buck2 kazanıyor.
      Büyük acı noktası LSP entegrasyonu. LSP sunucusunun bir dosyanın bağımlılıklarını bilmesinin tek yolu build olduğu için build sistemiyle sıkı sıkıya bağlı olması gerekiyor. dune’da her şey temiz şekilde sağlanıyor. buck2 ile de bir şekilde bağladık ama o kadar iyi değil.

  • Dune, build sistemi adı olarak açık ara en iyisi; yanına yaklaşan bile yok.

    • Doğru. “Build sistemini kontrol eden evreni kontrol eder.”
    • Yazılım hareketli kumların üzerine inşa edildiği için mi?

  • Daha iyi bir build sistemi yapmak için yola çıkıp “tesadüfen” daha iyi bir build sistemi yapmışlar; böyle tesadüflerin ortaya çıkma şekli gerçekten tuhaf.