แพตเทิร์น C++ สำหรับแอปพลิเคชันแบบหน่วงต่ำ รวมถึงการซื้อขายความถี่สูง

แพตเทิร์นการออกแบบสำหรับแอปพลิเคชัน C++ แบบหน่วงต่ำ

• ผู้เขียน: Paul Bilokon, Burak Gunduz
• วันที่ส่ง: 8 กันยายน 2023
• หัวข้อ: การเพิ่มประสิทธิภาพโค้ดแบบหน่วงต่ำ โดยเน้นเป็นพิเศษที่ระบบการซื้อขายความถี่สูง (HFT)

การมีส่วนสำคัญ

• การสร้างคลังเก็บการเขียนโปรแกรมแบบหน่วงต่ำ: เป็นคู่มือเชิงปฏิบัติ พร้อมการทำเบนช์มาร์กทางสถิติอย่างเข้มงวด
• การเพิ่มประสิทธิภาพกลยุทธ์อาร์บิทราจเชิงสถิติแบบเป็นกลางต่อภาวะตลาด: ปรับปรุงอย่างมีนัยสำคัญทั้งด้านความเร็วและความสามารถในการทำกำไร
• การนำแพตเทิร์น Disruptor ไปใช้ใน C++: ให้ประสิทธิภาพดีกว่าวิธีการจัดคิวแบบดั้งเดิม

ตัวชี้วัดการประเมิน

• ความเร็ว
• การใช้ประโยชน์จากแคช
• นัยสำคัญทางสถิติ เป็นต้น

เทคโนโลยีหลัก

• การวอร์มแคช: ลดเวลาแฝงด้วยการเตรียมแคชล่วงหน้า
• Constexpr: เพิ่มประสิทธิภาพด้วยการประเมินค่าคงที่ในเวลาคอมไพล์

ทิศทางในอนาคต

• ขยายคลังเก็บ
• ทดสอบอัลกอริทึมการซื้อขายที่ปรับแต่งแล้วในสภาพแวดล้อมการซื้อขายจริงแบบเรียลไทม์
• ผสานแพตเทิร์น Disruptor กับอัลกอริทึมการซื้อขายเพื่อทำเบนช์มาร์กระบบแบบครบวงจร

ผู้อ่านเป้าหมาย

• ผู้ปฏิบัติงานทั้งในแวดวงวิชาการและอุตสาหกรรม

สรุปโดย GN⁺

บทความนี้กล่าวถึงแพตเทิร์นการออกแบบเพื่อปรับปรุงประสิทธิภาพของแอปพลิเคชันแบบหน่วงต่ำ โดยเฉพาะระบบการซื้อขายความถี่สูง โดยคลังเก็บการเขียนโปรแกรมแบบหน่วงต่ำและการนำแพตเทิร์น Disruptor ไปใช้จะเป็นคู่มือที่มีประโยชน์สำหรับผู้ปฏิบัติงาน เทคนิคอย่างการวอร์มแคชและ Constexpr มีส่วนอย่างมากในการลดเวลาแฝง และบทความนี้จะเป็นประโยชน์อย่างยิ่งสำหรับผู้ที่สนใจการเพิ่มประสิทธิภาพ

[GN⁺]

ความคิดเห็นจาก Hacker News

• เป็นบทเกริ่นนำสั้น ๆ เกี่ยวกับหัวข้อนี้

• นักศึกษาปริญญาตรีรู้องค์ประกอบพื้นฐานของการปรับแต่งประสิทธิภาพอยู่แล้ว

  • เรียนรู้แนวคิดพื้นฐานอย่าง branch prediction, cache coherence และ instruction cache

• น่าแปลกที่ไม่ได้พูดถึง false sharing ซึ่งเป็นปัจจัยที่ทำให้ประสิทธิภาพลดลง

• น่าแปลกเช่นกันที่ไม่ได้พูดถึง optimization hint attributes เช่น [[likely]], [[unlikely]]

• ไม่ได้ครอบคลุมองค์ประกอบการปรับแต่งประสิทธิภาพขั้นสูง

  • เช่น IO API เฉพาะทาง, synchronization primitives, IPC mechanisms, compiler built-ins

• สิ่งที่โปรแกรมเมอร์สาย low-latency ต้องมีคือความระแวดระวังต่อการจัดสรรหน่วยความจำและการคัดลอกที่ไม่จำเป็น

  • ควรมีนิสัยค้นหาปัจจัยที่ทำให้ประสิทธิภาพลดลงผ่าน benchmark

• ตอนเขียนเซิร์ฟเวอร์แบบ low-latency จึงตระหนักได้ว่า vector IO ทำงานช้ากว่าการคัดลอกอ็อบเจ็กต์ขนาดเล็กไปยัง contiguous buffer

  • ย้ำว่าไม่มีการคัดลอกไหนที่ฟรี

• ผลการทดสอบให้ค่า t-statistic และ p-value

  • t-statistic แสดงผลการทดสอบ unit root ของ residuals
  • p-value ให้ความน่าจะเป็นที่สมมติฐานศูนย์ของการทดสอบจะเป็นจริง

• ส่วนนี้ดูเหมือนเขียนด้วย LLM

• ตัวอย่างที่วิเคราะห์ราคาปิดวันละครั้งเป็นเวลา 5 ปี แล้วคำนวณสเปรดด้วย latency 65 ไมโครวินาทีนั้นดูแปลก

  • ไม่ได้คำนวณสถิติในลูปชั้นใน
  • 65 ไมโครวินาทีช้าเกินไปสำหรับลูปชั้นใน
  • ดูเหมือนเป็นตัวอย่างสำหรับฝึกเทคนิคการปรับแต่ง

• แชร์ implementation ของตลาดหลักทรัพย์ที่เขียนด้วย C++

  • ใช้แพตเทิร์น LMAX disruptor
  • กำลังจะเขียนใหม่ด้วย Rust
  • ใน Rust การจัดการหน่วยความจำและ dependency ง่ายกว่า

• เขียนไลบรารี logging สำหรับ C++

  • คล้ายกับ LMAX disruptor
  • ใช้งานในชุมชน HFT
  • ทำให้สามารถทำ detailed logging ได้โดยไม่ทำให้ประสิทธิภาพลดลง
  • แก้ปัญหาที่เพื่อนร่วมงานไม่ log ข้อมูลสำคัญเพราะกังวลเรื่องประสิทธิภาพลดลง

• ประสิทธิภาพของ compile-time dispatch มาจากการที่การตัดสินใจเรียกฟังก์ชันเกิดขึ้นตั้งแต่ขั้นตอนคอมไพล์

  • หากคอมไพเลอร์สามารถตัดสินได้แบบสถิตว่าฟังก์ชันใดจะถูกเรียก ก็สามารถ inline โค้ดของฟังก์ชันนั้นได้โดยตรง
  • ช่วยลบ overhead ของการเรียกฟังก์ชันทั้งหมด และเปิดทางให้เกิดการปรับแต่งเพิ่มเติม

• แชร์สไลด์จากงาน CppCon 2017

  • หัวข้อคือ เมื่อไมโครวินาทีรู้สึกยาวนานชั่วนิรันดร์
  • ถ้าเป็นนักพัฒนามืออาชีพก็ควรดูเนื้อหาทั้งหมด

• ตั้งคำถามว่ามีเหตุผลใดหรือไม่ที่ high-frequency trading ควรมีอยู่

  • ผู้คนบ่นว่า Bitcoin สิ้นเปลืองพลังงาน แต่ high-frequency trading กลับส่งผลลบต่อสังคมแบบล้วน ๆ