เหตุใดโปรแกรมจึงต้องใช้จำนวนแกนประมวลผลขั้นต่ำที่เฉพาะเจาะจง

เป็นไปได้ไหมที่จะเขียนโค้ด (หรือซอฟต์แวร์ที่สมบูรณ์แทนที่จะเป็นส่วนหนึ่งของรหัส) ที่ทำงานไม่ถูกต้องเมื่อทำงานบน CPU ที่มีจำนวนคอร์น้อยกว่า N? โดยไม่ตรวจสอบอย่างชัดเจนและล้มเหลวตามวัตถุประสงค์:

หาก (noOfCores <4) จากนั้นทำงานไม่ถูกต้องตามวัตถุประสงค์

ฉันกำลังดูข้อกำหนดขั้นต่ำของเกม ( Dragon Age: Inquisition ) ขั้นต่ำของเกมและระบุขั้นต่ำของซีพียูสี่คอร์ ผู้เล่นหลายคนบอกว่ามันไม่ได้ทำงานบนซีพียูสองคอร์และ EVEN บนIntel Core i3s ที่มีฟิสิคัลคอร์สองตัวและคอร์ตรรกะสองคอร์ และมันก็ไม่ได้เป็นปัญหาของพลังการคำนวณ

จากความเข้าใจของฉันเธรดจะถูกแยกออกจาก CPU อย่างสมบูรณ์โดยระบบปฏิบัติการเนื่องจากไม่สามารถทำได้

เพียงเพื่อล้างสิ่งออก:

ฉันไม่ได้ถามว่า "ฉันสามารถค้นหาจำนวนแกนประมวลผลของ CPU จากโค้ดและไม่สามารถทำได้ตามวัตถุประสงค์หรือไม่" ... รหัสดังกล่าวจะไม่ได้ตั้งใจ (บังคับให้คุณซื้อ CPU ที่มีราคาแพงกว่าเพื่อรันโปรแกรม - โดยไม่จำเป็นต้องใช้พลังงานในการคำนวณ) ฉันถามว่ารหัสของคุณพูด, มีสี่กระทู้และล้มเหลวเมื่อสองหัวข้อที่มีการทำงานบนแกนเดียวกันทางกายภาพ(ไม่ชัดเจนตรวจสอบข้อมูลของระบบและจงใจล้มเหลว)

ในระยะสั้นจะมีซอฟต์แวร์ที่ต้องใช้หลายคอร์โดยไม่จำเป็นต้องใช้พลังการประมวลผลเพิ่มเติมที่มาจากหลายคอร์หรือไม่? มันจะต้องมีแกนร่างกายแยก N

มันอาจเป็นไปได้ที่จะทำสิ่งนี้โดยบังเอิญโดยใช้ความระมัดระวังเป็นหลัก พิจารณารหัสเทียมต่อไปนี้:

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

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

(ถ้าคุณมีเธรดที่ใช้เวลานานการตั้งค่าความสัมพันธ์ของ CPU โดยทั่วไปจะปรับปรุงปริมาณงาน)

ความคิดที่ว่า บริษัท เกมกำลัง "บังคับ" ให้ผู้คนซื้อฮาร์ดแวร์ที่มีราคาแพงกว่าด้วยเหตุผลที่ไม่ดีไม่น่าเชื่อถือ มันสามารถสูญเสียลูกค้าได้

แก้ไข:โพสต์นี้มี 33 upvotes ซึ่งค่อนข้างมากเพราะมันขึ้นอยู่กับการคาดเดาการศึกษา!

ดูเหมือนว่าผู้คนมีระบบ DA: ฉันต้องทำงานไม่ดีในระบบดูอัลคอร์: http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/การวิเคราะห์นั้น ระบุว่าสถานการณ์ดีขึ้นอย่างมากหากเปิดใช้งานไฮเปอร์เธรด เนื่องจาก HT ไม่ได้เพิ่มหน่วยการเรียนการสอนหรือแคชเพิ่มเติมอีกต่อไปจึงอนุญาตให้เธรดหนึ่งรันในขณะที่เธรดอื่นอยู่ในแผงขายแคชซึ่งแนะนำอย่างยิ่งว่ามันจะเชื่อมโยงกับจำนวนเธรดอย่างหมดจด

โปสเตอร์อื่นอ้างว่าการเปลี่ยนไดรเวอร์กราฟิกใช้งานได้: http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; เนื่องจากไดรเวอร์กราฟิกมีแนวโน้มที่จะเป็นกลุ่มคนเลวทรามและคนเลวนี่ไม่น่าแปลกใจ ชุดไดรเวอร์ที่มีชื่อเสียงหนึ่งชุดมีโหมด "ถูกต้อง & ช้า" และ "เร็ว & ไม่ถูกต้อง" ซึ่งถูกเลือกถ้าเรียกใช้จาก QUAKE.EXE มีความเป็นไปได้อย่างสิ้นเชิงว่าไดรเวอร์จะทำงานแตกต่างกันไปตามจำนวนซีพียูที่แตกต่างกัน บางที (กลับไปที่การเก็งกำไร) มีการใช้กลไกการซิงโครไนซ์ที่แตกต่างกัน การใช้spinlockในทางที่ผิด?

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

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

www.ecsl.cs.sunysb.edu/tr/ashok.pdf (2008) เป็นวิทยานิพนธ์ระดับบัณฑิตศึกษาเกี่ยวกับการกำหนดเวลาที่ดีกว่าสำหรับกราฟิกการ์ดซึ่งระบุอย่างชัดเจนว่าปกติแล้วพวกเขาจะใช้การกำหนดเวลาแบบมาก่อน - หลังแรกซึ่งง่ายต่อการติดตั้ง ระบบที่ไม่ยึดเอาเสียก่อน สถานการณ์ดีขึ้นหรือไม่ อาจจะไม่.

อาจจำเป็นต้องมี 4 คอร์เนื่องจากแอปพลิเคชันรันสี่งานในเธรดแบบขนานและคาดว่าจะเสร็จเกือบพร้อมกัน

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

ข้อบกพร่องที่เกิดขึ้นเนื่องจากการกำหนดเวลาเธรดที่ไม่คาดคิดเรียกว่า " เงื่อนไขการแข่งขัน "

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

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

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

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

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

ในทางทฤษฎีคุณสามารถอัดทั้งหมดนี้ลงในแกนเดียว แต่ทุกอย่างก็ยากขึ้นมาก ทันใดนั้นคุณต้องตรวจสอบให้แน่ใจว่าสถานะของเกมทั้งหมดนั้นเกิดขึ้นเร็วพอและทำให้การเรนเดอร์ของคุณเกิดขึ้น คุณไม่สามารถทำให้พวกเขาทั้งสองซอฟต์แวร์เธรดเพราะไม่มีวิธีที่จะทำให้ระบบปฏิบัติการเข้าใจ "เธรด A ต้องทำงาน X จำนวนสมบูรณ์ใน 16 มิลลิวินาทีโดยไม่คำนึงถึงสิ่งที่เธรด B ทำ"

นักพัฒนาเกมไม่มีความสนใจในการซื้อฮาร์ดแวร์ใหม่ เหตุผลที่พวกเขามีข้อกำหนดของระบบคือค่าใช้จ่ายในการสนับสนุนเครื่องระดับล่างไม่คุ้มค่า

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

เห็นได้ชัดว่าหากเธรดเรียลไทม์กำลังรอบางสิ่งที่ไม่อนุญาตให้เข้าสู่โหมดสลีป (เช่นสปิล็อกล็อค) โปรแกรมออกแบบโปรแกรมก็เมา

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

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

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

กล่าวคือมันเป็นไปไม่ได้ที่จะเขียนซอฟต์แวร์ที่จะหยุดในน้อยกว่า N cores

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

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

ฉันคิดว่าโจชัวกำลังมุ่งหน้าไปทางที่ถูกต้องไม่ใช่เพื่อข้อสรุป

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

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

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

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

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

รหัสใด ๆ ที่ใช้ spinlocks ที่มีปริมาณของความขัดแย้งในการล็อคที่เห็นได้ชัดเจนจะทำงานได้อย่างยอดเยี่ยม (สำหรับแอพพลิเคชั่นเช่นเกม - คุณสามารถพูดว่า"ไม่ทำงาน" ) ถ้าจำนวนเธรดเกินจำนวนแกน

ลองนึกภาพตัวอย่างเช่นเธรดโปรดิวเซอร์ที่ส่งงานไปยังคิวที่ให้บริการเธรดผู้บริโภค 4 เธรด มีสองแกนเท่านั้น:

ผู้ผลิตพยายามที่จะได้รับ spinlock แต่มันถูกจัดขึ้นโดยผู้บริโภคที่ทำงานบนแกนอื่น ๆ แกนประมวลผลทั้งสองแกนกำลังล็อคอยู่ในขณะที่ผู้ผลิตกำลังหมุนรอให้ปลดล็อค นี่มันแย่อยู่แล้ว แต่ก็ไม่แย่เท่าที่ควร
โชคไม่ดีที่เธรดผู้บริโภคอยู่ในช่วงสิ้นสุดของเวลาของควอนตัมดังนั้นมันจึงถูกยึดเอาไว้ มันพยายามเก็บกุญแจไว้ แต่แน่นอนว่ามีการล็อคดังนั้นตอนนี้แกนสองแกนกำลังหมุนและรอสิ่งที่ไม่สามารถเกิดขึ้นได้
ด้ายผู้ผลิตถึงจุดสิ้นสุดของเวลาและได้รับการจองผู้บริโภคอีกรายตื่นขึ้นมา อีกครั้งที่ผู้บริโภคสองรายกำลังรอการปลดล็อคและมันจะไม่เกิดขึ้นก่อนที่ควอนตัมจะผ่านไปอีกสองครั้ง
[... ] ในที่สุดผู้บริโภคที่ถือ spinlock ได้ปลดล็อค มันถูกนำมาทันทีโดยใครก็ตามที่กำลังหมุนบนแกนอื่น ๆ มีโอกาส 75% (3 ต่อ 1) ที่เป็นเธรดผู้ใช้อื่น กล่าวอีกนัยหนึ่งมีโอกาส 75% ที่ผู้ผลิตยังคงถูกถ่วง แน่นอนว่านี่หมายความว่าผู้บริโภคก็มีส่วนสำคัญเช่นกัน หากปราศจากงานที่ต้องทำผู้ผลิตก็ไม่ต้องทำอะไรเลย

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

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

ถ้าฉันเข้าใจสิ่งที่คุณถามมันเป็นไปได้ แต่มันเป็นสิ่งที่แย่มาก ๆ

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

การพึ่งพาระหว่างระยะเวลาและความถูกต้องนี่คือสิ่งที่วิทยาศาสตร์คอมพิวเตอร์เรียกว่าสภาพการแข่งขัน

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

หากไม่สามารถเข้าถึงการออกแบบภายในของDragon Age: Inquisitionทุกคนสามารถทำได้คือคาดเดาว่าทำไมมันถึงมีพฤติกรรมแบบที่มันเป็น แต่ฉันจะไปตามสิ่งที่ฉันเห็นในประสบการณ์ของฉัน:

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

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

หากDragon Age: การสอบสวนไม่ได้ทำตามขั้นตอนง่าย ๆ เพื่อให้แน่ใจว่ามีคอร์ทางกายภาพเพียงพอก่อนดำเนินการต่อนั่นเป็นความผิดของ EA พวกเขาอาจจะใช้ฟอร์จูนฟีลดิงขนาดเล็กรองรับการโทรและอีเมลจากคนที่พยายามเรียกใช้เกมบนฮาร์ดแวร์น้อยเกินไป

หน้าต่างมีในตัวฟังก์ชั่นสำหรับการนี้: ฟังก์ชั่นGetLogicalProcessorInformationอยู่ในหน้าต่างAPI คุณสามารถเรียกมันจากโปรแกรมของคุณเพื่อรับข้อมูลเกี่ยวกับแกนหลักแกนเสมือนและไฮเปอร์เธรด

ดังนั้นคำตอบสำหรับคำถามของคุณคือ: ใช่