ความพยายามในการลบ Python GIL ก่อนหน้านี้ส่งผลให้ประสิทธิภาพไม่ดี: เพราะอะไร

โพสต์นี้จากผู้สร้าง Python Guido Van Rossum กล่าวถึงความพยายามในการลบ GIL ออกจาก Python:

สิ่งนี้เคยลองมาแล้วด้วยผลลัพธ์ที่น่าผิดหวังซึ่งเป็นเหตุผลว่าทำไมฉันถึงลังเลที่จะใช้ความพยายามอย่างมากกับตัวเอง ในปี 1999 Greg Stein (กับ Mark Hammond?) ผลิต Python หนึ่งตัว (1.5 ฉันเชื่อ) ที่เอา GIL ออกมาแทนที่ด้วยการล็อกอย่างละเอียดในโครงสร้างข้อมูลที่ไม่แน่นอนทั้งหมด เขายังส่งแพตช์ที่ลบการเชื่อมโยงจำนวนมากกับโครงสร้างข้อมูลที่ไม่แน่นอนในระดับโลกซึ่งฉันยอมรับ อย่างไรก็ตามหลังจากการเปรียบเทียบมันแสดงให้เห็นว่าแม้บนแพลตฟอร์มที่มีการล็อกแบบเร็วที่สุด (Windows ในเวลานั้น) มันทำให้การประมวลผลแบบเธรดเดี่ยวช้าลงเกือบสองเท่าซึ่งหมายความว่าบน CPU สองตัวคุณสามารถทำงานได้มากขึ้น เสร็จสิ้นโดยไม่มี GIL มากกว่าใน CPU ตัวเดียวที่มี GIL นี่ยังไม่เพียงพอและแพทช์ของเกร็กก็หายไป (ดูการเขียนของ Greg เกี่ยวกับประสิทธิภาพ)

ฉันแทบจะไม่สามารถโต้แย้งกับผลลัพธ์ที่แท้จริงได้ แต่ฉันสงสัยว่าทำไมสิ่งนี้ถึงเกิดขึ้น เหตุผลหลักที่การลบ GIL ออกจาก CPython นั้นยากมากก็คือเนื่องจากระบบการจัดการหน่วยความจำการอ้างอิงที่อ้างอิง โปรแกรม Python ทั่วไปจะเรียกใช้Py_INCREFและเป็นPy_DECREFพัน ๆ ครั้งหรือหลายล้านครั้งทำให้เป็นประเด็นการแข่งขันที่สำคัญหากเราต้องล้อมรอบล็อค

แต่ฉันไม่เข้าใจว่าทำไมการเพิ่มแบบดั้งเดิมของอะตอมจึงทำให้โปรแกรมเธรดเดี่ยวช้าลง สมมติว่าเราเพิ่งแก้ไข CPython เพื่อให้ตัวแปร refcount ในแต่ละวัตถุ Python เป็นแบบดั้งเดิมอะตอมมิก จากนั้นเราก็ทำการเพิ่มอะตอม (คำสั่งการดึงและเพิ่ม) เมื่อเราต้องการเพิ่มจำนวนการอ้างอิง สิ่งนี้จะทำให้ Python อ้างอิงการนับเธรดปลอดภัยและไม่ควรมีการปรับประสิทธิภาพใด ๆ ในแอปพลิเคชันแบบเธรดเดียวเนื่องจากจะไม่มีการช่วงชิงการล็อก

แต่อนิจจาหลายคนที่ฉลาดกว่าฉันได้ลองและล้มเหลวดังนั้นเห็นได้ชัดว่าฉันขาดอะไรบางอย่างที่นี่ เกิดอะไรขึ้นกับวิธีที่ฉันดูปัญหานี้

ฉันไม่คุ้นเคยกับส้อม Greg Stein Python ดังนั้นให้ลดการเปรียบเทียบนี้เป็นการเปรียบเทียบเชิงประวัติศาสตร์ที่เป็นการเก็งกำไรหากคุณต้องการ แต่นี่เป็นประสบการณ์ในอดีตของฐานรหัสโครงสร้างพื้นฐานจำนวนมากที่ย้ายจากการติดตั้งแบบใช้ครั้งเดียวไปยังหลายเธรด

โดยพื้นฐานแล้วการใช้งาน Unix ทุกอย่างที่ฉันศึกษาในปี 1990 - AIX, DEC OSF / 1, DG / UX, DYNIX, HP-UX, IRIX, Solaris, SVR4 และ SVR4 MP - ทุกอย่างผ่านไปอย่างตรงจุด " การล็อคที่ละเอียดยิ่งขึ้น - ตอนนี้ช้าลง !! " ปัญหา. DBMS ที่ฉันติดตาม - DB2, Ingres, Informix, Oracle และ Sybase - พวกเขาทั้งหมดก็ผ่านมันเช่นกัน

ฉันเคยได้ยิน "การเปลี่ยนแปลงเหล่านี้จะไม่ทำให้เราช้าลงเมื่อเราใช้เธรดเดี่ยว" หนึ่งล้านครั้ง มันไม่เคยได้ผลเช่นนั้น การกระทำที่เรียบง่ายของการตรวจสอบแบบมีเงื่อนไข "เราใช้หลายเธรดหรือไม่?" เพิ่มค่าใช้จ่ายจริงโดยเฉพาะอย่างยิ่งในซีพียูที่มีท่อสูง เพิ่มการดำเนินงานของอะตอมและสปินล็อคเป็นครั้งคราวเพื่อให้แน่ใจว่าความสมบูรณ์ของโครงสร้างข้อมูลที่ใช้ร่วมกันนั้นต้องถูกเรียกใช้บ่อยครั้งและมันก็ช้ามาก การล็อก / การซิงโครไนซ์รุ่นแรกก็ช้าเช่นกัน ทีมดำเนินการส่วนใหญ่ในที่สุดเพิ่มหลายชั้นของดั้งเดิมใน "จุดแข็ง" ต่าง ๆ ขึ้นอยู่กับว่าจำเป็นต้องมีการป้องกันลูกโซ่ที่เชื่อมโยงกันในสถานที่ต่าง ๆ จากนั้นพวกเขาก็รู้ว่าพวกเขาอยู่ที่ไหนในตอนแรกที่ตบลงล็อกดั้งเดิมไม่ใช่สถานที่ที่เหมาะสมดังนั้นพวกเขาจึงต้องโปรไฟล์ออกแบบรอบคอขวดพบ และ roto-till อย่างเป็นระบบ บางส่วนของจุดที่ติดเหล่านี้ในที่สุดได้รับ OS หรือการเร่งฮาร์ดแวร์ แต่วิวัฒนาการทั้งหมดใช้เวลา 3-5 ปีขั้นต่ำเปล่า ในขณะที่รุ่น MP หรือ MT นั้นมีอาการที่คลาดเคลื่อนและมีประสิทธิภาพ

ทีมพัฒนาที่มีความซับซ้อนเป็นอย่างอื่นแย้งว่าการชะลอตัวดังกล่าวนั้นเป็นความจริงที่ไม่ย่อท้อและเป็นเรื่องยากของชีวิต IBM เช่นปฏิเสธที่จะเปิดใช้งาน SMP สำหรับ AIX เป็นเวลาอย่างน้อย 5 ปีหลังจากการแข่งขันยืนยันว่าเธรดเดียวนั้นดีกว่าหมดจด Sybase ใช้อาร์กิวเมนต์เดียวกันบางตัว เหตุผลเดียวที่บางทีมในที่สุดก็มาถึงก็คือประสิทธิภาพของเธรดเดี่ยวไม่สามารถปรับปรุงได้อย่างมีเหตุผลในระดับ CPU พวกเขาถูกบังคับให้ไป MP / MT หรือยอมรับว่ามีผลิตภัณฑ์ที่ไม่มีการแข่งขันเพิ่มมากขึ้น

การทำงานพร้อมกันที่ใช้งานคือ HARD และมันก็เป็นการหลอกลวง ทุกคนรีบเข้าไปคิดว่า "สิ่งนี้จะไม่เลวร้ายขนาดนี้" จากนั้นพวกเขาก็กระแทกทรายดูดและต้องผ่านไปให้ได้ ฉันเคยเห็นสิ่งนี้เกิดขึ้นอย่างน้อยหนึ่งโหลแบรนด์เนมทีมสมาร์ทที่ได้รับการสนับสนุนอย่างดี โดยทั่วไปแล้วดูเหมือนว่าจะใช้เวลาอย่างน้อยห้าปีหลังจากเลือกที่จะใช้มัลติเธรดเพื่อ "กลับไปยังที่ที่ควรจะเป็นประสิทธิภาพที่ชาญฉลาด" ด้วยผลิตภัณฑ์ MP / MT ส่วนใหญ่ยังคงปรับปรุง MP / MT อย่างมีประสิทธิภาพ / ความสามารถในการปรับขยายที่มีความหมายแม้สิบปีหลังจากทำการเปลี่ยนแปลง

ดังนั้นการเก็งกำไรของฉันคือการขาดการสนับสนุนและการสนับสนุนของ GvR ไม่มีใครได้รับความพ่ายแพ้ใน Python และ GIL แม้ว่าพวกเขาจะทำเช่นนี้ในวันนี้มันก็จะเป็น Python 4.x timeframe ก่อนที่คุณจะพูดว่า "ว้าว! เราอยู่เหนือโคก MT!"

อาจมีเวทมนต์บางอย่างที่แยก Python และรันไทม์จากซอฟต์แวร์โครงสร้างพื้นฐานอื่น ๆ ที่เป็น stateful ทั้งหมด - เวลาภาษา, ระบบปฏิบัติการ, การตรวจสอบธุรกรรมและผู้จัดการฐานข้อมูลที่เคยทำมาก่อน แต่ถ้าเป็นเช่นนั้นมันไม่เหมือนใครหรือเกือบจะเป็นเช่นนั้น ทุกคนที่ลบ GIL-เทียบเท่าได้ใช้เวลาห้าปีในการทุ่มเทความพยายามและการลงทุนเพื่อให้ได้มาจาก MT-not ไปยัง MT-hot

อีกสมมติฐานป่า: ในปี 1999 ลินุกซ์และอื่น ๆ ที่ไม่ได้ Unices ประสาน performant เหมือนว่ามันจะมีตอนนี้มีfutex(2)( http://en.wikipedia.org/wiki/Futex ) ผู้มาประมาณปี 2002 (และถูกรวมเข้ากับ 2.6 รอบ 2004)

เนื่องจากโครงสร้างข้อมูลทั้งหมดในตัวจะต้องมีการล็อคค่าใช้จ่ายให้ตรงกันมาก pointed ชี้ให้เห็นแล้วว่าการปฏิบัติการปรมาณูไม่จำเป็นที่จะถูก