Rust std fs ช้ากว่า Python เหรอ? ไม่ใช่ ปัญหาอยู่ที่ฮาร์ดแวร์

 (xuanwo.io)
2 คะแนน โดย GN⁺ 2023-11-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

Python binding ของ OpenDAL ช้ากว่า Python เองหรือไม่?

  • OpenDAL เป็น data access layer ที่ช่วยให้ดึงข้อมูลจากบริการจัดเก็บข้อมูลหลากหลายประเภทได้อย่างมีประสิทธิภาพ
  • มีรายงานว่า Python binding ของ OpenDAL ช้ากว่า Python เอง
  • มีการตั้งสมมติฐานว่าสาเหตุอาจมาจาก internal cache ของ Python, การเร่งความเร็วการอ่านไฟล์ และโอเวอร์เฮดเพิ่มเติมจาก PyO3

บริการ Fs ของ OpenDAL ช้ากว่า Python หรือไม่?

  • นี่เป็นปัญหาที่เกี่ยวข้องกับหลายปัจจัย เช่น Rust, OpenDAL, Python และ PyO3
  • พบว่าแม้แต่บริการ fs ของ OpenDAL ที่เขียนด้วย Rust ก็ยังช้ากว่า Python

Rust std fs ช้ากว่า Python หรือไม่?

  • OpenDAL ใช้ std::fs ในการอิมพลีเมนต์บริการ fs
  • ยืนยันได้ว่าอิมพลีเมนต์ที่ใช้ std::fs ของ Rust ก็ช้ากว่า Python เช่นกัน

Rust std fs ช้ากว่า Python จริงเหรอ!?

  • มีการตั้งข้อสงสัยกับผลลัพธ์ที่ว่า Rust std fs ช้ากว่า Python
  • ได้เรียนรู้การวิเคราะห์ system call ด้วย strace
  • จากการวิเคราะห์ผล strace ก็ยังหาคำตอบไม่ได้ว่าทำไม Python ถึงเร็วกว่าทั้งที่ทั้งคู่ใช้ mmap

ทำไมถึงใช้ mmap ที่นี่?

  • mmap ไม่ได้ใช้แค่เพื่อแมปไฟล์เข้ากับหน่วยความจำเท่านั้น แต่ยังใช้สำหรับการจัดสรรพื้นที่หน่วยความจำขนาดใหญ่ด้วย
  • เมื่อร้องขอหน่วยความจำด้วย malloc นั้น glibc จะใช้ mmap เพื่อจัดสรรหน่วยความจำ

Python มี memory allocator แบบเดียวกับ Rust หรือไม่?

  • Python ใช้ memory allocator ชื่อ pymalloc ที่ปรับแต่งมาสำหรับการจัดสรรขนาดเล็ก
  • pymalloc เหมาะกับอ็อบเจ็กต์ขนาดเล็ก และสำหรับการจัดสรรขนาดใหญ่จะใช้ PyMem_RawMalloc() และ PyMem_RawRealloc()

Rust ช้ากว่า Python เพราะ default memory allocator หรือไม่?

  • มีข้อสงสัยว่า mmap คือสาเหตุของปัญหา
  • พบว่าโปรแกรม Rust ที่สลับไปใช้ jemalloc ทำงานได้เร็วกว่า Python

หรือว่า Rust ช้ากว่า Python แค่บนคอมพิวเตอร์ของฉัน!

  • การที่ Rust ทำงานช้ากว่า Python เกิดขึ้นเฉพาะบนคอมพิวเตอร์บางเครื่องเท่านั้น
  • มีการให้ข้อมูลรายละเอียดเกี่ยวกับ CPU และหน่วยความจำ
  • แม้จะปรับฟีเจอร์บรรเทาช่องโหว่ของ CPU, Transparent Hugepage และ CPU core affinity แล้ว ผลลัพธ์ก็ไม่เปลี่ยนแปลง
  • ใช้โปรแกรม eBPF เพื่อตรวจสอบ และยืนยันว่า Rust ช้ากว่า Python แม้ในระดับ system call

C ช้ากว่า Python หรือไม่?

  • พบว่าเวอร์ชันที่อิมพลีเมนต์ด้วย C ก็ช้ากว่า Python เช่นกัน

C ช้ากว่า Python หรือไม่? เมื่อไม่มี offset ที่กำหนดไว้!

  • พบว่ามีความแตกต่างของ offset ในพื้นที่หน่วยความจำ และเมื่อปรับ offset แล้วก็ทำให้โปรแกรม C เร็วขึ้น
  • ยืนยันได้ว่าบน CPU AMD Ryzen จะเกิดประสิทธิภาพลดลงหากไม่มี offset บางค่า

AMD Ryzen 9 5900X ช้าเมื่อไม่มี offset ที่กำหนดไว้จริงหรือ!

  • ยืนยันได้ว่านี่เป็นปัญหาที่เกี่ยวข้องกับ CPU และมีนักพัฒนาเคอร์เนลเข้ามาร่วมอภิปราย
  • การทำ profiling ด้วย perf ยืนยันอีกครั้งว่าหากไม่มี offset ดังกล่าวจะเกิดประสิทธิภาพลดลง

GN⁺ ความเห็น: ประเด็นสำคัญที่สุดของบทความนี้คือ Rust และ C อาจทำงานช้ากว่า Python ได้ในสภาพแวดล้อมฮาร์ดแวร์บางแบบ และสาเหตุอาจเกี่ยวข้องกับการจัดสรรหน่วยความจำและลักษณะการทำงานเฉพาะของ CPU บทความนี้แสดงให้เห็นผ่านกระบวนการสำรวจปัจจัยหลายด้านที่มีผลต่อประสิทธิภาพซอฟต์แวร์ ว่าปฏิสัมพันธ์ระหว่างฮาร์ดแวร์กับซอฟต์แวร์นั้นซับซ้อนเพียงใด และการสืบค้นเช่นนี้ก็เป็นบทเรียนสำคัญต่อการแก้ปัญหาที่ไม่คาดคิดในโลกของวิศวกรรมซอฟต์แวร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-30
ความเห็นจาก Hacker News

  • ความเห็นเกี่ยวกับสมมติฐานที่ทำให้สับสน

    ผู้ใช้คนหนึ่งรู้สึกสับสนกับแนวคิดที่ว่าฟังก์ชันใน Python standard library ถูกเขียนด้วย Python ล้วน ๆ แม้ว่าความแตกต่างด้านประสิทธิภาพระหว่างเมธอดอ่านไฟล์ของ Python กับ OpenDAL จะน่าสนใจ เพราะทั้งคู่เป็น Python wrapper ที่ครอบ native code แต่ก็รู้สึกว่าการพูดว่า "ช้ากว่า Python" นั้นฟังแปลกไป คาดหวังว่าฟังก์ชันใน Python standard library จะถูก implement ด้วย native code และแต่ละส่วนก็ควรถูกปรับแต่งมาแล้ว ไม่ได้แปลกใจกับข้อสรุปของบทความที่เกี่ยวข้องกับวิธีการทำงานของ native code แม้จะประหลาดใจกับคำตอบบางข้อ แต่ก็ยอมรับว่าแม้จะเริ่มต้นอย่างชวนสับสน บทความนี้ก็น่าสนใจมาก

  • การถกเถียงเกี่ยวกับ CPU feature flag

    มี CPU feature flag แบบเฉพาะอยู่สองตัวที่บ่งบอกว่าคำสั่ง REP STOS/MOV นั้นเร็วและใช้งานได้ในฐานะลำดับคำสั่งสั้น ๆ สำหรับ memset/memcpy การต้องเขียนรูทีนที่ปรับแต่งเองสำหรับ CPU รุ่นใหม่แต่ละรุ่นเป็นความเจ็บปวดที่ยืดเยื้อมาหลายสิบปี จึงมีการตั้งคำถามว่าตอนนี้สิ่งนี้ควรกลายเป็นส่วนหนึ่งของ timing test suite ของผู้ผลิต CPU ได้หรือยัง

  • ลิงก์บั๊ก glibc ที่เกี่ยวข้อง

    มีการแชร์ลิงก์ไปยังบั๊กของ glibc ที่เกี่ยวข้องกับ Zen 4

  • ปฏิกิริยาเชิงบวกต่อบทความ

    ผู้ใช้คนหนึ่งบอกว่าเริ่มอ่านบทความโดยตั้งใจจะหัวเราะกับการใช้ std::fs แบบผิด ๆ แต่สุดท้ายกลับมองว่าบทความนี้เหมือนโพรงกระต่ายที่เต็มไปด้วยปริศนาต่อเนื่อง เขียนได้ดีและน่าสนใจมาก

  • การชื่นชมบทความอย่างมาก

    ผู้ใช้อีกคนมองว่านี่เป็นบทความที่น่าสนใจที่สุดที่อ่านมาในสัปดาห์นี้ และชื่นชมว่าบทความเขียนได้ยอดเยี่ยม

  • ข้อเสนอเพื่อแก้ปัญหา

    มีการเสนอว่าแนวทางแก้ที่ชัดเจนคือส่งแพตช์เพื่อเปลี่ยน kernel method copy_user_generic ให้ใช้ implementation การคัดลอกหน่วยความจำแบบอื่น หากตรวจพบว่า CPU มีปัญหาและการจัดแนวหน่วยความจำไปกระตุ้นบั๊กความช้า

  • ข้อมูลเกี่ยวกับ allocator พื้นฐานของ Rust

    มีการให้ข้อมูลว่า allocator พื้นฐานของ Rust เคยเป็น jemalloc จนถึงปี 2018 พร้อมลิงก์ที่เกี่ยวข้อง

  • สิ่งที่นักพัฒนา Rust ควรพิจารณาเพื่อเพิ่มประสิทธิภาพ

    มีการตั้งข้อสงสัยว่านักพัฒนา Rust ควรพิจารณาเปลี่ยนไปใช้ jemallocator เพื่อเพิ่มประสิทธิภาพหรือไม่ นี่เป็นวิธีที่ทุกคนจะได้ performance ฟรีหรือไม่ codebase ฝั่ง C ก็จะได้ประโยชน์จากเรื่องนี้ด้วยหรือไม่ และนี่คือประสิทธิภาพที่ยังถูกทิ้งไว้บนโต๊ะอยู่หรือเปล่า

  • คำอธิบายเกี่ยวกับความแตกต่างของ CPU ระหว่าง AMD และ Intel

    มีการอธิบายว่าวิธีจัดการ string store ของ AMD แตกต่างจาก Intel และไม่ควรใช้จนกว่าจะเกินขนาด L2 ของ CPU เมื่อเลยจุดนั้นไปแล้ว การใช้ string store จะให้ประโยชน์และควรทำงานได้ที่ระดับ "ความเร็ว DRAM" แต่เนื่องจากมีต้นทุนเริ่มต้นสูง จึงควรใช้ 256-bit vector load/store ไปก่อนจนกว่าจะถึง threshold นั้น

  • การส่งต่อบทความให้คนที่เหมาะสม

    ผู้ใช้คนหนึ่งระบุว่าได้ส่งบทความนี้ต่อให้คนที่เหมาะสมแล้ว