Ubuntu paketlerini yeniden derleyerek %90 daha hızlı hale getirmek

 (gist.github.com/jwbee)
1 puan yazan GN⁺ 2025-03-19 | 1 yorum | WhatsApp'ta paylaş
  • Aynı jq kaynağı yeniden derlenip allocator değiştirildiğinde, 500 MB GeoJSON işleme süresi 4,606 saniyeden 2,428 saniyeye düştü ve Ubuntu ikili dosyasına göre 1,90 kat hızlandı
  • Benchmark, Ryzen 9 9950X üzerinde Alameda County Assessor parsel haritasında TotalNetValue < 193000 koşuluna uyan SitusCity değerlerini çıkarma yöntemiyle yapıldı
  • Yalnızca basit bir yeniden derleme bile %2–4 iyileşme sağladı; clang-18, -O3, -flto, -DNDEBUG kombinasyonu Ubuntu paketine kıyasla 1,20 kat performans verdi
  • Profilde bellek ayırma maliyeti belirgin göründüğü için TCMalloc, jemalloc, mimalloc karşılaştırıldı; LD_PRELOAD deneylerinde en hızlısı mimalloc oldu
  • Nihai mimalloc bağlantılı derleme, ayrı bir 2,2 GB JSON işleme örneğinde de 0,755 saniyeye karşı 1,424 saniye sonucu verdi; dağıtımın varsayılan derlemesiyle iş yüküne bağlı olarak büyük farklar oluşabiliyor

Temel iş yükü ve ölçüm yöntemi

  • Test hedefi JSON işleme aracı jq; girdi verisi Alameda County Assessor’ın parsel haritasını içeren 500 MB GeoJSON dosyası
  • Çalıştırılan sorgu, parsel listesinden TotalNetValue < 193000 koşulunu sağlayan öğelerin SitusCity değerini yazdırıyor
    • .features[] | select(.properties.TotalNetValue < 193000) | .properties.SitusCity
  • Ubuntu’nun varsayılan /usr/bin/jq dosya önbelleğe alınmış durumdayken yaklaşık 5 saniye sürdü; ayrıntılı benchmark hyperfine ile tekrarlı ölçüldü
  • Çalışma sırasındaki değişkenliği azaltmak için taskset -c 2 ile mantıksal CPU 2’ye sabitlendi
    • Bu ayar, CPU 0’da çalışan sistem kesmeleri ve CPU migration etkilerinden kaçınmak için kullanıldı

Aynı kaynağın basit yeniden derlemesi

  • Ubuntu’nun kullandığı jq kaynak kodu alındı ve ek bayrak olmadan configure ile derleme yapıldı
  • Bu basit yeniden derleme bile Ubuntu ikili paketinden yaklaşık %2–4 daha hızlı oldu
    • Yeniden derlenen ikili: ortalama 4,517 saniye
    • Ubuntu /usr/bin/jq: ortalama 4,641 saniye
    • Sonuç olarak yaklaşık 1,03 kat performans

clang ve optimizasyon bayraklarının uygulanması

  • Sonraki aşamada clang-18, daha yüksek optimizasyon seviyesi, LTO ve debugging/profiling ile ilgili bayraklar birlikte uygulandı
  • Performansı etkileyen temel bayraklar -O3, -flto, -DNDEBUG oldu
    • -O3, -O2den daha yüksek optimizasyon seviyesi kullanır
    • -flto, link-time optimization’ı etkinleştirir
    • -DNDEBUG, profilde belirgin görünen assertion maliyetini azaltır
  • Uygulanan configure örneği şöyle
    • CC=clang-18
    • LDFLAGS="-flto -g -Wl,--emit-relocs -Wl,-z,now -Wl,--gc-sections -fuse-ld=lld"
    • CFLAGS="-flto -DNDEBUG -fno-omit-frame-pointer -gmlt -march=native -O3 -mno-omit-leaf-frame-pointer -ffunction-sections -fdata-sections"
  • Bu derleme Ubuntu ikili dosyasından 1,20 kat daha hızlıydı
    • Optimize yeniden derleme: ortalama 3,853 saniye
    • Ubuntu /usr/bin/jq: ortalama 4,631 saniye

Allocator değiştirme deneyi

  • jq karmaşık bir C programı ve profilde en büyük maliyet bellek ayırma olarak göründü
  • Önce Ubuntu paketi olarak sunulan TCMalloc link edilerek yeniden derlendi
    • LDFLAGS içine -L/usr/lib/x86_64-linux-gnu -ltcmalloc_minimal eklendi
    • Yeniden derlenen ikili: ortalama 3,253 saniye
    • Ubuntu /usr/bin/jq: ortalama 4,611 saniye
    • Ubuntu ikili dosyasına göre 1,42 kat daha hızlı sonuç
  • Varsayılan Ubuntu ikili dosyasında yalnızca allocator’ı LD_PRELOAD ile değiştirmek de kısmi iyileşme sağlayabiliyor
    • Varsayılan: ortalama 4,601 saniye
    • TCMalloc preload: ortalama 4,082 saniye
    • Varsayılana göre 1,13 kat hızlanma

Dinamik preload ve THP ayarı

  • Ubuntu’nun sağladığı jemalloc, mimalloc, TCMalloc, LD_PRELOAD ile karşılaştırıldı
  • Bu karşılaştırma aşağıdaki ortam değişkenleri ayarlandıktan sonra elde edilen sonuçlara dayanıyor
    • MIMALLOC_LARGE_OS_PAGES=1
    • MALLOC_CONF="thp:always,metadata_thp:always"
    • GLIBC_TUNABLES=glibc.malloc.hugetlb=1
  • Sonuçta mimalloc en hızlısı oldu
    • Varsayılan glibc: ortalama 4,123 saniye
    • TCMalloc preload: ortalama 4,130 saniye
    • jemalloc preload: ortalama 3,510 saniye
    • mimalloc preload: ortalama 3,154 saniye
  • THP’nin etkinleştirilmesi glibc allocator, jemalloc ve mimalloc’un hepsine fayda sağladı
  • THP + mimalloc, THP + glibcten %31 daha hızlı, glibc varsayılanından ise %48 daha hızlı

mimalloc bağlantılı derlemenin nihai sonucu

  • Dinamik preload’un performans açısından ideal olmadığı düşünülerek, son aşamada mimalloc link edilip jq yeniden derlendi
  • Nihai derleme Ubuntu ikili paketinden 1,90 kat daha hızlıydı
    • mimalloc yeniden derlemesi: ortalama 2,428 saniye
    • Ubuntu /usr/bin/jq: ortalama 4,606 saniye
    • Her benchmark 10 çalıştırma üzerinden yapıldı
  • Aynı derleme başka bir uygulamada da kullanıldı
    • 13.000 dosyadaki 2,2 GB JSON işlendi
    • Paralelleştirme için rush kullanıldı
    • mimalloc ile yeniden derlenen jq: 0,755 saniye
    • Ubuntu paketi jq: 1,424 saniye
  • Bu ayrı örnekte de hız artışı neredeyse 2 kat oldu

İlgili okumalar

1 yorum

 
GN⁺ 2025-03-19
Hacker News yorumları

  • “Tek bir Ubuntu paketini yeniden derleyip bellek ayırıcısını değiştirerek %90 daha hızlı yapmak” gibi clickbait başlıklar, insanın TCP/IP üzerinden bir yumruk atası geliyor. Sonuçta sadece tek bir paketti ve iyileşmenin bir kısmı yeniden derlemeden bile kaynaklanmıyordu.
    Yine de jemalloc’u LD_PRELOAD ile bir programa enjekte edip malloc uygulamasını değiştirmeyi denemişliğim var; sonuçlar epey iyiydi. Performansı ölçmedim ama o uygulamanın bellek kullanımı dengelendi ve bellek sızıntısı gibi görünen sorun da çözüldü. Aslında bunun uygulamanın kendi sorunundan çok, standart mallocun bellek parçalanması olması kuvvetle muhtemel.

    • glibc bellek ayırıcısını araştırdım; bunun bellek parçalanması değil, çekirdeğe asla geri verilmeyen iş parçacığı başına önbellekler yüzünden olduğunu gördüm. free() çağrılsa bile, istisnai durumlar dışında dışarıdan bakıldığında bellek gerçekten serbest bırakılmıyor.
      İş parçacığı ve CPU çekirdeği sayısı arttıkça sorun daha da kötüleşiyor. Kolay çözümlerden biri, “sihirli” ortam değişkeni MALLOC_ARENA_MAX=2 ayarlayıp önbellek sayısını sınırlamak. Diğer yol, uygulamanın önbellekleri boşaltmak için düzenli olarak malloc_trim() çağırması; ama bu kaynak kod değişikliği gerektiriyor.
      https://www.joyfulbikeshedding.com/blog/2019-03-14-what-caus...
    • Doğru, ben de kısa süreliğine inanacak gibi oldum. Ama Ubuntu’yu hatanın nedeni gibi göstermek de kolay. Bana kalırsa Ubuntu paketleri bir araya getirme işini gayet iyi yapıyor ve gerçekten de stack protection seçenekleri açık şekilde derliyor.
      Buna karşılık, potansiyel olarak hatalı olabilecek -O3 ile derlememesi iyi bir şey. Performansın kritik olduğu bazı kısımlar için iyi olabilir ama tüm sistemi -O3 ile derlenmiş halde istemem.
    • Böyle genel bir iyileştirmenin tek bir yazıdaki açıklamayla elde edilebilmesi mümkün olmadığından, açıkça abartı gibi görünüyor. %90 daha hızlı ifadesi bir mikrobenchmark sayısı.
    • Önceden paketlenmiş ikili dağıtımların kaçının işletim sistemi ve donanım için en güvenli seçeneklerle derlendiğini, bu yüzden de mümkün olan en yüksek performansı veremediğini merak ediyorum. Açıkçası çoğunun böyle olduğunu düşünüyorum.
      Uzun zaman önce Mozilla’yı ve kendi Linux çekirdeğimi zevkime göre derlemeye başladım; genelde makul bir performans artışı elde ediyordum. Gentoo Linux dağıtımının bütün amacı da örneğin her şeyi kaynaktan optimize ederek derleyip performans artışı elde etmek.
    • Başlık clickbait, ama uygulama geliştiricilerini yeniden derlemeyi denemeye teşvik etmek iyi bir şey. Özellikle jq, grep, ffmpeg, ocrmypdf gibi bazı yaygın yardımcı araçlarda CPU darboğaz olduğunda; bu tür genel Unix araçları çoğu zaman belirli bir uygulama için değil, genel amaçlı derleme hedefleri olarak hazırlanıyor.

  • Mühendislik uzlaşmadır. Yazıdaki kazanımların çoğu bellek ayırıcısını özelleştirmekten geliyor. Bazı projelerin çok iş parçacıklı olduğunu; bir iş parçacığında ayırıp veriyi başka bir iş parçacığında yazdığını, üçüncü bir iş parçacığında da serbest bırakabildiğini unutmamak gerekir.
    Ayırıcı bununla başa çıkmak zorunda olduğundan, bir projede hız artışı sağlayan şey başka bir projede çakışmaya dönüşebilir. Yeniden ayırma stratejisi de sorun. Bazı programlar baştan ayırır ve bir daha malloca dokunmaz; bazıları ise sürekli serbest bırakıp yeniden alır. Parçalanmayı ne kadar iyi yönettiği, çalışma süresinin 10 saniye mi 10 yıl mı olduğu da önemlidir. Bazen ayırıcı seçimi, uzun vadeli kararlılık ile kısa vadeli hız arasındaki fark anlamına gelir.
    4K video test edip kareleri önbelleğe alan bir video düzenleyici geliştirirken çeşitli ayırıcıları denemiştim. Kare başına 32 MB ve 60 fps olduğunda, tek bir iz için saniyede neredeyse 2 GB eder. Hemen ayırıcı sınırlarına çarpıyorsunuz ve en azından varsayılan glibc ayırıcısının uzun vadeli kararlılık açısından en iyisi olduğunu fark ediyorsunuz. Ama kısa benchmark'larda en yavaşıdır.

    • Mimalloc, JEMalloc / TCMalloc gibi genel amaçlı bir ayırıcıdır. glibc oldukça kötü bir ayırıcı olarak bilinir; MIMalloc ya da güncel TCMalloc, yani Ubuntu ile varsayılan gelen sürüm olmayanlar, glibc'nin epey önündedir.
      Elbette hız artışının boyutu değişebilir, ama benchmark'lar genelde genel bir iyileşme gösterir. Bunun belirli bir uygulama için anlamlı olup olmadığı ise bambaşka bir mesele. Çakışmalar konusunda da, bunların hepsi genel amaçlı çok iş parçacıklı ayırıcılardır; glibc'den farklı davranmazlar ve hatalar glibc'de de aynı şekilde bulunabilir.
    • Ben de büyük 8K video kareleri ile çalışıyorum [1]. Karelerin kendisinden bahsediyorsanız, saniyede 60 ayırma hiçbir şey değildir. glibc'nin yavaş olmasının tek bir nedeni var: Her ayırma DEFAULT_MMAP_THRESHOLD_MAX değerini aşıyor ve 64 bit platformlarda bu değer 32 MiB olduğu için, mallopt kılavuzunda belgelendiği üzere glibc'yi bunları önbelleğe almaya ikna edemiyorsunuz.
      Her seferinde mmap ile doğrudan çekirdekten bellek istiyor ve munmap ile geri veriyor. Bu sistem çağrıları biraz yavaştır; benim durumumda ise ilk erişimde her bellek sayfası için page fault oluşturmanın maliyeti, performans hedefini tutturamayacak kadar yavaştı. Çözüm gerçekten basit: Video kareleri için genel amaçlı bir ayırıcının ya da mmapin üzerinde kendi serbest listenizi kullanmak yeterli. Tam olarak aynı boyuttaki ayırmalar çok kararlı biçimde tekrarlandığı için iyi çalışır.
      [1] UYVY formatında 64 MiB'den biraz küçük, I420 formatında ise 48 MiB'den biraz küçük.
    • Bu yorumu anlamak biraz zor. C'yi ya da C derleyicilerini pek bilmiyorum ama gist'in tamamını okudum, çok şey öğrendim ve değerli olduğunu düşündüm.
      Ancak bu üst yorumu okuyunca yazıyı tamamen yanlış mı anladım diye endişelendim. Üslubundan, gist'te söylenen şeyin kesinlikle yapılmaması gerektiğini ve bunun tüm bu karmaşıklıkları gözden kaçıran korkunç bir öneri olduğunu ima ediyormuş gibi geliyor. Asıl gist iyi bir yazı mı, geçerli noktaları var mı, yoksa hiçbir değeri yok mu anlamama yardımcı olabilir misiniz? Bu yorumu görmeden önce değerli olduğunu düşünmüştüm; ama bunu ayırt edecek kadar zeki olmadığımı fark ettim.
    • Bu yüzden dünyadaki her şey için tek bir ayırıcı kullanmak kötü bir fikir. Tek iş parçacıklı uygulamaların, hatta kaynak yönetimini sıkı yapan çok iş parçacıklı uygulamaların bile iş parçacığı güvenliği maliyetini ödemesi berbat.
    • Yaygın bir dert. Projeye uygun dili kullandığınızda, insanlar şu ya da bu nedenle başka bir dil kullanmanız gerektiğini söyler.
      Veriye uygun sıkıştırma algoritmasını kullandığınızda, insanlar neden aptal olduğunuzu ve başka bir algoritma kullanmanız gerektiğini anlatır. Yakın zamanda Dynamo'ya koymak için belirli uzun JSON dizelerini sıkıştırmam gerekti; popüler algoritmaların hepsini kapsamlı biçimde test ettim ve Brotli açık ara öndeydi. Yine de gelip geçen herkesin zlib'in daha iyi olduğunu söylemesini engelleyemedim. Bazen epey yorucu oluyor.

  • Gentoo Linux, aslında tam da böyle insanlar için, kendi Linux makinenizi kendi kullanımınıza göre optimize edebilmeniz amacıyla yapılmış bir dağıtım
    İlk kurulumdan sonra oldukça basit ve kullanımı kolay. Matrix’teki Gentoo Linux kanalında çok arkadaş edindiğimi hatırlıyorum; eğlenceli zamanlardı
    https://www.gentoo.org/
    İlginç bir bilgi: İlk ChromeOS temelde özel bir Gentoo Linux kurulumuydu. Hâlâ içeride Gentoo Linux kullanıp kullanmadığını bilmiyorum

    • Doğru, ama burada optimizasyonun mutlaka performans anlamına gelmediğini belirtmekte fayda var
      Gentoo’yu 20 yıldır kullanıyorum ama hiç performans için kullanmadım. Gentoo, nasıl davranmasını istediğinizi bildiğinizde harika ve sizi oraya ulaştırıyor
    • HN tarzı “install gentoo” memini ilk kez görüyorum. Kesinlikle daha rafine
      Gentoo’nun amacı, önceden derlenmiş ikili paketler yerine tüm programların kaynaktan derlendiği bir işletim sistemine sahip olmak. Bu, ileri düzey hız artışları ve özelleştirme sağlar; ancak kernel gibi en temel bileşenleri bile kaynaktan derlemeniz gerektiği anlamına gelir. Linux topluluğunda, zahmetli kurulum süreci nedeniyle çok karmaşık bir işletim sistemi olarak bilinir. Varsayılan Gentoo kurulumu doğrudan komut istemine önyüklenir; kullanıcı diski elle bölümlendirmeli, “Stage 3 tarball” denen paketi indirip açmalı, paketleri elle kurarak sistemi oluşturmalıdır. Yeni ya da deneyimsiz kullanıcılar, kurulum programına girip grafik ekran olmadığını gördüklerinde çoğu zaman ne yapacaklarını bilemez. /g/ üyeleri de sık sık Gentoo’nun değerini abartarak yeni kullanıcıları kurulum denemeye kandırır
    • 2003’ten beri sürekli Gentoo kullanıyordum; çok yakın zamanda, 2024 sonlarında Void Linux’u deneyince ona geçtim. Void’de son kullanıcının kaynaktan derleme yapabilmesi ilan edilmiş bir hedef ya da mimari özellik değil, ama bunu gerçekten çalışır hâle getirme ihtimali oldukça yüksek
      Bir iki kez tökezleyebilir, ama genel Linux deneyiminiz yeterliyse build recipe’lere girip düzeltmeniz, ihtiyacınıza göre çalışır hâle getirmeniz ve değişikliklerinizi upstream’e katkı olarak göndermeniz muhtemel. Bu, minimalizme takıntılı biçimde odaklanmanın ve her tür aşırı mühendislikten kaçınmanın sonucu. Gentoo kullandığım süre boyunca özlediğim şey de buydu. Gentoo’da hep diğer kullanıcılara pek faydası olmayacak biçimde USE flag’leri ve package mask’leriyle oynamak zorunda kalıyordum. Build sistemi o kadar karmaşıktı ki, yıllar içinde gerçekten öğrenip sorunları kök neden düzeyinde düzeltmek ve upstream’e katkı vermek çok zordu. Tüm sistemi kaynaktan derlemek istemiyor, ama dağıtımın sağladığı ikililerle doğrudan kaynaktan derlediğiniz paketleri birlikte kullanmak istiyorsanız Void ideal bir temel de olabilir
    • Gentoo’yu bir süre kullandım ama her şeyi sonsuza kadar kurcalama cazibesi yüzünden sonunda sistemi bozuyordum. Gentoo’nun hatası değil, benim hatam
      Sonra ArchLinux’a geçtim ve benim için genel olarak iyi oldu. Oldukça standart bir işlemci kullanıyorsanız Gentoo’nun o kadar büyük bir avantaj sağlayacağını sanmıyorum
    • Bildiğim kadarıyla Gentoo tabanlı ChromeOS’un yerini Android alıyor

  • Bunu yaparsanız yalnızca jq için değil, regex ayrıştırma bağımlılığı onigurama için gelen güvenlik güncellemelerinin de dışında kalırsınız. Geçmişte onigurama için güvenlik güncellemesi olmuştu; böyle bir şey tekrar olursa savunmasız kalabilirsiniz. jq, güvenilmeyen JSON’u ayrıştırmak için sık kullanılır
    İçerik “Güvenlik güncellemesi: çeşitli hatalı pointer dereference’ları, sınır dışı yazma bellek bozulması ve stack buffer overflow düzeltmeleri” şeklindeydi; ilgili olay CVE-2017-9224, CVE-2017-9226, CVE-2017-9227, CVE-2017-9228, CVE-2017-9229 hakkındaydı

    • Gentoo Prefix gibi bir kullanıcı alanı paket yöneticisi kullanırsanız bu özel build’i kurarken güvenlik güncellemelerini almaya devam edebilirsiniz
    • Yine de platforma göre derleyip derlememeye akıllıca karar veren bir paket yönetim sistemi fikrinin tohumu burada yok mu? Geride bırakmak için performans kazancı epey büyük görünüyor
    • Genel olarak doğru, ama bu örnekte yanlış. gist’te açıklanan build hâlâ onigurama’yı dinamik link ediyor. onigurama libonig5 adlı ayrı bir pakette yer alıyor ve normal şekilde güncellenecektir
    • Bu tür CVE’lerin genel olarak ne kadar uygulanabilir olduğunu merak ediyorum. Evdeki oda kapısını kullanınca kasa kapısının sağladığı güvenliği kaçırıyorsunuz demek gibi. Yanlış değil, ama bankadaki tüm kapıların kasa kapısı olmamasının da bir nedeni var
      CVE sisteminin değerini küçümsemeye çalışmıyorum, ama bulgular arasında gerçek etki açısından büyük farklar olduğunu da inkâr etmek zor
    • Kesinlikle doğru. Ayrıca allocator’ı değiştirip derleyici flag’lerini değiştirirseniz, belirli bir bellek yerleşimine dayanan saldırılara karşı tesadüfen bağışıklık da kazanabilirsiniz

  • Bu işlerle uğraşmayalı biraz oldu, ama hatırladığım kadarıyla upstream geliştiricilerin kullandığı flag’lerin ötesine geçtiğiniz anda tuhaf bug’lar ve bug çıktığında muazzam bir ilgisizlik satın almış oluyorsunuz. Burada kastettiğim dağıtım paketleyicisi değil, upstream geliştirici
    libc dışı malloc kullanmadım ama aynı ilkenin geçerli olacağını düşünüyorum

    • Birbirine zıt iki şey aynı anda doğru. Bir birey hiç farklı olmamaya çalışırsa en çok insanla aynı yoldadır ve kısa vadede başarı ihtimali en yüksektir
      Ama herkes böyle yaparsa bu bir monokültür olur; monokültür kırılgan ve kötüdür. Kod ancak farklı bağlamlarda, yani farklı platformlarda, derleyicilerde, seçeneklerde, kütüphanelerde vb. derlendiği için biraz olsun sağlamlaşır. Platformun ya da build flag’lerinin tesadüfen tuzağın hemen yanından geçip çoğunluğun dokunmadığı bir bug yine de bug’dır; onu bulup düzeltmek kod için daha iyidir. Bireyler olarak kodun genel olarak kırılgan olmak yerine sağlamlaşmasından hepimiz fayda görürüz
    • Uzun zamandır kendi emacs’imi kendim derliyorum ve henüz tuhaf bir bug’la karşılaşmadım. Güvensiz optimizasyonlardan kaçınırsanız sorun olmaz diye düşünüyordum
      Elbette -march=nativein gördüğüm başlıca iyileştirme olduğunu da sanıyordum; bu yazı bunun her zaman öyle olmadığını gösteriyor. Kayan nokta kullanan uygulamalarda pürüzlü alanların daha fazla olması da muhtemel görünüyor
    • Öte yandan bir optimizasyon birçok platformda tutarlı biçimde fayda sağlıyorsa, upstream geliştiriciyi bunu doğrudan uygulamaya ikna edebilirsiniz. Mutlaka tüm platformlar olması gerekmez; tek bir mimaride performans artışı yeterince büyükse o build için ayarları değiştirmeye gerekçe olabilir

  • Belirli bir iş akışında benchmark’ları iyi çıkan başka bir allocator ile yeniden derlemeye daha yakın

    • glibc malloctan daha iyi olan neredeyse her şey mümkün. Dağıtımların mimalloc veya jemalloc yerine hâlâ glibc malloc kullanması fiilen görev ihmali
    • glibc mallocın hangi iş yüklerinde iyi olduğu biliniyor mu ki?

  • Bu Rust tabanlı jq klonuyla performansının nasıl karşılaştırıldığını merak ediyorum
    cargo install --locked jaq
    Belirli bir CPU ailesine yönelik optimizasyonları açmak için RUSTFLAGS="-C target-cpu=native" de eklenebilir. cargo install, yazıda anlatılan türden kullanım için Rust’ın hakkı yeterince verilmeyen bir özelliği. Aracı kaynak koddan derlediği için, eski CPU’larla uyumluluk adına ikili dosyalara normalde dahil edilmeyen platforma özgü özellikleri veya komutları seçebilirsiniz. Depoyu klonlamanız ya da nasıl derleneceğini çözmeniz gerekmez; bunlar kendiliğinden gelir
    jaq[1] ve yq[2], jq kullanırken hızlı ve kolay bir performans artışına ihtiyaç duyduğumda tercih ettiğim seçenekler
    [1] https://github.com/01mf02/jaq
    [2] https://github.com/mikefarah/yq

    • Ara sıra jaq’ı jq ve gojq ile karşılaştırıyorum; AoC 2022 day 13 için kendi jq çözümümle test ediyorum
      https://gist.github.com/oguz-ismail/8d0957dfeecc4f816ffee79d...
      Hâlâ ikisinin gerisinde kalıyor
    • İnsanların bilmeyebileceği bir bonus olarak, depoyu doğrudan kullanmak istediğinizde cargo installda depo URL’si belirtebileceğiniz bir --git bayrağı da var. Herkese açık paket olmadığında ya da henüz yayımlanmamış en son commit’i istediğinizde kullanılabilir
      Daha önce birçok kez kullandım; özellikle de kişisel olarak aceleyle yaptığım araçları depoya push ettikten sonra, release süreci oluşturmadan veya binary’leri kendi makinelerime elle kopyalayıp derlemede kullanılan tam commit’i takip etmek zorunda kalmadan hızlıca kurmanın kolay bir yolu olarak işe yaradı

  • Bunu gerçekten yapacaksanız Ubuntu’nun istediği tam kaynak paketini indirtmeniz yeterli. Bu durumda apt-get source jq kullanılır
    Ardından paketin içine girip istediğiniz gibi yeniden derleyebilirsiniz. Dağıtım veya arşivleme için yeniden paketleyebilirsiniz de. Böylece bir yığın garip hata ve tutarsızlık elde etmek yerine upstream Ubuntu’ya çok daha yakın bir sonuç alırsınız

  • Başlık yanıltıcı. Daha hızlı hâle gelen sürenin %90’ı anlamına geliyor; gerçekte yaklaşık %45 daha hızlı
    Dili nasıl kullandığımızla ilgileniyorsanız biraz ilginç. Aynı sürede %90 daha fazla iş yaptığını söylemek de mümkün; bu, sık kullandığımız başka hız birimleriyle, örneğin mil/saat, kelime/dakika, bit/saniye ile uyumlu. Ama bilgisayar performansında sabit bir iş miktarının ne kadar sürdüğünü ölçme geleneği var. Muhtemelen genelde iş miktarı sabit olduğu, değişenin bekleme süresi olduğu için. Bu blog yazısında da durum tam olarak böyle, bu yüzden zaman paya yerleşiyor. Yazının kendisi çok ilginç ve iyi yazılmış, ama %90 hızlı değil

    • Daha da yanıltıcı olan, tüm paketleri %90 daha hızlı yapabileceği iması. Bu yalnızca belirli bir paket
    • Burada zaman birimi değil, işleme hızı birimi olan “90% faster” ifadesini kullanmak daha mantıklı gibi
      Ayrıca zaman birimi kullanacaksanız “faster” kelimesini kullanmazsınız. “45% less time” ile “45% faster” çok farklı iddialar ve ikisi de programlamanın içinde de dışında da anlamlı
    • İlgili yazı: https://randomascii.wordpress.com/2018/02/04/what-we-talk-ab...
    • Biraz daha düşününce neden yanıltıcı olduğunu anladım sanırım. Daha büyük değerdeki değişimi daha küçük değerin yüzdesi olarak söylüyor olmamızdan kaynaklanıyor
      “Bir şeyi %N azalttık” dediğimizde genellikle o %N’nin başka bir değerin değil, azaltılan şeyin kendisinin %N’si olduğu varsayılır
    • Doğru gibi. Paketin, yani kodun %45 daha hızlı olduğunu söyleyebilir veya ayrıştırma işleme hızını %90 artırdığınızı söyleyebilirsiniz. Ama ikisini karıştırınca kafa karıştırıcı oluyor

  • Böyle basit bir değişiklikle büyük bir hız artışı elde edilebildiğini okuyunca aklıma ilk gelen, bunu jq yazarlarına bildirmek gerektiğiydi. Dikkat edilmesi gereken tuzaklar olabilir; test ettikten sonra herkes için daha hızlı hâle getirebilirler
    Sonuç ne olursa olsun, kısaca haber vermek faydalı görünüyor. Ama yazıda bu seçenek hiç değerlendirilmemiş gibi, buradaki yorumlarda da göremiyorum. Bir şeyi mi kaçırıyorum?

    • Intel Clear Linux’un komut kümesindeki daha yeni op kodlarını kullanarak benzer kazanımlar elde edip etmediğini merak ediyorum
      Orada da glibc allocator’ın standart olup olmadığını bilmiyorum
      https://en.m.wikipedia.org/wiki/Clear_Linux_OS