ฉันมักจะพบคำว่า "การเพิ่มประสิทธิภาพขนาดเล็ก" ค่อนข้างคลุมเครือ หากการเปลี่ยนแปลงระดับการเรียนการสอนในรูปแบบหน่วยความจำและรูปแบบการเข้าถึงทำให้บางสิ่งเร็วขึ้น 80 เท่าจากมืออาชีพที่มีระเบียบวินัยวัดฮอตสปอตของพวกเขาโดยไม่ลดความซับซ้อนของอัลกอริธึมนั่นคือ สำหรับฉันนั่นคือ "การเพิ่มประสิทธิภาพ mega" เพื่อทำให้บางสิ่งเร็วขึ้น 80 เท่าสำหรับเคสการใช้งานจริง ผู้คนมักพูดถึงสิ่งเหล่านี้เช่นการปรับให้เหมาะสมเช่นนั้นมีผลกระทบทางกล้องจุลทรรศน์
ฉันไม่ได้ทำงานใน gamedev อีกต่อไป แต่ฉันทำงานใน VFX ในพื้นที่เช่นการติดตามเส้นทางและฉันเห็นการใช้งานหลายอย่างของ BVHs และต้นไม้ KD ที่นั่นการประมวลผลประมาณ 0.5 ล้านรังสีต่อวินาทีในฉากที่ซับซ้อน (และนี่คือ การประเมินผลแบบมัลติเธรด) พูดอย่างคร่าว ๆ ฉันมักจะเห็นการใช้ BVH ที่ตรงไปตรงมาในบริบทของการฉายรังสีที่ต่ำกว่า 1 ล้านรังสี / วินาทีแม้จะมีการประเมินแบบมัลติเธรด ยกเว้น Embree มี BVH ที่สามารถประมวลผลมากกว่า 100 ล้านรังสีในฉากเดียวกันด้วยฮาร์ดแวร์เดียวกัน
ทั้งหมดนี้เกิดจาก "การเพิ่มประสิทธิภาพขนาดเล็ก" ที่ Embree เร็วกว่า 200 เท่า (อัลกอริธึมและโครงสร้างข้อมูลเดียวกัน) แต่แน่นอนว่าเหตุผลที่เร็วกว่านั้นมากคือเพราะนักพัฒนาของ Intel ที่อยู่เบื้องหลังนั้นเป็นมืออาชีพที่พึ่งพาโปรไฟล์และการวัด ปรับพื้นที่ที่สำคัญจริงๆ พวกเขาไม่ได้เปลี่ยนโค้ดโดยไม่คำนึงถึงลางสังหรณ์และยืนยันการเปลี่ยนแปลงซึ่งทำให้การปรับปรุง 0.000000001% มีค่าใช้จ่ายในการบำรุงรักษาที่ลดลงอย่างมีนัยสำคัญ สิ่งเหล่านี้เป็นการปรับที่แม่นยำอย่างมากที่ใช้ในมือที่มีไหวพริบ - อาจใช้กล้องจุลทรรศน์ในแง่ของการโฟกัส แต่เป็นการมองด้วยกล้องจุลทรรศน์ในแง่ของผลกระทบ
ตามธรรมชาติด้วยความต้องการอัตราเฟรมแบบเรียลไทม์ของเกมขึ้นอยู่กับว่าคุณทำงานกับเอ็นจิ้นเกมระดับสูงหรือระดับต่ำ (แม้แต่เกมที่ทำด้วย UE 4 มักใช้งานอย่างน้อยบางส่วนในสคริปต์ระดับสูง) แต่ไม่พูดชิ้นส่วนที่สำคัญที่สุดของเครื่องมือฟิสิกส์) การปรับขนาดเล็กให้เหมาะสมกลายเป็นข้อกำหนดที่ใช้ได้จริงในบางพื้นที่
พื้นที่พื้นฐานที่อยู่รอบตัวเราทุกวันคือการประมวลผลภาพเช่นการเบลอภาพความละเอียดสูงแบบเรียลไทม์และอาจทำเอฟเฟกต์อื่น ๆ ให้เป็นส่วนหนึ่งของการเปลี่ยนภาพซึ่งเราอาจเคยเห็นที่ไหนสักแห่ง คุณไม่สามารถใช้การดำเนินการเกี่ยวกับภาพดังกล่าวได้ตั้งแต่การวนลูปไปจนถึงพิกเซลทั้งหมดของภาพและคาดว่าจะได้ผลลัพธ์แบบเรียลไทม์ที่อัตราเฟรมที่ตรงกัน ถ้าเป็นซีพียูเรามักจะดูที่ SIMD และการจูนไมโครหรือเรากำลังมองหา GPU ที่มีแนวโน้มที่จะต้องใช้ความคิดระดับไมโครเพื่อเขียนอย่างมีประสิทธิภาพ
ถ้าใช่การปรับปรุงฮาร์ดแวร์เราควรคาดหวังว่าภาษาระดับสูงกว่าจะเข้าครอบงำอุตสาหกรรมเกมหรือไม่
ฉันค่อนข้างสงสัยว่าความก้าวหน้าของฮาร์ดแวร์เพียงอย่างเดียวสามารถทำได้เพราะในขณะที่ความก้าวหน้าของฮาร์ดแวร์คำแนะนำและเทคโนโลยี (เช่นฟิสิกส์บน GPU) และเทคนิครวมถึงความคาดหวังของลูกค้าสำหรับสิ่งที่พวกเขาต้องการเห็นและการแข่งขันใน วิธีที่นักพัฒนาซอฟต์แวร์มักจะก้าวไปสู่ระดับต่ำอีกครั้งเช่นเดียวกับกรณีของนักพัฒนาเว็บในขณะนี้ที่เขียน GLSL ระดับต่ำใน WebGL (การพัฒนาเว็บประเภทนี้โดยเฉพาะนั้นอยู่ในระดับต่ำกว่าเมื่อสิบหรือสองปีที่แล้ว) เนื่องจาก GLSL เป็นภาษาที่มีระดับต่ำมากและฉันไม่เคยคาดเดามาก่อนหรือสองทศวรรษที่ผ่านมาว่านักพัฒนาเว็บบางคนจะยอมรับการเขียนชิพ GPU ระดับต่ำเช่นนี้)
หากจะมีวิธีสำหรับพื้นที่สำคัญที่มีประสิทธิภาพในการย้ายไปยังภาษาระดับสูงกว่าก็จะต้องมาเพิ่มเติมจากซอฟต์แวร์และคอมไพเลอร์และเครื่องมือที่เรามีให้ตามที่ฉันเห็น ปัญหาสำหรับฉันในอนาคตอันใกล้นี้ไม่ได้เป็นฮาร์ดแวร์ที่ไม่ได้ทรงพลังพอ มีอะไรเพิ่มเติมเกี่ยวกับวิธีที่เราไม่สามารถหาวิธีที่จะพูดคุยกับมันได้อย่างมีประสิทธิภาพมากที่สุดทุกครั้งที่มีการเปลี่ยนแปลงและความก้าวหน้าโดยไม่ต้องกลับไปใช้ภาษาของตัวเองอีกครั้ง อันที่จริงแล้วการเปลี่ยนแปลงอย่างรวดเร็วของการเปลี่ยนแปลงฮาร์ดแวร์ที่ทำให้การเขียนโปรแกรมระดับสูงค่อนข้างยากสำหรับพื้นที่เหล่านี้อย่างที่ฉันเห็นเพราะหากว่าสมมุติฐานว่าฮาร์ดแวร์ของเราหยุดก้าวหน้าไปจากสีน้ำเงินในทศวรรษต่อ ๆ ไป
สนุกวันนี้เมื่อฉันทำงานในพื้นที่ที่สำคัญต่อประสิทธิภาพการทำงานของแท้ฉันต้องคิดในระดับต่ำกว่าที่ฉันเริ่มต้นบ้าง (แม้ว่าฉันจะเริ่มในยุค Borland Turbo C DOS) เพราะเมื่อก่อนแคช CPU ก็แทบจะไม่มีอยู่จริง ส่วนใหญ่เป็นเพียง DRAM และการลงทะเบียนซึ่งหมายความว่าฉันสามารถมุ่งเน้นไปที่ความซับซ้อนของอัลกอริทึมและเขียนโครงสร้างที่เชื่อมโยงเหมือนต้นไม้ในแนวตรงไปตรงมามากโดยไม่กระทบกับประสิทธิภาพมากนัก ทุกวันนี้รายละเอียดในระดับต่ำของแคช CPU ครอบงำความคิดของฉันเกือบเท่ากับอัลกอริธึมเอง และในทำนองเดียวกันเรามีเครื่องจักรหลายคอร์ซึ่งต้องทำให้เราคิดถึงมัลติเธรดและอะตอมมิกส์และ mutexes และความปลอดภัยของเธรดและโครงสร้างข้อมูลที่เกิดขึ้นพร้อมกันและอื่น ๆ ซึ่งผมบอกว่าในหลาย ๆ ด้านนั้นเป็นระดับที่ต่ำกว่ามาก ในไม่ใช่มนุษย์ธรรมดา) กว่าตอนที่ฉันเริ่ม
แปลกที่ดูเหมือนจริงมากสำหรับฉันตอนนี้ ฉันคิดว่าวันนี้ฉันได้รับผลกระทบจากความซับซ้อนและรายละเอียดระดับต่ำของฮาร์ดแวร์มากกว่าเมื่อ 30 ปีก่อนพยายามอย่างเต็มที่ที่จะถอดแว่นตาความคิดถึง แน่นอนว่าเราอาจจะพูดถึงการชุมนุมเล็กน้อยที่นี่และต้องจัดการกับรายละเอียดที่เต็มไปด้วยเลือดเช่น XMS / EMS แต่ส่วนใหญ่ฉันจะบอกว่ามีความซับซ้อนน้อยลงและการรับรู้ฮาร์ดแวร์และคอมไพเลอร์ฉันต้องย้อนกลับไปกว่าที่ฉันทำในวันนี้เมื่อฉันทำงานในพื้นที่สำคัญด้านประสิทธิภาพ และดูเหมือนว่าจะเป็นเรื่องจริงของอุตสาหกรรมทั้งหมดหากเราเขียนเหมือนกันif/else แถลงการณ์ในรูปแบบที่อ่านได้ง่ายกว่ามนุษย์มากขึ้นและพิจารณาว่าคนทั่วไปโดยรวมคิดว่ารายละเอียดฮาร์ดแวร์ในระดับที่ต่ำกว่า (จากหลายคอร์ถึง GPUs ไปจนถึง SIMD ไปยังแคชแคชและรายละเอียดภายในของคอมไพเลอร์ / ล่าม / ห้องสมุดทำงานและอื่น ๆ )
ระดับสูง! = มีประสิทธิภาพน้อยลง
กลับมาที่คำถามนี้:
ถ้าใช่การปรับปรุงฮาร์ดแวร์เราควรคาดหวังว่าภาษาระดับสูงกว่าจะเข้าครอบงำอุตสาหกรรมเกมหรือไม่
สำหรับฉันมันไม่เกี่ยวกับฮาร์ดแวร์ มันเกี่ยวกับเครื่องมือเพิ่มประสิทธิภาพและ เมื่อฉันเริ่มผู้คนเขียนเกมคอนโซลทั้งหมดในที่ชุมนุมและมีข้อได้เปรียบด้านประสิทธิภาพที่แท้จริงจากนั้นโดยเฉพาะอย่างยิ่งเมื่อไม่มีคอมไพเลอร์คุณภาพที่สร้าง 6502
เมื่อการเพิ่มประสิทธิภาพคอมไพเลอร์ C ได้อย่างชาญฉลาดในการปรับให้เหมาะสมแล้วพวกเขาก็เริ่มที่จะถึงจุดที่โค้ดระดับสูงที่เขียนใน C กำลังแข่งขันกันและบางครั้งแม้แต่โค้ดที่เขียนโดยผู้เชี่ยวชาญชุดประกอบที่ดีที่สุดในหลายพื้นที่ ที่ทำให้มันเป็นดังนั้นจึงไม่มีเกมง่ายๆที่จะใช้ C เป็นเวลาอย่างน้อยส่วนใหญ่ของการเข้ารหัสสำหรับเกม และการเปลี่ยนแปลงที่คล้ายกันก็เกิดขึ้นในบางจุดด้วย C ++ การยอมรับ C ++ นั้นช้าลงเนื่องจากฉันคิดว่าการเพิ่มประสิทธิภาพการทำงานตั้งแต่การประกอบไปจนถึง C อาจจะบรรลุข้อตกลงเป็นเอกฉันท์จาก gamedevs ในการเขียนเกมที่ไม่น่าสนใจอย่างสิ้นเชิงใน ASM เมื่อเทียบกับการเปลี่ยนจาก C เป็น C ++
แต่การเปลี่ยนแปลงเหล่านี้ไม่ได้มาจากฮาร์ดแวร์ที่มีประสิทธิภาพมากขึ้นเมื่อเครื่องมือเพิ่มประสิทธิภาพสำหรับภาษาเหล่านี้แสดงผลในระดับที่ต่ำกว่าอย่างมาก
หากคุณสามารถจินตนาการถึงสถานการณ์สมมุติที่เราสามารถเขียนโค้ดในรหัสระดับสูงสุดเท่าที่จะเป็นไปได้โดยไม่ต้องกังวลว่าจะมีหลายเธรดหรือ GPU หรือแคชหายไปหรืออะไรทำนองนั้น (อาจไม่ใช่โครงสร้างข้อมูลเฉพาะ) และเครื่องมือเพิ่มประสิทธิภาพก็เป็นปัญญาประดิษฐ์ ฉลาดและสามารถหารูปแบบหน่วยความจำที่มีประสิทธิภาพมากที่สุดในการจัดเรียงและบีบอัดข้อมูลของเราคิดว่ามันสามารถใช้ GPU บางตัวที่นี่และตรงนั้นโค้ดบางส่วนที่นี่ขนานกันที่นี่ใช้ SIMD บางตัวอาจทำโปรไฟล์เอง ตอบสนองต่อฮอตสปอตของ profiler และมันก็ทำอย่างนั้นเพื่อเอาชนะผู้เชี่ยวชาญที่ดีที่สุดของโลกแล้วมันจะไม่เป็นเกมง่ายๆแม้แต่กับผู้ที่ทำงานในสาขาที่มีประสิทธิภาพสูงที่สุดเพื่อนำมาใช้ ... และนั่นคือความก้าวหน้า มาจากเครื่องมือเพิ่มประสิทธิภาพสมาร์ทที่น่าขันไม่ใช่ฮาร์ดแวร์ที่เร็วกว่า