Rust std fs Python’dan daha mı yavaş? Hayır, sorun donanımda

 (xuanwo.io)
2 puan yazan GN⁺ 2023-11-30 | 1 yorum | WhatsApp'ta paylaş
  • Çıkış noktası, Apache OpenDAL’in Python bağlamalarında dosya okumanın Python’un yerleşik open().read() çağrısından daha yavaş olduğuna dair bir bildirimdi; ancak darboğaz OpenDAL’in ya da PyO3’nün kendisi değildi
  • 64MiB dosya okuma benchmark’ında python-fs-read yaklaşık 15~19ms, Rust std::fs ve C uygulaması ise yaklaşık 23ms olarak ölçüldü; bu da Rust/C’nin Python’dan yavaş göründüğü anlamına geliyordu
  • strace, eBPF, perf izlenince farkın, read sistem çağrısının hedef tamponunun sayfa içinde bulunduğu ofset ile bağlantılı olduğu görüldü; 0x10 civarında performans düşüşü yeniden üretilebildi
  • AMD Ryzen 9 5900X, Ryzen 7 5700X, Ryzen 9 5900HX serilerinde benzer olgu doğrulandı; çekirdek içindeki _copy_to_iter içinde rep movsb yürütme performansı temel ipucuydu
  • Python’un doğası gereği daha hızlı olması değil, AMD Zen 3’ün FSRM/rep movsb ile ilgili CPU hatası ve bellek ofsetinin tesadüfen bu sonucu yaratmasıydı; jemalloc iyileşmesi de ayırıcının kendisinden değil, farklı ofsetten kaynaklanıyordu

OpenDAL Python bağlamalarında başlayan tuhaf benchmark

  • Apache OpenDAL, farklı depolama servislerinde verileri birleşik bir şekilde okumak ve yazmak için kullanılan bir veri erişim katmanıdır; Python bağlamaları PyO3 üzerinden sağlanır
  • Kullanıcı, OpenDAL Python bağlamasıyla 150MB dosya okuyan kodun Python’un yerleşik dosya okumasından yavaş olduğunu bildirdi
    • Python yerleşik open(...).read() 100 kez: 4.470868484000675
    • OpenDAL Python bağlaması 100 kez: 8.993250704006641
  • Basitleştirilmiş 64MiB dosya okumasında da OpenDAL bağlaması daha yavaştı
    • python-fs-read: ortalama 15.9ms
    • python-opendal-read: ortalama 32.9ms
    • Python yerleşik okuma, OpenDAL bağlamasından 2.07 kat daha hızlı ölçüldü

İz sürme Rust OpenDAL ve std::fs’e kadar indi

  • Aynı mantık Rust’ın OpenDAL fs servisiyle uygulandığında da Python yerleşik okumadan yavaştı
    • rust-opendal-fs-read: ortalama 23.8ms
    • python-fs-read: ortalama 15.6ms
    • Python yerleşik okuma, Rust OpenDAL uygulamasından 1.52 kat daha hızlı ölçüldü
  • OpenDAL’in fs servisi Rust std::fs kullandığı için, OpenDAL’in kendi maliyetini kontrol etmek üzere std::fs tabanlı ayrı bir uygulama yazıldı
  • Rust std::fs doğrudan uygulamasında da aynı akış sürdü
    • rust-std-fs-read: ortalama 23.1ms
    • python-fs-read: ortalama 15.2ms
    • Python yerleşik okuma, Rust std::fs’ten 1.52 kat daha hızlı ölçüldü

strace ile görülen sistem çağrıları ve mmap

  • strace analizinde hem Rust hem Python’un büyük tampon ayırmaları için mmap kullandığı görüldü
  • Rust std::fs çalıştırması /tmp/file dosyasını açıyor, 64MiB’ı bir kez okuyor, EOF kontrolü için read çağırıyor ve ardından kapatıyordu
  • Python yerleşik okuma newfstatat, ioctl, lseek gibi daha fazla sistem çağrısı yürütse de toplam süre daha kısaydı
  • mmap(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) çağrısı dosya eşleme için değil, anonim bellek ayırma için kullanılıyordu
    • 67112960, 64MiB’a 4KiB eklenmiş boyut
    • MAP_ANONYMOUS, dosyayla ilişkisi olmayan bellek ayırma anlamına gelir
  • Rust’ın x86_64-unknown-linux-gnu varsayılan derlemesi glibc’nin malloc’unu kullanır; glibc büyük ayırmalarda mmap kullanabilir

jemalloc ile hızlanan Rust ve tersine dönen ara sonuç

  • Rust genel ayırıcısı jemallocator::Jemalloc olarak değiştirildiğinde Python’dan hızlı hale geldi
    • rust-std-fs-read-with-jemalloc: ortalama 9.7ms
    • python-fs-read: ortalama 15.8ms
    • jemalloc kullanan Rust uygulaması Python’dan 1.64 kat daha hızlı ölçüldü
  • Bu aşamada neden mmap ya da varsayılan bellek ayırıcısı gibi görünüyordu; ancak sonraki güncellemede yorum düzeltildi
  • 2023-12-01 güncellemesine göre fark, jemalloc, pymalloc, mimalloc’un glibc malloc’tan doğası gereği daha hızlı olmasından kaynaklanmıyordu
  • Gerçek fark, ayırıcının oluşturduğu tamponun sayfa içi ofsetinden geliyordu
    • rust-std-fs-read: mmap başlangıç adresinden 0x10 ofsetinde okuma
    • rust-std-fs-read-with-jemalloc: mmap başlangıç adresinden 0x740 ofsetinde okuma
  • Sorunlu aralık sayfa içindeki 0x00..0x10 aralığı olarak toparlandı; aynı sorun jemalloc ile de yeniden üretilebiliyor

Yazılım ayarlarından çok cihaza bağlı yeniden üretilebilirlik baskındı

  • Tartışma ilerledikçe Rust’ın Python’dan yavaş olduğu olgunun özellikle yazarın makinesinde belirgin olduğu doğrulandı
  • Yazarın CPU’su AMD Ryzen 9 5950X 16-Core Processor idi; bellek yapılandırması DDR4 3200 MT/s 16GB DIMM’di
  • Çeşitli ayarlar değiştirilse de göreli performans farkı ortadan kalkmadı
    • Linux çekirdeği mitigations=off yeniden açıldığında sonuç değişmedi
    • Transparent Hugepage always, madvise, never olarak değiştirildiğinde mutlak değerler değişti, ancak göreli oran korundu
    • core_affinity ile belirli bir CPU çekirdeğine sabitlendiğinde de sonuç aynıydı
  • eBPF tabanlı read sistem çağrısı gecikmesi ölçümünde de Rust tarafı daha yavaştı
    • Python read file: 8,134,049ns
    • Rust std::fs read file: 24,636,975ns
  • Gözlemlere göre farkı yalnızca OpenDAL, PyO3 veya Rust standart kütüphanesiyle açıklamak zordu; süre farkı zaten sistem çağrısı seviyesinde açılmıştı

C uygulamasında ortaya çıkan bellek ofseti ipucu

  • Aynı 64MiB dosya okuması C fopen/malloc/fread ile uygulandığında da Python’dan yavaştı
    • c-fs-read: ortalama 23.8ms
    • python-fs-read: ortalama 19.1ms
    • Python yerleşik okuma, C uygulamasından 1.25 kat daha hızlı ölçüldü
  • strace -e raw=read,mmap ile işaretçi adresleri kontrol edilince C ve Python’un tampon başlangıç ofsetlerinin farklı olduğu görüldü
    • C: mmap dönüş adresinden 0x10 ofsetinde read
    • Python: mmap dönüş adresinden 0x30 ofsetinde read
  • C uygulamasında ofset aynı şekilde ayarlandığında performans belirgin ölçüde iyileşti
    • c-fs-read-with-offset: ortalama 8.9ms
    • Python’dan 2.15 kat, mevcut C uygulamasından 2.68 kat hızlı
  • Bu sorun AMD Ryzen 9 5900X ve AMD Ryzen 7 5700X üzerinde de yeniden üretildi
  • Rust topluluğundaki Std::fs::read slow? başlığında da benzer bir olgu bildirildi ve bellek bölgesi ofseti ile sistem çağrısı performansı arasındaki ilişkiye işaret edildi

perf analizinin işaret ettiği rep movsb

  • Bir çekirdek geliştiricisi AMD Ryzen 9 5900HX üzerinde c-fs-read ve ofset uygulanmış sürümü yeniden üretip perf ile analiz etti
  • Ofsetin olup olmamasına göre L1-dcache-prefetches ve L1-dcache-loads değerleri büyük ölçüde değişiyordu
    • Ofset yok: L1-dcache-loads yaklaşık 127,845,213, L1-dcache-prefetches yaklaşık 1,843,493
    • Ofset var: L1-dcache-loads yaklaşık 13,965,813, L1-dcache-prefetches yaklaşık 395,578
  • Sıcak nokta, çekirdeğin read yolunda shmem_file_read_iter → copy_page_to_iter → _copy_to_iter zincirinde yer alıyordu
  • _copy_to_iter içindeki temel assembly rep movsb idi ve örneklerin çoğu bu komutta yoğunlaşıyordu
  • Sonraki analizlerde, L1 prefetch’in kendisinden ziyade, sayfaya hizalı verilerde rep movsb performansının kötü olması ve sayfa hizası bozulduğunda iyileşmesi daha önemli bir ipucu olarak değerlendirildi

FSRM ve AMD Zen 3 sorunu

  • Paylaşılan Ubuntu glibc hata raporu Terrible memcpy performance on Zen 3 when using rep movsb da rep movsb performans sorununu ele alıyor
  • Rapordaki örnek, 2113 bayt kopyalamada rep movsb yolunun yaklaşık 3.2GB/s gösterdiğini, boyut 2111 bayta değiştirildiğinde ise 100GB/s üzerine çıktığını açıklıyor
  • FSRM, Fast Short REP MOV’un kısaltmasıdır; rep movsb ve rep movsd komutlarını hızlandırmaya yönelik bir özelliktir
  • FSRM Intel’de başlayan bir özellik olup AMD’ye de getirildi; desteğini ilan eden CPU’larda glibc varsayılan olarak FSRM kullanır
  • Dolayısıyla Python’un C/Rust’tan doğası gereği daha hızlı olması değil, AMD CPU hatası nedeniyle C/Rust’ın okuma yolunun belirli bellek ofsetlerinde yavaşlaması söz konusudur

Güncelleme: AMD’nin haberdar olup olmadığı ve glibc yanıtı

  • 2023-12-01 güncellemesine göre AMD’nin bu hatadan 2021’den beri haberdar olduğu anlaşılıyor
  • Yazı yayımlandıktan sonra çok sayıda okur bağlantıyı AMD’ye ilettiği için AMD’nin sorundan haberdar olduğu düşünülüyor
  • Yazar, AMD’nin bu hatayı amd-ucode içinde sorumluluk alıp düzeltmesi gerektiğini düşünüyor; ancak doğrulanmamış bilgilere göre Zen 3’te amd-ucode düzeltmesi zor olabilir
  • Gerçekçi umut, glibc’nin gerektiğinde FSRM’i devre dışı bırakması yönünde
  • glibc tarafında x86: Improve ERMS usage on Zen3 çalışması devam ediyor

Yeniden üretim kodu ve ilgili kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-30
Hacker News yorumları

  • REP STOS/MOV’un hızlı olduğunu ve memset/memcpy için kısa komut dizileri olarak kullanılabileceğini gösteren iki ayrı özel CPU özellik bayrağı bile var.
    On yıllardır her yeni CPU neslinde optimizasyon rutinlerini elle yeniden yazma eziyeti sürüyor; hâlâ böyle bir durumda olmamız, bunun CPU tedarikçilerinin zamanlama test paketlerinde yer alması gerekmez miydi diye düşündürüyor.

    • Tamamen tahmin ama son anda ya da piyasaya çıktıktan sonra gelen bir mikrokod güncellemesiyle eklenen bir hata düzeltmesinin etkisi olabilir gibi görünüyor.
      Sayfa hizalı hızlı rep movs ile ilgili bir sorun olmuş ya da bir saldırıya açık olduğu için devre dışı bırakılmış olabilir.
    • Doğru anladıysam, bunun belirli bir derleme zamanı derlemesi için iki yürütülebilir dosya üretmek gerektiği anlamına mı geldiğini, yoksa belirli bir donanım üzerinde derlemek gerektiği anlamına mı geldiğini merak ediyorum.
      Düzeltmenin nasıl olması gerektiğini, çalışma zamanı denetimi gibi bir şey gerekip gerekmediğini bilmiyorum.
    • CPU tedarikçisinin kendi CPU’sunu en iyi kendisinin bileceğini düşünmek kolay.
      Daha hızlı bir “yazılım” uygulaması varsa REP MOVS’un en azından mikrokod içinde aynı işi yapar hâle getirilmemesinin nedenini merak ediyorum.

  • İlgili glibc hatası burada. Ancak bu taraf Zen 4: https://sourceware.org/bugzilla/show_bug.cgi?id=30994

  • İlk başta yazıyı okuyunca yazarın std::fs’i yanlış kullandığını söyleyip dalga geçmeye hazırlanmıştım; ama aslında hata ayıklama tavşan deliği ve gizemle ilerleyen keyifli bir yazı çıktı.
    İyi yazılmış ve çok ilginçti.

    • Gerçekten çok iyi bir yazıydı. Test programı yazıp katmanları tek tek soyarak ilerleyen hata ayıklama yaklaşımı zekiceydi; sonuç ilginç ve beklenmedikti, yazı da açık olduğu için takip etmesi kolaydı.

  • Çıkış noktası biraz kafa karıştırıcı. Saf Python koduyla yerel C/Rust kodu karşılaştırılmıyor; yerel kodun üzerindeki bir Python sarmalayıcısı olan Python dosya okuma yöntemiyle, başka bir yerel kod sarmalayıcısı olan OpenDAL karşılaştırılıyor.
    Performans farkı olması hâlâ ilginç, ama bunu “Python’dan daha yavaş” diye ifade etmek epey tuhaf. Python standart kütüphanesinin tamamının saf Python ile yazıldığını mı bekliyorlar diye düşündürüyor. Aksine, Python standart kütüphanesindeki fonksiyon uygulamalarının yerel olduğunu ve tek tek oldukça optimize edilmiş olacağını beklerim.
    Sonucun yerel kodun çalışma biçimiyle ilgili olması şaşırtıcı değildi; ama somut yanıt beklenmedikti. Yalnızca başlangıç kısmı kafa karıştırıcıydı; yazının kendisi ise çok ilginçti.
    Ayrıca “C is slower than Python with specified offset” başlığı da ana dili İngilizce olan biri için “ofset belirtilmiş olsa bile C, Python’dan daha yavaş” gibi okunuyor. Oysa gerçekte bunun tersi kastedilmişti: Python’da kullanılan ofset C’de de belirtilince C daha hızlı olmuştu.

    • Neden kafa karıştırıcı olduğunu pek anlamıyorum.
      Dosya okumak gibi basit bir işin Rust standart kütüphanesinde Python standart kütüphanesinden daha yavaş olması şaşırtıcı. Bu Python standart kütüphanesi çağrısının C ile yazıldığını bilseniz bile, Rust standart kütüphanesi çağrısının da benzer hızda olmasını beklersiniz.
      Bu yüzden normalde kullanımın yanlış olduğunu ya da Rust standart kütüphanesinde garip bir davranış olduğunu beklersiniz; ama bu sefer ikisi de değildi, belirli donanımlarda ayırma hizalamasına bağlı oluşan bir performans uçurumuydu.
      Dosya sistemi okumanın Python’da iyi optimize edilmiş olmasını bekleriz; ama Rust’ta da aynısını düşünürüz. Bu yüzden Rust tarafının çok daha yavaş olması şaşırtıcıydı; özellikle de donanıma ve ayırıcıya bağlı olması daha da şaşırtıcıydı.
    • Python yavaş olduğunda yavaş bir dil diye eleştirilirken, hızlı olduğunda “gerçek Python değil” gerekçesiyle kabul görmemesini anlamıyorum.
      Python ile yazdığım kod hızlıysa benim için Python hızlıdır. Uygulamanın başka bir dilde yazılmış olması mı yoksa başka bir neden mi olduğu pek önemli değil.
    • “Tek tek oldukça optimize edilmiş” olmasını beklemek için ne sebep var, bilmiyorum.
      Orijinal yazıda olan şey neredeyse tamamen tesadüf. CPython’ın C kodu const tutarlılığını bile pek umursamaz; dinamik bellek ayırma ve yardımcı/kolaylık çağrıları çoktur. Aritmetik gibi şeyler bile dinamik bellek ayırır.
      CPython ile çalışma deneyiminiz varsa genelde performansının iyi olmasını beklemezsiniz. Performansı iyileştirmek istediğinizde, onun sunduğu özellikleri baypas etmeye çalışırsınız.
      Ayrıca Python’un bir standardı yoktur; bu yüzden teknik olarak standart kütüphanesi de yoktur ve birlikte dağıtılan kütüphanelerin çoğu Python ile yazılmıştır. Bazıları C ile yazılmıştır ama o C kodlarının içinde bile aslında Python kodunu mekanik olarak C’ye taşımış olanların oranı epey yüksektir. Örneğin Python’un ikili arama uygulaması önce Python ile yazılmış, daha sonra Python C API kullanılarak C’ye çevrilmiştir.
      Beklenebilecek şey, işletim sistemi işlevlerine basitçe eşlenen özelliklerin nispeten ince bir sarmalayıcıya sahip olmasıdır. Yani dosya okuma özünde doğrudan sistem arayüzüne girdiği için çok fazla bağlama kodu gerektirmemelidir.
    • Uyarı için teşekkürler. Başlığı düzelttim.
    • Çıkış noktası şu: “Python Rust’tan hızlı” gibi bir ifade kullanırsanız doğru olmasa bile sayfa görüntülemesi getirir.
      Benzer yazılar onlarca kez yayımlandıktan sonra herkes bunu fark etti.

  • Yazının kendisi harika ve bu meseleyle ilgili çok sayıda ilginç bilgi içeriyor.
    Ancak daha çok ilgimi çeken ve endişelendiren kısım, sorunun nasıl raporlanıp kayda geçirildiği ve iletişimin nasıl yürütüldüğü.
    Raporlama Discord üzerinden yapılıyor; bu kapalı bir ortam, indekslenmiyor, araması zor ve kalıcı olarak korunmuyor. Tartışmalar Discord ve Telegram’da yapılıyor; bu bağlamda Telegram daha da kötü olabilir.
    Bu blog yazısı ve GitHub deposu, geriye kalan tek iz. Xuanwo blogda yazmamış olsaydı zaman akışının içinde kaybolup gidecekti. Oldukça ilginç bir durum.

    • Kapalı bir platform olduğu doğru ve iyi değil. Ama indekslenmediği ya da aranamadığı yönündeki suçlamayı kabul etmek zor.
      Varsayılan olarak herkese açık erişilebilen kayıtları indeksleyip aranabilir hâle getiren mesajlaşma uygulaması neredeyse yok. Tüm IRC sunucuları herkese açık log sağlamıyor; Matrix grupları da öyle. Oradaki tartışmaların neden zaman akışında kaybolmadığını düşündüğünüzü bilmiyorum.
      Herkese açık log sunulabilmesinin nedeni kapalı olmaması değil, loglamaya izin veren bir API olması. Telegram’da da böyle bir API var ve bizim tartışma grubumuzun aranabilir kayıtları burada görülebiliyor: https://luoxu-web.vercel.app/#g=1264662201
      Herkese açık indekslemenin olmaması çoğunlukla gizlilik yüzünden; platformun kapalı olmasından değil.
    • USENET’in çöküşüne her üzüldüğümde “artık Discord var ya” cevabını kabul etmememin nedeni tam da bu.
      Eskiden tüm gönderiler DejaNews’te, daha sonra Google’da tertemiz aranabiliyordu.
      İnternet/WWW yığını ve temel programlama araçları ile kütüphaneleri kadar önemli açık kaynak projelerinin kritik iletişimi açık standartlar üzerinden yürümeli.

  • Bu hafta okuduğum yazılar arasında en ilginç olanıydı. Harika bir derleme.

  • Yapılacak bariz şey, copy_user_generic kernel metoduna bir yama göndermek gibi görünüyor.
    Sorunlu CPU algılandığında ve bellek hizalamasının yavaşlamasına yol açan bug tetiklendiğinde farklı bir bellek kopyalama uygulaması kullandırmak yeterli olur.

    • Bariz değil. Mikrokod ile düzeltilebiliyorsa, kernel’e fiilen yazılım yamalanabilir bir sorunun düzeltme kodunu serpiştirmektense insanların güncellenmiş mikrokodu kullanmasını sağlamak daha iyi görünüyor.
      Kernel deneyimi olmayan birinin kabul ettirebileceği bir düzeltme önemsiz olmayacaktır. Daha da önemlisi, geçici çözümün hangi şekilde etkinleştirileceği de açık değil. Muhtemelen en iyisi açılışta ölçüm yapmak olur; aksi hâlde hangi model ve stepping’lerin etkilendiğini nasıl bileceğimiz belirsiz.
    • Önemsiz bir düzeltme değil. AMD’nin sayfa hizalamasına yakın adreslerde aliasingin neden bozulduğunu anlaması gerekiyor; bu yüzden düzeltmenin mikrokod tarafında olması muhtemel.
      Yazılım tarafındaki hafifletme de karmaşık olacaktır. Çünkü kernel, ERMS kullanılamadığında normalde alternatif yolda kullandığı vektör komutlarını gerçekte kullanamaz.

  • jemalloc, 2018’e kadar Rust’ın varsayılan ayırıcısıydı.
    https://internals.rust-lang.org/t/jemalloc-was-just-removed-...

  • “Rust geliştiricileri performansı artırmak için jemallocator'a geçmeyi düşünebilir” kısmını merak ediyorum
    Herkesin neredeyse bedavaya performans artışı elde edip edemeyeceğini, yoksa dikkat edilmesi gereken noktalar olup olmadığını bilmiyorum. C kod tabanlarının da bundan fayda görüp görmeyeceğini, şu anda sadece kaçırdığımız bir performans olup olmadığını merak ediyorum

    • jemalloc kullanınca MADV_FREE nedeniyle gözlemlenebilirlik sorunları çıkabileceğini bilmek gerekir. htop artık gerçekten kullanımda olan belleği doğru şekilde göstermez
      https://github.com/jemalloc/jemalloc/issues/387#issuecomment...
      https://gitlab.haskell.org/ghc/ghc/-/issues/17411
      Görünüşe göre artık jemalloc, MADV_FREE sonrasında 10 saniye sonra MADV_DONTNEED çağırıyor: https://github.com/JuliaLang/julia/issues/51086#issuecomment...
      Bu yüzden bu sorunu “düzeltmiş” oluyor, ancak belleğin serbest bırakıldığı an ile bunun htopta gözlemlendiği an arasında kafa karıştırıcı bir gecikme oluşuyor
      Öte yandan https://jemalloc.net/jemalloc.3.html sayfasına göre opt.muzzy_decay_ms = 0 ayarlanarak gecikme kaldırılabiliyor
      Yine de musl yazarı, jemalloc'ı varsayılan yapmak konusunda çekimser: https://www.openwall.com/lists/musl/2018/04/23/2
      Ana fikir; ciddi şişkinlik, ASLR'nin zayıflaması ve bellek kullanımını önemsemeden mümkün olduğunca hızlı olmaya odaklanan optimizasyon sorunları olduğu. Yukarıdaki ayarlarla bir ölçüde hafifletilebilir, ancak performansa mı bellek kullanımına mı odaklanılacağına dair genel eğilim muhtemelen hâlâ bir ödünleşim olarak kalacaktır
    • Bunun neredeyse bedavaya kaçırılan bir performans olduğunu düşünüyorum. İkili dosya boyutunun biraz artması gibi bir maliyeti var
      Her durumda mutlaka daha hızlı olmayacaktır, ama büyük çoğunlukta daha hızlı olur. Rust da eskiden varsayılan olarak jemalloc kullanıyordu, ancak bunu varsayılan olarak şaşırtıcı bulanlar olduğu için değiştirildi
    • Varsayılan olmayan bir ayırıcıya geçmek her zaman performansı artırmaz
      İş yüküne büyük ölçüde bağlıdır; bu yüzden profil çıkarma ve kıyaslama gerekir. Yine de C/C++/Rust gibi düşük seviyeli dillerin bu ayırıcıları seçebilmesi gerekir
      Dikkat edilmesi gereken bir nokta ikili dosya boyutudur. Özel ayırıcılar yürütülebilir dosyaya ek baytlar ekler
    • Rust eskiden varsayılan olarak jemalloc kullanıyordu, ancak 2018 civarında tekrar sistem malloc'ına döndü[0]
      Şu anda Rust'ta GlobalAlloc trait'i ve #[global_allocator] özniteliği var; dolayısıyla uygulama isterse ayırıcı olarak jemalloc kullanabilir. Kullanıcının bunu LD_PRELOAD gibi yöntemlerle geçersiz kılıp kılamayacağından pek emin değilim
      jemalloc her iş yükü ve kullanım senaryosu için her zaman en iyi seçenek değildir. Sistem ayırıcıları çoğu zaman mükemmel olmaktan uzaktır, ama en azından genel amaçlı ayırıcılar olarak yaygın biçimde test edilmiştir
      [0] https://github.com/rust-lang/rust/issues/36963
    • Performans, bir programın “yavaş”tan “hızlı”ya geçtiği tek boyutlu bir ölçek değildir. Her zaman başka unsurlar da devrededir
      jemalloc bazı uygulamalar için doğru tercih olabilir, ancak başka durumlarda başka bir ayırıcı daha hızlı olabilir. Ya da daha yavaş olsa bile daha az kirli bellek, daha iyi gözlemlenebilirlik veya belirli güvenlik garantileri gibi hedeflere daha uygun olabilir

  • Bunu uygun kişilere gönderdim

    • AMD tarafına gönderdiğin anlamına mı geliyor?