1 คะแนน โดย GN⁺ 2024-05-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

GGML: เขียน SiLU และ Softmax สำหรับ CPU ใหม่

การเปลี่ยนแปลงหลัก

  • เพิ่มฟังก์ชัน expf() แบบเวกเตอร์:

    • ทำให้สามารถคำนวณ Softmax และ SiLU ได้แม่นยำกว่า lookup table แบบ short[65536] ที่ GGML ใช้อยู่เดิม
    • รองรับ aarch64 และ sse2+ และในกรณีแย่ที่สุดมีข้อผิดพลาดจากการปัดเศษ 2 ULP
    • มีการเขียนอิมพลีเมนเทชัน avx2 และ avx512 ด้วย แต่ไม่ได้ใช้งาน เพราะเมื่อเทียบกับ sse2+fma แล้วแทบไม่มีข้อดีมากพอเมื่อเทียบกับความซับซ้อนของโค้ด
  • เสียงตอบรับหลัก:

    • ผู้มีส่วนร่วมหลายคนแสดงความเห็นเชิงบวกต่อการเปลี่ยนแปลงนี้
    • SOFT_MAX เร็วขึ้นราว 1.5 เท่าบน AMD Ryzen 9 5950X และ M2 Ultra

การเปลี่ยนแปลงของโค้ด

  • สรุปการเปลี่ยนแปลงหลัก:
    • ลบ #define ที่ถูกคอมเมนต์ไว้
    • แยกโค้ดซ้ำ 5 บรรทัดออกมาเป็น ggml_vec_soft_max_f32()
    • ลบฟังก์ชันที่เกี่ยวข้องกับ GGML_SILU_FP16
    • เพิ่ม ggml_v_expf()
    • เพิ่ม ggml_v_silu()
    • ปรับ ggml_vec_silu_f32() ด้วยคำสั่งพรีโปรเซสเซอร์ตามแฟลก SSE2 หรือ __ARM_NEON

การปรับปรุงประสิทธิภาพ

  • ผลการเบนช์มาร์ก:
    • SOFT_MAX เร็วขึ้นราว 1.5 เท่าบน AMD Ryzen 9 5950X และ M2 Ultra
    • เมื่อรวม AVX2 ข้อได้เปรียบเพิ่มจาก 1.5 เท่าเป็น 1.9 เท่า
    • บน znver4 เมื่อรวม avx512 เพิ่มเป็น 2.1 เท่า

ความเห็นเพิ่มเติม

  • ความเห็นจากผู้มีส่วนร่วม:
    • เมื่อใช้ AVX512 หากใช้ vscalefps จะสามารถจัดการ overflow และ underflow ได้อย่างเหมาะสม และตัดการตรวจสอบกับการ blend ออกได้
    • ยืนยันการปรับปรุงประสิทธิภาพบน Skylake-AVX512/Cascadelake

ความเห็นของ GN⁺

  • การปรับปรุงประสิทธิภาพ: การเปลี่ยนแปลงนี้สามารถเพิ่มประสิทธิภาพบน CPU ได้อย่างมาก โดยเฉพาะบนฮาร์ดแวร์รุ่นใหม่ที่ใช้ AVX2 และ AVX512
  • ความซับซ้อนของโค้ด: เนื่องจากอิมพลีเมนเทชัน AVX2 และ AVX512 ไม่ได้ให้ข้อได้เปรียบมากนักเมื่อเทียบกับ SSE2+fma การลดความซับซ้อนของโค้ดจึงเป็นเรื่องสำคัญ
  • ความเข้ากันได้ของฮาร์ดแวร์: การรองรับชุดคำสั่ง SIMD ที่หลากหลายเป็นสิ่งสำคัญเพื่อเพิ่มประสิทธิภาพบนฮาร์ดแวร์หลายประเภท
  • เบนช์มาร์ก: จำเป็นต้องมีการทดสอบเบนช์มาร์กบนฮาร์ดแวร์ที่หลากหลายเพื่อยืนยันการปรับปรุงประสิทธิภาพ
  • การใช้เทคโนโลยีล่าสุด: การใช้ชุดคำสั่ง SIMD รุ่นล่าสุดเพื่อดึงประสิทธิภาพสูงสุดเป็นสิ่งสำคัญ

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

 
GN⁺ 2024-05-16
ความเห็นจาก Hacker News

สรุปรวมความคิดเห็นจาก Hacker News

  • เรื่องเล่าเกี่ยวกับตัวประมวลผลสัญญาณเรดาร์ของ Hughes เมื่อ 20 ปีก่อน

    • มีการแชร์ประสบการณ์การปรับแต่งการคำนวณ e^x บนตัวประมวลผลสัญญาณเรดาร์ของ Hughes
    • ใช้ตาราง e^x จำนวน 256 ค่า สำหรับค่า 8 บิตแต่ละชุดภายในคำขนาด 32 บิต แล้วคูณกันเพื่อให้ได้ค่าผลลัพธ์สุดท้าย
    • ทำงานได้เร็วขึ้นกว่าเดิม 5 เท่า
    • ปัจจุบันเครื่องนี้ถือว่าล้าสมัยแล้ว แต่ในเวลานั้นขึ้นชื่อว่าเร็วมาก
  • ผลกระทบของการปรับปรุง silu และ softmax ต่อความเร็วในการอนุมานของ LLM

    • มีความเห็นว่าน่าจะส่งผลต่อความเร็วในการอนุมานของ LLM ไม่มากนัก
    • เวลาส่วนใหญ่ถูกใช้ไปกับการคูณเมทริกซ์
  • ความทึ่งต่อการปรับแต่งโค้ด

    • รู้สึกประหลาดใจและชื่นชมงานปรับแต่งที่ซับซ้อนนี้
    • พอรู้ว่าผู้มีส่วนร่วมคือ jart ก็เลยเข้าใจขึ้นมา
  • ข้อสงสัยเกี่ยวกับขนาดของ LUT

    • มีความเห็นว่า LUT ขนาด 65536 อาจไม่มีประสิทธิภาพ เพราะมีขนาดเท่ากับ L1 cache ทั้งหมด
    • แต่ก็อาจทำงานได้ดีเพราะมีการปรับแบบความน่าจะเป็น
  • การเปรียบเทียบ llama.cpp กับ ggml บน CPU

    • มีคนสงสัยว่า ggml เป็นอย่างไรเมื่อเทียบกับ tensorflow lite, onnxruntime และอื่น ๆ
  • การเปรียบเทียบประสิทธิภาพบนอุปกรณ์ CUDA

    • มีคำถามว่า gguf/llama.cpp ดีกว่าสำหรับการอนุมานแบบไม่แบตช์หรือไม่ หรือ exllamav2+flashattention ยังเหนือกว่าอยู่
  • ความเป็นไปได้ในการทำ LUT ให้เป็นเวกเตอร์

    • มีความเห็นว่าสามารถทำ LUT ให้เป็นเวกเตอร์ได้
    • มีการให้ลิงก์ไปยังข้อมูลที่เกี่ยวข้อง
  • การคำนวณ tanh แบบเร็ว

    • มีการให้ลิงก์เกี่ยวกับการคำนวณ tanh แบบเร็ว
  • ประสิทธิภาพของ llama บน CPU

    • มีความเห็นว่าแม้จะมีการปรับแต่งแล้ว แต่ llama ที่มีพารามิเตอร์จำนวนมากก็อาจยังช้าเกินไปบน CPU