บทความล่าสุดที่ตั้งคำถามต่อประสิทธิภาพของ lockless queue ได้จุดประกายการถกเถียงอย่างดุเดือดในชุมชนโปรแกรมเมอร์ โดยนักพัฒนาได้ตั้งคำถามทั้งการอ้างสมรรถนะและสมมติฐานพื้นฐานในการออกแบบที่ผู้เขียนนำเสนอ
บทความต้นฉบับได้โต้แย้งว่าการใช้งาน lockless queue ส่วนใหญ่มีข้อบกพร่องพื้นฐานและช้า โดยเสนอโครงสร้างข้อมูลแบบ bag ทางเลือกที่ละทิ้งการรับประกันลำดับไปโดยสิ้เชิง อย่างไรก็ตาม คำยืนยันนี้ได้รับการต่อต้านอย่างมากจากนักพัฒนาที่มีประสบการณ์ซึ่งชี้ไปที่ข้อมูลสมรรถนะในโลกจริงที่ขัดแย้งกับการอ้างเหล่านี้
ตัวเลขสมรรถนะเล่าเรื่องที่แตกต่าง
สมาชิกชุมชนได้ท้าทายการอ้างว่า lockless queue ช้าอย่างรวดเร็วด้วยข้อมูลการทดสอบประสิทธิภาพที่เป็นรูปธรรม นักพัฒนาที่ทำงานกับระบบนิเวศ lockless queue ของ Rust รายงานว่าการใช้งานที่เร็วที่สุดสามารถประมวลผลได้มากกว่า 30 ล้านองค์ประกอบต่อวินาที ซึ่งแปลเป็นเพียง 33 นาโนวินาทีต่อองค์ประกอบ แม้แต่การใช้งานที่ช้ากว่าก็ยังทำงานได้ประมาณ 100 นาโนวินาทีต่อองค์ประกอบ ซึ่งหลายคนถือว่าค่อนข้างเร็วสำหรับการดำเนินการพร้อมกัน
การถกเถียงทวีความรุนแรงขึ้นเมื่อผู้เขียนต้นฉบับปกป้องจุดยืนของตนโดยอ้างถึงการทดสอbenchmark ของตนเองที่แสดงเวลาประมวลผลเฉลี่ย 250 นาโนวินาทีภายใต้การแข่งขันที่หนัก นักวิจารณ์โต้แย้งว่านี่แสดงถึงการใช้งานเฉพาะภายใต้สภาวะที่รุนแรงมากกว่าการประณามเทคโนโลยี lockless queue โดยทั่วไป
การเปรียบเทียบประสิทธิภาพของ Lockless Queue
- การใช้งานที่เร็วที่สุด: 30+ ล้านเอลิเมนต์ต่อวินาที (33 นาโนวินาทีต่อเอลิเมนต์)
- การใช้งานที่ช้ากว่า: 5-10 ล้านเอลิเมนต์ต่อวินาที (100 นาโนวินาทีต่อเอลิเมนต์)
- การทดสอบของผู้เขียนภายใต้การแข่งขันที่หนัก: ประมาณ 4 ล้านเอลิเมนต์ต่อวินาที (250 นาโนวินาทีต่อเอลิเมนต์)
ข้อถกเถียงเรื่องคำนิยาม Queue
ส่วนสำคัญของการอภิปรายมุ่งเน้นไปที่สิ่งที่เป็น queue จริงๆ ในสภาพแวดล้อมแบบหลายเธรด บทความต้นฉบับอ้างว่า multi-consumer queue ทำลายลำดับโกลบอลและดังนั้นจึงไม่ใช่ queue ที่แท้จริง สมาชิกชุมชนไม่เห็นด้วยอย่างยิ่งกับคำนิยามที่แคบนี้ โดยชี้ให้เห็นว่า queue ในโลกจริงไม่ค่อยรักษาลำดับการประมวลผลโกลบอลที่เข้มงวด
นักพัฒนาคนหนึ่งใช้การเปรียบเทียบของศาลากลางเมืองที่มีเคาน์เตอร์บริการหลายแห่งเพื่ออธิบายประเด็นนี้ แม้ว่าผู้คนจะได้รับตั๋วตามลำดับ แต่พวกเขาอาจได้รับการบริการจากเคาน์เตอร์ต่างๆ ด้วยความเร็วที่แตกต่างกัน ซึ่งอาจทำให้การบริการเสร็จสิ้นไม่เป็นไปตามลำดับเดิม สิ่งนี้สะท้อนถึงวิธีการทำงานของ multi-consumer queue ในทางปฏิบัติและรองรับกรณีการใช้งานที่ถูกต้อง
ความท้าทายในการใช้งานและการแลกเปลี่ยน
ทางเลือก bag ที่เสนอได้รับความสงสัยจากนักพัฒนาที่คุ้นเคยกับโครงสร้างข้อมูลพร้อมกัน นักวิจารณ์สังเกตว่าการใช้งาน bag ยังคงต้องการการดำเนินการแบบ atomic บน bitmask ซึ่งอาจสร้างคอขวดการแข่งขันของตัวเอง ความท้าทายพื้นฐานยังคงอยู่: โครงสร้างข้อมูลที่ใช้ร่วมกันใดๆ ที่เข้าถึงโดยหลายเธรดจะต้องประสานการเข้าถึงด้ววิธีใดวิธีหนึ่ง
ผู้แสดงความคิดเห็นหลายคนเน้นย้ำว่า queue ประเภทต่างๆ รองรับวัตถุประสงค์ที่แตกต่างกัน MPSC (multiple-producer, single-consumer) queue ถูกใช้อย่างแพร่หลายในตัวจัดตารางงาน ในขณะที่ SPSC (single-producer, single-consumer) queue ทำงานได้ดีสำหรับไปป์ไลน์การประมวลผลแบบกำหนดเอง การเลือกขึ้นอยู่กับข้อกำหนดของกรณีการใช้งานเฉพาะมากกว่าลักษณะสมรรถนะสากล
ตัวที่เร็วที่สุดทำได้อย่างน้อย 30 ล้านองค์ประกอบต่อวินาทีในการกำหนดค่าส่วนใหญ่ได้อย่างง่ายดาย ตัวที่ช้าที่สุดอยู่ที่ประมาณ 5-10 ดังนั้นตัวที่เร็วที่สุดทำได้ 33ns ต่อองค์ประกอบและตัวที่ช้าที่สุดคือ 100ns
ประเภทของคิวและกรณีการใช้งาน
- SPSC (Single-Producer Single-Consumer): ไปป์ไลน์การประมวลผลแบบกำหนดเอง
- MPSC (Multiple-Producer Single-Consumer): ตัวจัดกำหนดการงาน ( tokio , rayon )
- SPMC (Single-Producer Multiple-Consumer): กรณีการใช้งานที่จำกัด
- MPMC (Multiple-Producer Multiple-Consumer): การจัดกำหนดการงานทั่วไป
ผลกระทบในทางปฏิบัติสำหรับนักพัฒนา
การถกเถียงเผยให้เห็นข้อพิจารณาสำคัญสำหรับนักพัฒนาที่เลือกโครงสร้างข้อมูลพร้อมกัน แม้ว่าบทความต้นฉบับจะยกประเด็นที่ถูกต้องเกี่ยวกับการรับประกันลำดับ แต่การตอบสนองของชุมชนเน้นย้ำว่าแอปพลิเคชันจำนวนมากไม่ต้องการลำดับโกลบอลที่เข้มงวด คุณสมบัติเช่นความยุติธรรม การหลีกเลี่ยงการอดอาหาร และพฤติกรรมที่คาดเดาได้มักจะสำคัญกว่าความสอดคล้องแบบลำดับที่สมบูรณ์แบบ
การอภิปรายยังเน้นย้ำถึงอันตรายของการอ้างสมรรถนะในวงกว้างโดยไม่มีการทดสอบประสิทธิภาพที่ครอบคลุมในสถานการณ์และการใช้งานที่แตกต่างกัน สิ่งที่ทำงานได้ดีภายใต้เงื่อนไขหนึ่งอาจมีปัญหาภายใต้เงื่อนไขอื่น ทำให้บริบทมีความสำคัญสำหรับการตัดสินใจในการออกแบบ
ข้อถกเถียงนี้ในท้ายที่สุดเน้นย้ำถึงความซับซ้อนของการเขียนโปรแกรมพร้อมกันและความสำคัญของการเข้าใจทั้งคุณสมบัติเชิงทฤษฎีและลักษณะสมรรถนะในทางปฏิบัติของแนวทางต่างๆ ก่อนตัดสินใจเชิงสถาปัตยกรรม