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ş

OpenDAL Python binding’i Python’dan daha mı yavaş?

  • OpenDAL, çeşitli depolama servislerinden veriyi verimli şekilde almayı sağlayan bir veri erişim katmanıdır.
  • OpenDAL’in Python binding’inin Python’ın kendisinden daha yavaş olduğuna dair bir rapor vardır.
  • Bunun nedeni olarak Python iç önbelleği, dosya okuma hızlandırması ve PyO3’ün ek overhead’i gibi etkenler öne sürülür.

OpenDAL Fs servisi Python’dan daha mı yavaş?

  • Bu, Rust, OpenDAL, Python ve PyO3 gibi birden çok unsurun dahil olduğu bir sorundur.
  • Rust ile uygulanan OpenDAL fs servisinin de Python’dan daha yavaş olduğu görülür.

Rust std::fs, Python’dan daha mı yavaş?

  • OpenDAL, fs servisini std::fs üzerinden uygular.
  • Rust’un std::fs kullanan uygulamasının da Python’dan daha yavaş olduğu doğrulanır.

Rust std::fs, Python’dan daha mı yavaş? Gerçekten mi!?

  • Rust std::fs’in Python’dan daha yavaş çıktığı sonuca şüpheyle yaklaşılır.
  • Sistem çağrılarını analiz etmek için strace kullanımı öğrenilir.
  • strace sonuçları incelendiğinde, her ikisi de mmap kullanmasına rağmen Python’ın neden daha hızlı olduğu bulunamaz.

Burada neden mmap kullanılıyor?

  • mmap, yalnızca dosyayı belleğe eşlemek için değil, büyük bellek alanları ayırmak için de kullanılır.
  • malloc ile bellek istendiğinde, glibc belleği ayırmak için mmap kullanır.

Python, Rust ile aynı bellek ayırıcısını mı kullanıyor?

  • Python, küçük tahsisler için optimize edilmiş pymalloc adlı bir bellek ayırıcı kullanır.
  • pymalloc küçük nesneler için optimize edilmiştir; büyük tahsislerde ise PyMem_RawMalloc() ve PyMem_RawRealloc() kullanılır.

Varsayılan bellek ayırıcısıyla Rust, Python’dan daha mı yavaş?

  • Sorunun kaynağının mmap olduğu düşünülür.
  • jemalloc’a geçirilen Rust programının Python’dan daha hızlı çalıştığı görülür.

Rust neden sadece benim bilgisayarımda Python’dan daha yavaş!

  • Rust’un Python’dan daha yavaş çalışması yalnızca belirli bir bilgisayarda ortaya çıkar.
  • CPU ve bellek hakkında ayrıntılı bilgi verilir.
  • CPU zafiyet azaltımları, Transparent Hugepage ve CPU çekirdek affinity’si ayarlansa da sonuç değişmez.
  • eBPF programı kullanılarak Rust’un sistem çağrısı düzeyinde de Python’dan daha yavaş olduğu doğrulanır.

C, Python’dan daha mı yavaş?

  • C ile yazılan sürümün de Python’dan daha yavaş olduğu görülür.

C, Python’dan daha mı yavaş? Belirlenmiş offset olmadan!

  • Bellek bölgesi offset’lerinde fark olduğu fark edilir ve offset ayarlanarak C programının hızı artırılır.
  • AMD Ryzen CPU’da belirli bir offset olmadan performans düşüşü yaşandığı doğrulanır.

AMD Ryzen 9 5900X, belirlenmiş offset olmadan mı yavaş!

  • Bunun CPU ile ilgili bir sorun olduğu doğrulanır ve tartışmaya bir kernel geliştiricisi katılır.
  • perf ile yapılan profillemede de offset olmadığında performans düşüşü yeniden doğrulanır.

GN⁺ görüşü: Bu yazıdaki en önemli nokta, Rust ve C’nin belirli donanım ortamlarında Python’dan daha yavaş çalışabilmesi ve bunun bellek tahsisi ile CPU’nun belirli çalışma biçimlerinden kaynaklanabilmesidir. Yazı, yazılım performansını etkileyen çeşitli unsurları araştırma süreci üzerinden donanım ile yazılım etkileşiminin ne kadar karmaşık olabileceğini gösteriyor. Bu tür incelemeler, yazılım mühendisliğinde ortaya çıkabilecek beklenmedik sorunları çözmek için önemli dersler sunuyor.

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-30
Hacker News görüşleri

  • Kafa karıştırıcı ön kabule dair görüş

    Bir kullanıcı, Python standart kütüphanesindeki fonksiyonların saf Python ile yazıldığını sanmanın kafa karıştırıcı olduğunu belirtiyor. Python'un dosya okuma metodlarıyla OpenDAL'in de yerel kodu saran Python sarmalayıcıları olması nedeniyle performans farkını ilginç buluyor, ancak bunu "Python'dan daha yavaş" diye ifade etmenin tuhaf olduğunu düşünüyor. Python standart kütüphanesi fonksiyonlarının yerel kodla yazılmış ve ayrı ayrı optimize edilmiş olmasını beklediğini söylüyor. Makalenin vardığı sonucun yerel kodun çalışma biçimiyle ilgili olmasına şaşırmadığını, bazı belirli yanıtlara şaşırsa da kafa karıştırıcı başlangıca rağmen bunun çok ilginç bir makale olduğunu kabul ediyor.

  • CPU özellik bayrakları hakkında tartışma

    REP STOS/MOV komutlarının memset/memcpy için hızlı ve kullanılabilir kısa komut dizileri olduğunu gösteren iki özel CPU özellik bayrağı bulunduğu belirtiliyor. Her yeni CPU nesli için optimize edilmiş rutinleri elle yazmanın onlarca yıldır süren bir sıkıntı olduğu söyleniyor. Bunun artık CPU üreticilerinin zamanlama test paketinin bir parçası olması gerekip gerekmediği sorgulanıyor.

  • İlgili glibc hata bağlantısı

    Zen 4 ile ilgili bir glibc hatasına bağlantı veriliyor.

  • Makaleye olumlu tepki

    Bir kullanıcı makaleyi okumadan önce std::fs'nin yanlış kullanımına gülmeye hazır olduğunu, ancak makalenin tavşan deliği ve gizemlerle dolu olduğunu, iyi yazıldığını ve çok ilginç olduğunu söylüyor.

  • Makaleye yüksek değerlendirme

    Başka bir kullanıcı bunun bu hafta okuduğu en ilginç makale olduğunu söylüyor ve yazının son derece iyi kaleme alındığını belirtiyor.

  • Sorunu çözmek için öneri

    Bariz çözüm olarak, CPU'nun sorunlu olduğunun tespit edilmesi ve bellek hizalamasının yavaşlık hatasını tetiklemesi durumunda farklı bir bellek kopyalama uygulamasının kullanılmasını sağlayacak şekilde copy_user_generic çekirdek metodunu değiştiren bir yama gönderilmesi öneriliyor.

  • Rust'ın varsayılan allocator'ü hakkında bilgi

    Rust'ın varsayılan allocator'ünün 2018'e kadar jemalloc olduğu bilgisi ve ilgili bağlantı paylaşılıyor.

  • Performans artışı için Rust geliştiricilerinin değerlendirebileceği konu

    Rust geliştiricilerinin performansı artırmak için jemallocatora geçmeyi değerlendirip değerlendirmemesi gerektiği, bunun herkesin ücretsiz performans kazanması için bir yol olup olmadığı, C kod tabanlarının da bundan fayda sağlayıp sağlayamayacağı ve şu anda masada bırakılmış bir performans olup olmadığı merak ediliyor.

  • AMD ve Intel CPU farklarına dair açıklama

    AMD'nin string store yaklaşımının Intel'den farklı olduğu ve CPU'nun L2 boyutunu aşana kadar bunun kullanılmamasının daha iyi olduğu açıklanıyor. Bu eşik aşıldığında string store kullanmanın avantajlı hale geldiği ve "DRAM hızı"nda çalışması gerektiği, ancak yüksek bir başlangıç maliyeti bulunduğu için o eşiğe ulaşana kadar 256 bit vektör load/store kullanılmasının gerektiği belirtiliyor.

  • Makalenin doğru kişilere iletildiğinin belirtilmesi

    Bir kullanıcı bu makaleyi doğru kişilere ilettiğini söylüyor.