โปรแกรมที่อ้างว่าไม่เป็นมิตรกับ "มัลติคอร์"


17

คุณเห็นวลีนี้หรือคล้ายกันเตะเป็นครั้งคราวโดยทั่วไปหมายถึงโปรแกรมที่อ้างว่าพวกเขาไม่ได้ออกแบบมาเพื่อใช้ประโยชน์จากโปรเซสเซอร์แบบมัลติคอร์อย่างเต็มที่ นี่เป็นเรื่องปกติโดยเฉพาะอย่างยิ่งกับการเขียนโปรแกรมวิดีโอเกม (แน่นอนว่าโปรแกรมจำนวนมากไม่มีการทำงานพร้อมกันและไม่จำเป็นต้องใช้เช่นสคริปต์พื้นฐาน ฯลฯ )

สิ่งนี้จะเป็นอย่างไร โปรแกรมจำนวนมาก (โดยเฉพาะเกม) ใช้งานพร้อมกันและเนื่องจากระบบปฏิบัติการรับผิดชอบการกำหนดตารางเวลางานบน CPU ดังนั้นโปรแกรมเหล่านี้จึงไม่ได้รับประโยชน์จากหลายคอร์ที่มีอยู่หรือไม่ สิ่งนี้หมายความว่าอย่างไรในการ "ใช้ประโยชน์จากหลายแกน" นักพัฒนาเหล่านี้จริง ๆ แล้วห้ามการกำหนดตารางงาน OS และบังคับให้มีความเกี่ยวข้องหรือกำหนดเวลาของตนเองหรือไม่? (ฟังดูเหมือนปัญหาด้านเสถียรภาพที่สำคัญ)

ฉันเป็นโปรแกรมเมอร์ Java ดังนั้นฉันอาจไม่ต้องจัดการกับเรื่องนี้เนื่องจากสิ่งที่เป็นนามธรรมหรืออะไรก็ตาม


11
ความเป็นไปได้ที่ยิ่งใหญ่คือมีการใช้ช็อตคัตในการซิงโครไนซ์ซึ่งทำงานกับระบบตัวประมวลผลเดียว / คอร์ แต่ทำลายด้วยการทำงานพร้อมกันที่แท้จริงของโปรเซสเซอร์ / คอร์หลายตัว
Bart van Ingen Schenau

@BartvanIngenSchenau: ถูกต้อง คุณควรขยายและโพสต์มันเป็นคำตอบ ฉันคิดว่าคนอื่น ๆ ทั้งหมดพลาดจุดนี้
kevin cline

1
ฉันคิดว่า @Bart อยู่ใกล้จริงๆ อย่างไรก็ตาม s / งาน / ดูเหมือนจะทำงาน / และมันจะอยู่ใกล้กับเครื่องหมาย
Ben Voigt

ฉันได้รับประสบการณ์นี้ในฐานะผู้ใช้มากกว่าโปรแกรมเมอร์ - Ground Control 2 บน windows XP ฉันต้องการตั้งค่า core affinity เป็น core เดียวเท่านั้นบนระบบ multicore เพื่อให้ทำงานได้อย่างถูกต้องมิฉะนั้นภาพเคลื่อนไหวทั้งหมด (infact ทั้งเกม) จะทำงานที่ความเร็ว 10x ซึ่งในขณะที่ความท้าทายมากขึ้นก็น่ารำคาญเล็กน้อยหลังจากผ่านไประยะหนึ่ง . ฉันไม่ได้ทำงานเกี่ยวกับเกม แต่ในใจของฉันบางส่วนของเกมดูเหมือนว่าจะใช้หน่วยประมวลผลเพียงแค่ทำงานในเวลาเดียวกัน
jammypeach

คำตอบ:


28

การทำงานพร้อมกันที่ดีต้องมีมากกว่าการใช้เธรดบางตัวในแอปพลิเคชันและหวังว่าจะดีที่สุด มีช่วงของวิธีการที่โปรแกรมพร้อมกันสามารถเริ่มจากขนานที่น่าอับอายกับลำดับบริสุทธิ์ โปรแกรมใดก็ตามที่สามารถใช้กฎหมายของ Amdahlเพื่อแสดงให้เห็นว่าปัญหาหรืออัลกอริทึมที่ปรับขนาดได้นั้นเป็นอย่างไร คุณสมบัติสองประการสำหรับการใช้งานแบบขนานที่น่าอับอายคือ:

  • ไม่มีสถานะที่แชร์ทุกฟังก์ชั่นขึ้นอยู่กับพารามิเตอร์ที่ส่งผ่าน
  • ไม่สามารถเข้าถึงอุปกรณ์ทางกายภาพ (กราฟิกการ์ดฮาร์ดไดรฟ์ ฯลฯ )

มีคุณสมบัติอื่น ๆ แต่ด้วยเพียงแค่สองสิ่งนี้เราสามารถเข้าใจได้ว่าทำไมเกมโดยเฉพาะนั้นไม่ง่ายอย่างที่คุณคิดว่าจะใช้ประโยชน์จากหลายคอร์ สำหรับหนึ่งรูปแบบของโลกที่จะแสดงผลจะต้องมีการใช้ร่วมกันเป็นฟังก์ชั่นที่แตกต่างกันคำนวณฟิสิกส์การเคลื่อนไหวใช้ปัญญาประดิษฐ์ ฯลฯ ประการที่สองแต่ละเฟรมของเกมนี้จะต้องมีการแสดงผลบนหน้าจอด้วยกราฟิกการ์ด

เพื่อความเป็นธรรมผู้ผลิตเกมหลายรายใช้เอ็นจิ้นเกมที่ผลิตโดยบุคคลที่สาม มันใช้เวลาสักครู่ แต่เอ็นจิ้นเกมบุคคลที่สามเหล่านี้ตอนนี้ขนานกันมากกว่าที่เคยเป็นมา

มีความท้าทายด้านสถาปัตยกรรมที่ใหญ่กว่าในการจัดการกับการเกิดพร้อมกัน

การทำงานพร้อมกันสามารถมีได้หลายรูปแบบตั้งแต่การทำงานในพื้นหลังไปจนถึงการสนับสนุนสถาปัตยกรรมแบบเต็มสำหรับการทำงานพร้อมกัน บางภาษาให้คุณสมบัติการทำงานพร้อมกันที่ทรงพลังเช่นERLANGแต่คุณต้องคิดแตกต่างกันมากเกี่ยวกับวิธีการสร้างแอปพลิเคชันของคุณ

ไม่ใช่ทุกโปรแกรมที่ต้องการความซับซ้อนของการสนับสนุนมัลติคอร์อย่างสมบูรณ์ ตัวอย่างหนึ่งคือซอฟต์แวร์ภาษีหรือแอปพลิเคชันที่ขับเคลื่อนด้วยรูปแบบใด เมื่อเวลาส่วนใหญ่ของคุณถูกรอให้ผู้ใช้ทำบางสิ่งความซับซ้อนของแอพพลิเคชั่นแบบมัลติเธรดนั้นไม่ได้มีประโยชน์

บางแอปพลิเคชันให้ยืมตัวเองเพื่อแก้ปัญหาแบบขนานที่น่าอับอายมากขึ้นเช่นเว็บแอปพลิเคชัน ในกรณีนี้แพลตฟอร์มจะเริ่มขนานกันอย่างน่าอายและขึ้นอยู่กับคุณไม่จำเป็นต้องกำหนดความขัดแย้งของเธรด

บรรทัดล่าง:

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


นี่คือการวิเคราะห์ที่ดี สิ่งหนึ่งที่เป็นโรคจิตผมว่าเป็นจุดของคุณเกี่ยวกับโปรแกรมที่แท้จริงของโลกมักจะไม่เป็นเปิ่นขนานและทำให้ยากที่จะคู่ขนาน: ในขณะที่มันอาจจะเป็นไปไม่ได้ที่จะทำแบบเดียวกันสิ่งที่คู่ขนานกันมันอาจจะเป็นเรื่องง่ายมากที่จะทำที่แตกต่างกันสิ่งที่อยู่ในแบบคู่ขนาน ( เช่นในสถาปัตยกรรมไปป์ไลน์หรือมีเธรด UI แยกต่างหาก)
amon

8
ประเด็นที่แท้จริงคือคุณต้องออกแบบเพื่อการทำงานแบบขนานและหากคุณไม่ได้ถูก จำกัด ด้วยการขาดการออกแบบ ผมเห็นว่ามันสามารถเป็นเรื่องง่ายมากที่จะทำสิ่งที่แตกต่างในแบบคู่ขนาน แต่ไม่ถ้ามันเป็นโปรแกรมที่มีอยู่กับความคาดหวังของผู้ใช้สูง ในกรณีนี้อาจต้องมีการเขียนใหม่เพื่อให้เป็นไปได้ การเขียนซ้ำมีความเสี่ยงโดยเนื้อแท้ แต่บางครั้งคุณก็สามารถโต้แย้งได้ดี ฉันได้ทำการเขียนซ้ำสองสามครั้งซึ่งเพิ่มการประมวลผลแบบขนานในขณะที่รักษารหัสให้มากที่สุดเท่าที่จะทำได้ มีจำนวนมากของปัจจัยที่ซ่อนอยู่
Berin Loritsch

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

35

มีโปรแกรมมากมาย (โดยเฉพาะเกม) โดยใช้การทำงานพร้อมกัน

ไม่จริงๆแล้วมันเป็นสิ่งที่ตรงกันข้าม แอพส่วนใหญ่เขียนด้วยความคิดเธรดเดียวและนักพัฒนาซอฟต์แวร์ไม่เคยทำการเปลี่ยนแปลงที่จำเป็นเพื่อสนับสนุนการทำงานพร้อมกัน

ใน C, C ++ และ C # คุณต้องบอกแอปพลิเคชันอย่างชัดเจนเพื่อเริ่มกระทู้และ / หรือกระบวนการใหม่

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

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

โดยทั่วไปเมื่อแอปพลิเคชันแจ้งว่าไม่สามารถใช้หลายคอร์ได้นั่นหมายความว่าพวกเขาไม่มีการซิงโครไนซ์เพื่อปกป้องการจัดการข้อมูล


สิ่งนี้เป็นจริงแม้สำหรับโปรแกรมที่ทันสมัยใหม่จากนักพัฒนา / ผู้เผยแพร่รายใหญ่? เมื่อฉันนั่งลงและเขียนโปรแกรมสิ่งแรกในขั้นตอนการออกแบบที่ฉันคิดคือฉันต้องเห็นพ้องด้วยหรือไม่ เพราะมันสามารถส่งผลในการออกแบบที่แตกต่างกันอย่างมาก เกมโดยเฉพาะจะต้องมีระดับของการเกิดขึ้นพร้อมกันมิฉะนั้นเกมจะหยุดเมื่อหนึ่งในพันรุ่นบนหน้าจอพยายามทำอะไร ...
SnakeDoc

5
@SnakeDoc - ฉันคิดว่าคุณสับสนโดเมนของคุณที่นั่น บริษัท ยักษ์ใหญ่อย่างแน่นอนเขียนด้วยความพร้อมกันในใจ แต่ฉันยังไม่เห็นเกมจาก บริษัท เกมใหญ่ที่ไม่สนับสนุนการทำงานพร้อมกัน แอพและเกมที่ฉันเห็นว่าไม่สามารถรองรับการทำงานพร้อมกันได้นั้นโดยทั่วไปแล้วจะมาจากร้านค้าขนาดเล็ก / devs ส่วนบุคคลที่พวกเขาไม่ได้เริ่มด้วยความคิดนั้น และเมื่อถึงจุดหนึ่งในวิวัฒนาการของแอปพลิเคชันมันก็เป็นไปไม่ได้ที่จะโบกสะบัดพร้อมกันหลังจากความจริง และแอพบางตัวไม่เคยตั้งใจที่จะทำพอที่จะแสดงให้เห็นถึงความพร้อมกัน

และยังมีเกมบางเกมที่เจริญเติบโตบนเนื้อหาใหม่ (กราฟิกและการเล่นเกม) โดยไม่ต้องอัปเดตเอ็นจิ้นเกม (การติดตั้งโค้ด) ดังนั้นเกมเอ็นจิ้นอาจจะล้าสมัยไปหลายปีในด้านเทคโนโลยี

6
@SnakeDoc: คุณไม่จำเป็นต้องมีภาวะพร้อมกันเพื่อจัดการกับโมเดลบนหน้าจอหลายพันรุ่น มันไม่เหมือนวัตถุทุกอย่างในเกมของคุณที่ต้องการเธรดของตัวเองเพื่อจำลองมัน หนึ่งเธรดสามารถจัดการการอัปเดตสำหรับทุกสิ่งบนหน้าจอในทุกเวลา
user2357112 รองรับโมนิก้า

13

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

ทำไมฉันต้องเขียนโปรแกรมแบบเธรดเดียว? พวกเขาเขียนได้ง่ายขึ้นและง่ายต่อการตรวจแก้จุดบกพร่อง: มีสิ่งหนึ่งเกิดขึ้นหลังจากนั้นอีกสิ่งหนึ่ง (แทนที่จะเกิดหลายสิ่งหลายอย่างพร้อมกันและเป็นไปได้ที่จะเข้าหากัน) หรือโปรแกรมของคุณอาจไม่ได้กำหนดเป้าหมายไปที่เครื่องมัลติคอร์ (เช่นกรณีของเกมเก่า) ในบางกรณีโปรแกรมแบบมัลติเธรดอาจทำงานช้ากว่าเวอร์ชั่นแบบเธรดเดียวหากค่าใช้จ่ายจากสวิทช์บริบทและการสื่อสารระหว่างเธรดมีค่ามากกว่าความเร็วที่ได้รับจากการประมวลผลแบบขนาน (บางส่วนของโปรแกรมอาจไม่ขนานกัน)


8

นี่ไม่ใช่คำตอบที่สมบูรณ์ มันเป็นเรื่องเตือน

วันหนึ่งฉันคิดว่าฉันจะให้นักเรียนในหลักสูตรการเขียนโปรแกรมพร้อมกันเป็น quicksort แบบขนาน Quicksort ควรจะขนานกันดีฉันคิด ฉันใช้สองเธรด วิ่งบนคอมพิวเตอร์แกนเดียวของฉัน ผลการวิจัยพบว่า:

  • 14 วินาทีสำหรับรุ่นที่มีเธรดเดียว
  • 15 วินาทีสำหรับเวอร์ชั่น 2 เธรด

นี่คือสิ่งที่ฉันคาดไว้

จากนั้นฉันก็ลองใช้กับเครื่องใหม่ดูอัลคอร์

  • 11 วินาทีสำหรับเวอร์ชั่นที่มีเธรดเดียว
  • 20 วินาทีสำหรับเวอร์ชั่น 2 เธรด

เธรดทั้งสองแบ่งใช้คิวงานที่เหลืออยู่ ดูเหมือนว่าฟิลด์ของวัตถุคิวจะถูกสับเปลี่ยนไปมาระหว่างแคชของคอร์หนึ่งและอีกซีก


2
คุณทดสอบองค์ประกอบอาร์เรย์กี่รายการ บางทีการผสานกันอาจจะเหมาะสมกว่าเนื่องจากการเขียนโปรแกรมแบบมัลติคอร์จำเป็นต้องคัดลอกข้อมูลเพื่อหลีกเลี่ยงความขัดแย้งของแคช

2
@rwong มีองค์ประกอบอาร์เรย์ 10,000,000 รายการ การรวมกันอย่างแน่นอนจะขนานกัน ถ้าฉันใช้การเรียงลำดับผสานฉันอาจจะไม่ได้เรียนรู้บทเรียนที่มีประโยชน์
Theodore Norvell

1
@ArlaudPierre ฉันจะพิจารณาทำขนานอัลกอริทึมใด ๆ Quicksort มีความน่าสนใจเนื่องจากคุณสามารถใช้วิธีการแบบ bag-of-task เนื่องจากงานมีความเป็นอิสระปรีชาญาณของฉันคือควรเป็นตัวอย่างของความเท่าเทียมที่น่าอับอาย ฉันควรพูดถึงว่าหลังจากปรับจูนจริง ๆ แล้วมันก็มีความเร็วถึง 2
Theodore Norvell

1
@Jules คำตอบคือสมดุลภาระ นอกจากนี้ฉันต้องการเขียนด้วยวิธีที่ทำให้จำนวนเธรดเปลี่ยนแปลงได้ง่าย วิธีการของคุณพูดถึงพลังของ 2 อย่างชัดเจน แต่ก็ไม่ค่อยดีนักสำหรับจำนวนเธรดอื่น ๆ
Theodore Norvell

2
@MaciejPiechotka ศีลธรรมเป็นสิ่งที่คุณแนะนำ แต่กลับมาที่ OP ฉันคิดว่าคุณธรรมที่เกี่ยวข้องที่สุดคือโปรแกรมแบบมัลติเธรดอาจทำงานช้าลง (มาก) บนสถาปัตยกรรมแบบมัลติคอร์มากกว่าในตัวประมวลผลแกนเดียว
Theodore Norvell
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.