สถาปัตยกรรมซีพียูมีอคติต่อการดำเนินการตามขั้นตอนหรือไม่?


13

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

ฉันรู้สึกว่าการออกแบบ CPU ในปัจจุบันอาจได้รับการปรับให้เหมาะสมยิ่งขึ้นสำหรับ runtimes แบบโพรซีเดอร์เช่น C หากเราต้องการปรับให้เหมาะสมสำหรับ runtimes ที่เกิดขึ้นพร้อมกัน CPU จะดูแตกต่างกันอย่างไร

สำหรับ isntance การคาดคะเนสาขาถูกนำมาใช้บนพื้นฐานของการสรุปทั่วไปในเอกสารงานวิจัยที่วิเคราะห์รหัสขั้นตอน ฉันสงสัยว่าสิ่งที่เป็นนามธรรมที่เกิดขึ้นพร้อมกันจะเพิ่มชุดการทำงานที่สำคัญให้กับรันไทม์ที่ส่งผลเสียต่ออัลกอริทึมการทำนายสาขาที่มีอยู่หรือไม่ ตัวอย่างเช่นการคาดการณ์ใน for for loop เป็นสิ่งหนึ่ง แต่เมื่อเป้าหมายของสาขาเป็นส่วนใหม่ของหน่วยความจำเสมอ (กราฟิก, ข้อความ, ฯลฯ ) มันจะเป็นแคชที่พลาดเสมอและจะไม่มีสาขา ประวัติศาสตร์สำหรับมัน - เพราะยังไม่ได้แตะต้องเลย

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

สถาปัตยกรรมของ CPU มีอคติต่อโค้ดโพรซีเดอร์มากกว่าโค้ดที่เกิดขึ้นพร้อมกันหรือไม่ หรือซีพียูรุ่นใหม่มีจุดประสงค์ทั่วไปที่เพียงพอซึ่งภาษาที่เกิดขึ้นพร้อมกันสูงไม่ประสบ


2
คุณได้ดูวรรณกรรมรอบ ๆ สถาปัตยกรรม Itanium (IA-64) แล้วหรือยัง? มันได้รับการออกแบบด้วยความฝันอันยิ่งใหญ่ของการใช้อัลตร้าพอร์ราริสซึ่ม แต่แล้วคนก็ล้มเหลวในการสร้างคอมไพเลอร์ที่จะใช้ประโยชน์จากคุณสมบัติของซีพียูและซอฟต์แวร์ก็ทำงานได้ไม่ดีนัก
Gilles 'หยุดความชั่วร้าย'

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

@Gilles: และในทำนองเดียวกันสถาปัตยกรรม Mill ใหม่ดูเหมือนจะถูกสร้างขึ้นด้วยความเท่าเทียมและสวิตช์ต้นทุนต่ำ ตัวอย่างเช่นโดยการใช้พื้นที่ที่อยู่เสมือนเดียวสำหรับ "กระบวนการ" ทั้งหมดมันจะย้อนกลับ TLB ระหว่างระดับแคชล่าสุดและตัวควบคุมอุปกรณ์ (ดูที่ 49 สไลด์ของmillcomputing.com/docs/memory )
Matthieu M.

1
@pedAntic สนิมต้องรันไทม์เป็นความเข้าใจผิดว่าเป็นเรื่องง่ายที่จะทำให้: chat.stackoverflow.com/transcript/message/24171983#24171983 ดูเหมือนว่าคำถามของคุณจะสนับสนุนความเข้าใจผิดซึ่งไม่ใช่สิ่งที่ดีสำหรับ Rust
ArtemGr

1
@pedAntic คุณจะเห็นว่า Rust มีรันไทม์พร้อมกัน (สำหรับเธรดสีเขียว) แต่ก็ไม่ได้อีกต่อไป ตอนนี้ Rust ส่วนใหญ่อยู่ในลีกเดียวกับ C ในแง่ของประวัติประสิทธิภาพการทำงานพร้อมกัน ข้อแตกต่างจาก C คือการวิเคราะห์แบบสถิตใน Rust ทำให้การเกิดพร้อมกันส่วนใหญ่ปลอดภัย
ArtemGr

คำตอบ:


1

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

เป็นเวลานานมากที่ภาษาเป้าหมายสำหรับสถาปัตยกรรมส่วนใหญ่จะเป็นภาษา "C" สิ่งนี้สะท้อนถึงความต้องการเล็กน้อยที่ภาษานั้นทำกับฮาร์ดแวร์และความจริงที่ว่ามันได้กลายเป็นภาษาการเขียนโปรแกรมระบบที่เกือบจะเป็นสากล (Sorry Rust and Go คุณมีทางที่จะเอาชนะ C ได้มาก)

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

ผลตอบแทนสำหรับโปรเซสเซอร์ที่ตรงกับคอมไพเลอร์สมัยใหม่คือโค้ดจากคอมไพเลอร์เหล่านั้นทำงานได้ดีและโปรเซสเซอร์มีโอกาสที่จะแข่งขันอย่างน้อย ค่าใช้จ่ายของความล้มเหลวที่นี่ dooms โปรเซสเซอร์ก่อนที่จะสามารถเริ่มต้น เพียงสองตัวอย่างในเชิงลบ ได้แก่ iAPX-432 และ Itanium ทั้งสองโดย Intel ทั้งสองมีความสัมพันธ์ที่ไม่ดีกับคอมไพเลอร์ของพวกเขา (Ada และ C ตามลำดับ) กับความล้มเหลวของผลิตภัณฑ์กลายเป็นเกมโทษระหว่างซิลิคอนและซอฟต์แวร์


0

ไม่ต้องสงสัยเลยว่าใช่

โดยเฉพาะอย่างยิ่งรูปแบบการสื่อสารที่บอกเป็นนัยโดย C99 นั้นคือหน่วยความจำที่ใช้ร่วมกัน ภาษาพร้อมกันขั้นสูงเพิ่มเติมมีรูปแบบการสื่อสารที่สมบูรณ์ยิ่งขึ้นเช่นช่องทางส่งข้อความ (เช่นเดียวกับในสนิม)

สถาปัตยกรรม CPU สมัยใหม่มีการสนับสนุนฮาร์ดแวร์อย่างชัดเจนสำหรับหน่วยความจำที่ใช้ร่วมกัน โดยเฉพาะอย่างยิ่งโปรโตคอลเชื่อมโยงกันแคชเช่น MESI ถูกนำไปใช้ในประตูและสายจริง ไม่มีการสนับสนุนที่แท้จริงสำหรับการส่งข้อความระหว่างกระบวนการแม้ว่าความคิดในการส่งข้อความจะไม่แปลกไปกับซีพียู รถบัส PCI-e ที่ทันสมัยแม้จะเลียนแบบหน่วยความจำที่แชร์โดยใช้การส่งผ่านข้อความในขณะที่กระบวนการของ CPU จะต้องเลียนแบบการส่งข้อความโดยใช้หน่วยความจำที่แชร์

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.