ทำไมโปรเซสเซอร์ Itanium จึงยากที่จะเขียนคอมไพเลอร์

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

แต่ทำไมคอมไพเลอร์จึงเป็นปัญหาทางเทคนิคที่ยาก? สำหรับฉันแล้วดูเหมือนว่าหากการขนานอย่างชัดเจนใน EPIC นั้นเป็นเรื่องยากสำหรับผู้ขายคอมไพเลอร์ที่จะใช้ ... ทำไมต้องวางภาระนั้นไว้กับพวกเขาตั้งแต่แรก มันไม่ได้เป็นวิธีแก้ปัญหาที่ดีและเข้าใจกันดีในปัญหานี้ไม่ได้มีอยู่แล้ว: วางภาระให้กับ Intel แทนและให้เป้าหมายที่เรียบง่ายแก่นักเขียนคอมไพเลอร์

Itanium ออกมาในปี 1997 โดยจุดนี้ระบบรหัสไบต์UCSD P-Codeอายุเกือบ 20 ปีเครื่อง Zอายุน้อยกว่าเล็กน้อยและ JVM เป็นดาวรุ่งพุ่งแรงใหม่ในโลกของภาษาโปรแกรม มีเหตุผลใดบ้างที่ Intel ไม่ได้ระบุภาษา "Itanium bytecode แบบง่าย" และให้เครื่องมือที่แปลง bytecode นี้เป็นรหัส EPIC ที่ได้รับการปรับปรุงโดยใช้ประโยชน์จากความเชี่ยวชาญของพวกเขาในฐานะผู้ออกแบบระบบตั้งแต่แรก?

ตามที่ฉันจำได้ในตอนนี้ปัญหาไม่ใช่เฉพาะของ IA64 เท่านั้น แต่เป็นการแข่งขันกับชุดคำสั่ง x86-64 ของ AMD ด้วยการทำให้สถาปัตยกรรมของพวกเขาเข้ากันได้กับชุดคำสั่ง x86 ทำให้ AMD สามารถใช้เครื่องมือและชุดทักษะการพัฒนาที่มีอยู่ได้ การย้ายของเอเอ็มดีประสบความสำเร็จอย่างมากโดยที่ Intel (และ Via) ถูกบังคับให้นำสถาปัตยกรรม x86-64 มาใช้เป็นหลัก

อุปสรรคใหญ่ในเวลานั้นคือ RAM 4 GB บนเดสก์ท็อปพีซี (มากกว่า ~ 3.4GB ที่ใช้งานได้จริงบน Windows) x86-64 ทุบสิ่งกีดขวางนั้นและเปิดการคำนวณพลังงานที่สูงขึ้นสำหรับทุกคน หากเอเอ็มดีไม่เคยเกิดขึ้นกับ x86-64 ฉันมั่นใจว่า Intel ยินดีที่จะให้ทุกคนที่ต้องการข้ามไปที่ 4GB + RAM จ่ายเบี้ยประกันภัยที่หนักหน่วงเป็นเวลาหลายปีเพื่อรับสิทธิพิเศษนี้ แสดงให้เห็นว่าตลาดเคลื่อนไหวอย่างช้าๆอย่างไรจึงต้องใช้เวลาหลายปีกว่าที่แอพพลิเคชั่นจะจับการเขียนโปรแกรมแบบมัลติเธรดได้ถึง 64 บิตและถึงตอนนี้ RAM 4GB เป็นมาตรฐานสำหรับพีซีระดับล่าง

ในระยะสั้น Intel พยายามก้าวกระโดดปฏิวัติด้วยสถาปัตยกรรม IA64 และ AMD ทำขั้นตอนวิวัฒนาการกับ x86-64 ในตลาดที่จัดตั้งขึ้นขั้นตอนวิวัฒนาการที่อนุญาตให้พนักงานความรู้ใช้ประโยชน์จากทักษะที่มีอยู่จะชนะในขั้นตอนการปฏิวัติที่ต้องการให้ทุกคนเรียนรู้ทักษะใหม่ โดยไม่คำนึงถึงความแตกต่างเชิงคุณภาพระหว่างสถาปัตยกรรม IA64 ไม่สามารถเอาชนะโมเมนตัมของแพลตฟอร์ม x86 ของตนเองได้เมื่อเอเอ็มดีเพิ่มส่วนขยาย x86-64

ฉันไม่ซื้อคำอธิบายว่า IA64 นั้นยากเกินกว่าจะเขียนโปรแกรมได้ มันเป็นเรื่องยากเมื่อเทียบกับทางเลือก @ จุดของ delnan เกี่ยวกับ IR ระดับต่ำที่ถูกตีฉันไม่คิดว่ามันจะสร้างความแตกต่าง

ทำไม Intel ถึงไม่พยายามแบกภาระนั้นใครจะไปรู้? พวกเขาเป็นอำนาจของตลาดในเวลานั้น เอเอ็มดีเป็นสิ่งที่คุกคาม แต่ Intel เป็นราชาแห่งขุนเขา บางทีพวกเขาคิดว่า IA64 น่าจะดีกว่าสิ่งอื่นใดที่พวกเขาสามารถเคลื่อนไหวทั่วทั้งตลาด บางทีพวกเขากำลังพยายามทำระดับพรีเมี่ยมและออกจาก AMD, VIA และอื่น ๆ ในการต่อสู้ระดับที่สองบนฮาร์ดแวร์สินค้าโภคภัณฑ์ที่มีอัตรากำไรต่ำซึ่งเป็นกลยุทธ์ที่ทั้ง Intel และ Apple ใช้งานค่อนข้างประสบความสำเร็จ

Itanium เป็นความพยายามโดยเจตนาที่จะสร้างแพลตฟอร์มระดับพรีเมียมและดึงพรมออกจากภายใต้ AMD, VIA และอื่น ๆ หรือไม่? แน่นอนว่านั่นเป็นวิธีการทำงานของธุรกิจ

บทความวิกิพีเดีย EPICได้ระบุไว้แล้วภัยหลายเรื่องธรรมดาที่จะ VLIW และ EPIC

หากใครไม่รู้สึกถึงความโชคชะตาจากบทความนั้นให้ฉันเน้นเรื่องนี้:

โหลดการตอบสนองจากลำดับชั้นหน่วยความจำซึ่งรวมถึงแคชของ CPU และ DRAM ไม่มีความล่าช้าที่กำหนดไว้

กล่าวอีกนัยหนึ่งการออกแบบฮาร์ดแวร์ใด ๆ ที่ล้มเหลวในการรับมือกับ (*) เวลาแฝงที่ไม่ได้กำหนดไว้จากการเข้าถึงหน่วยความจำจะกลายเป็นความล้มเหลวที่งดงาม

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

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

คำถามนี้สามารถใช้ถ้อยคำใหม่ได้ว่า: "เนื่องจากแพลตฟอร์มฮาร์ดแวร์ที่กำหนดไว้ว่าจะล้มเหลวเพราะเหตุใด (1) ไม่ (2) ผู้เขียนคอมไพเลอร์ไม่สามารถใช้ความพยายามอย่างกล้าหาญเพื่อไถ่มันได้"

ฉันหวังว่าการเรียบเรียงใหม่ของฉันจะทำให้คำตอบของคำถามนั้นชัดเจน

มีแง่มุมที่สองของความล้มเหลวซึ่งเป็นอันตรายถึงชีวิต

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

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

(กล่าวว่าหากรหัสของคุณเข้าถึงหน่วยความจำที่แปลเป็นภาษาท้องถิ่นบ่อยๆการแคชจะช่วยได้)

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

• คำนวณที่อยู่แล้ว
• อ่านค่าแล้ว
• ใช้ในการคำนวณบางอย่าง

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

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

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

(*) ถ้าเราสามารถทำให้NOPงานมีประโยชน์ ...

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

เพื่อตอบสนองต่อคำตอบของ AProgrammer

ไม่ใช่ว่า "คอมไพเลอร์ ... การแตกความเท่าเทียมนั้นยาก"

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

ปัญหาหลักคือเวลาแฝงของหน่วยความจำที่ไม่ได้กำหนดไว้หมายความว่า "การจับคู่คำสั่ง" สิ่งใดสิ่งหนึ่งที่เข้ารหัสไว้สำหรับโปรเซสเซอร์ VLIW / EPIC จะจบลงด้วยการเข้าถึงหน่วยความจำ

คำแนะนำการปรับให้เหมาะสมที่ไม่ได้หยุดทำงาน (ลงทะเบียนเท่านั้น, เลขคณิต) จะไม่ช่วยแก้ไขปัญหาประสิทธิภาพที่เกิดจากคำแนะนำที่น่าจะหยุดทำงาน (การเข้าถึงหน่วยความจำ)

เป็นตัวอย่างของความล้มเหลวในการใช้กฎการเพิ่มประสิทธิภาพ 80-20: การเพิ่มประสิทธิภาพสิ่งที่เร็วแล้วจะไม่ปรับปรุงประสิทธิภาพโดยรวมอย่างมีความหมายเว้นแต่สิ่งที่ช้าลงจะถูกปรับให้เหมาะสม

ในการตอบสนองต่อคำตอบโดย Basile Starynkevitch

มันไม่ใช่ "... (อะไรก็ตาม) มันยาก" มันคือ EPIC นั้นไม่เหมาะสมสำหรับแพลตฟอร์มใด ๆ ที่ต้องรับมือกับพลวัตสูงในเวลาแฝง

ตัวอย่างเช่นหากโปรเซสเซอร์มีดังต่อไปนี้:

• ไม่มีการเข้าถึงหน่วยความจำโดยตรง
  • การเข้าถึงหน่วยความจำ (อ่านหรือเขียน) ใด ๆ จะต้องถูกกำหนดโดยการถ่ายโอน DMA;
• ทุกคำสั่งมีเวลาแฝงในการเรียกใช้งานเหมือนกัน
• การดำเนินการตามลำดับ
• หน่วยประมวลผลแบบไวด์ / เวกเตอร์

จากนั้น VLIW / EPIC จะเป็นแบบที่ดี

ใครจะพบโปรเซสเซอร์ดังกล่าวที่ไหน DSP และนี่คือสิ่งที่ VLIW เจริญรุ่งเรือง

ในความเข้าใจย้อนหลังความล้มเหลวของ Itanium (และความพยายามในการวิจัยและพัฒนาอย่างต่อเนื่องในความล้มเหลวแม้จะมีหลักฐานที่ชัดเจน) เป็นตัวอย่างของความล้มเหลวขององค์กรและสมควรได้รับการศึกษาในเชิงลึก

ได้รับแล้วกิจการอื่น ๆ ของผู้ขายเช่น hyperthreading, SIMD เป็นต้นดูเหมือนจะประสบความสำเร็จอย่างสูง เป็นไปได้ว่าการลงทุนใน Itanium อาจมีผลกระทบอย่างมากต่อทักษะของวิศวกรซึ่งอาจทำให้พวกเขาสามารถสร้างเทคโนโลยีที่ประสบความสำเร็จรุ่นต่อไป

TL; DR: 1 / มีแง่มุมอื่น ๆ ในความล้มเหลวของ Itanium มากกว่าปัญหาคอมไพเลอร์และพวกเขาอาจจะดีพอที่จะอธิบายได้ 2 / a รหัสไบต์จะไม่ได้แก้ไขปัญหาคอมไพเลอร์

โดยทั่วไประบุว่าสถาปัตยกรรม Itanium 64-bit processor ของ Intel ล้มเหลวเนื่องจากชุดคำสั่งการปฏิวัติ EPIC เป็นเรื่องยากมากในการเขียนคอมไพเลอร์ที่ดีสำหรับ

พวกเขายังมาสาย (วางแผนไว้ที่ 98 ส่งครั้งแรกในปี 2544) และเมื่อพวกเขาส่งมอบฮาร์ดแวร์ในที่สุดฉันไม่แน่ใจด้วยซ้ำว่าจะส่งมอบสิ่งที่สัญญาไว้สำหรับวันที่ก่อนหน้านี้ (IIRC อย่างน้อยพวกเขาก็ทิ้งส่วนหนึ่งของ x86 อีมูเลชั่นที่วางแผนไว้ในตอนแรก) ดังนั้นฉันจึงไม่แน่ใจว่าแม้ว่าปัญหาการรวบรวมจะได้รับการแก้ไข (และ AFAIK มันยังไม่เสร็จ) พวกเขาก็จะประสบความสำเร็จ คอมไพเลอร์ไม่ได้เป็นเพียงแง่มุมเดียวที่ท้าทายความสามารถมากเกินไป

มีเหตุผลใดบ้างที่ Intel ไม่ได้ระบุภาษา "Itanium bytecode แบบง่าย" และให้เครื่องมือที่แปลง bytecode นี้เป็นรหัส EPIC ที่ได้รับการปรับปรุงโดยใช้ประโยชน์จากความเชี่ยวชาญของพวกเขาในฐานะผู้ออกแบบระบบตั้งแต่แรก?

ฉันไม่แน่ใจว่าคุณวางเครื่องมือไว้ที่ใด

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

หากเป็นภายนอกการเริ่มต้นจากรหัสไบต์ทำให้ยิ่งยากกว่าการเริ่มต้นจากภาษาระดับสูงกว่า ปัญหาของ EPIC คือมันสามารถใช้ความเท่าเทียมกันเท่านั้นที่คอมไพเลอร์สามารถค้นหาได้และการแยกความขนานนั้นยาก การรู้กฎภาษาทำให้คุณมีความเป็นไปได้มากกว่าที่คุณจะถูก จำกัด โดยสิ่งที่กำหนดไว้แล้ว ของฉัน (ยอมรับไม่น่าเชื่อถือและจากคนที่ตามมาจากที่ไกล) ความทรงจำคือสิ่งที่ HP (*) และ Intel ล้มเหลวที่จะบรรลุในหน้าคอมไพเลอร์คือการสกัดระดับภาษาของความเท่าเทียมไม่ใช่ระดับต่ำซึ่งจะมีอยู่ในไบต์ รหัส.

คุณอาจประเมินค่าต่ำกว่าซึ่งโปรเซสเซอร์ปัจจุบันบรรลุประสิทธิภาพ OOO นั้นมีประสิทธิภาพมากกว่าความเป็นไปได้อื่น ๆ แต่ก็ไม่ได้มีประสิทธิภาพอย่างแน่นอน EPIC ต้องการใช้งบประมาณพื้นที่ที่ใช้โดยการดำเนินการ OOO เพื่อให้การคำนวณแบบดิบมากขึ้นโดยหวังว่าคอมไพเลอร์จะสามารถใช้ประโยชน์ได้ ดังที่เขียนไว้ด้านบนไม่เพียง แต่เรายังไม่สามารถ - ในฐานะ AFAIK แม้แต่ในทางทฤษฎี - ในการเขียนคอมไพเลอร์ที่มีความสามารถนั้น แต่ Itanium มีคุณสมบัติที่ยากต่อการใช้งานมากพอที่จะใช้งานได้ แม้แต่การแข่งขัน (ยกเว้นในตลาดเฉพาะบางแห่งที่มีการคำนวณ FP จำนวนมาก) กับตัวประมวลผลระดับไฮเอนด์อื่น ๆ เมื่อออกจาก fab

(*) คุณดูเหมือนจะประมาทบทบาทของ HP ใน EPIC

บางสิ่ง.

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

เครื่องอื่น ๆ ในเวลานั้นคือ UltraSPARC นั้นเป็นแบบตามลำดับ แต่ IPF ก็มีข้อควรพิจารณาอื่น ๆ เช่นกัน หนึ่งคือพื้นที่เข้ารหัส คำแนะนำของ Itanium นั้นไม่ได้มีความหนาแน่นสูงโดยเฉพาะอย่างยิ่งชุดบันเดิล 128 บิตมีการดำเนินการสามรายการและฟิลด์เทมเพลต 5 บิตซึ่งอธิบายการดำเนินการในชุดรวม สิ่งนี้ทำขึ้นเพื่อประสิทธิภาพการทำงานขนาด 42.6 บิต - เปรียบเทียบกับ 32 บิตสำหรับการดำเนินงาน RISCs ส่วนใหญ่ในเวลานั้น (นี่คือก่อนที่ Thumb2, et al - RISC ยังคงหมายถึงความแข็งแกร่งที่มีความยาวคงที่) ยิ่งแย่กว่านั้นคุณมี ILP ไม่เพียงพอที่จะพอดีกับเทมเพลตที่คุณใช้อยู่ - ดังนั้นคุณต้อง NOP-pad แม่แบบหรือมัด เมื่อรวมกับความหนาแน่นต่ำสัมพัทธ์ที่มีอยู่นั่นหมายความว่าการได้รับอัตราการเข้าชม i-cache ที่เหมาะสมนั้นเป็นสิ่งที่สำคัญจริงๆ)

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

แต่ทำไมคอมไพเลอร์จึงเป็นปัญหาทางเทคนิคที่ยาก? สำหรับฉันแล้วดูเหมือนว่าหากการขนานอย่างชัดเจนใน EPIC นั้นเป็นเรื่องยากสำหรับผู้ขายคอมไพเลอร์ที่จะใช้ ... ทำไมต้องวางภาระนั้นไว้กับพวกเขาตั้งแต่แรก มันไม่ได้เป็นวิธีแก้ปัญหาที่ดีและเข้าใจกันดีในปัญหานี้ไม่ได้มีอยู่แล้ว: วางภาระให้กับ Intel แทนและให้เป้าหมายที่เรียบง่ายแก่นักเขียนคอมไพเลอร์

สิ่งที่คุณอธิบายเป็นสิ่งที่Transmetaพยายามทำกับซอฟต์แวร์ morphing code ของพวกเขา (ซึ่งแปล x86 "bytecode" เป็นแบบไดนามิกในรหัสเครื่อง Transmeta ภายใน)

ว่าทำไมไม่ Intel ล้มเหลวที่จะทำให้คอมไพเลอร์ที่ดีพอสำหรับ IA64 ... ผมคิดว่าเป็นสิ่งที่พวกเขาไม่ได้มีมากพอที่เชี่ยวชาญคอมไพเลอร์ในบ้าน (แม้ว่าแน่นอนพวกเขามีบางผู้เชี่ยวชาญคอมไพเลอร์ที่ดีมากภายใน แต่อาจไม่เพียงพอที่จะ สร้างมวลวิกฤต ฉันเดาว่าผู้บริหารประเมินความพยายามต่ำเกินไปในการสร้างคอมไพเลอร์

AFAIK, Intel EPIC ล้มเหลวเนื่องจากการคอมไพล์สำหรับ EPIC นั้นยากมากและเมื่อเทคโนโลยีคอมไพเลอร์ช้าลงและค่อย ๆ ดีขึ้นคู่แข่งรายอื่น ๆ ที่สามารถปรับปรุงคอมไพเลอร์ของพวกเขา (เช่นสำหรับ AMD64) แบ่งปันความรู้คอมไพเลอร์

BTW ฉันหวังว่า AMD64 จะเป็นชุดคำสั่ง RISCy มากกว่านี้ อาจเป็นPOWERPC64บางส่วน(แต่อาจไม่ใช่เพราะปัญหาสิทธิบัตรเนื่องจาก Microsoft มีความต้องการในเวลานั้น ฯลฯ ... ) สถาปัตยกรรมชุดคำสั่ง x86-64 ไม่ใช่สถาปัตยกรรม "ดีมาก" สำหรับนักเขียนคอมไพเลอร์ (แต่ก็เป็น "ดีพอ")

สถาปัตยกรรม IA64 ได้สร้างข้อ จำกัด ที่แข็งแกร่งเช่น 3 คำแนะนำ / คำได้ดีตราบใดที่หน่วยประมวลผลมีหน่วยการทำงาน 3 หน่วยในการประมวลผล แต่เมื่อ Intel ไปถึงชิป IA64 รุ่นใหม่พวกเขาจะเพิ่มหน่วยการทำงานที่มากขึ้น ระดับขนานเป็นอีกครั้งที่ยากที่จะบรรลุ

บางทีRISC-V (ซึ่งเป็นโอเพ่นซอร์ส ISA) จะค่อยๆประสบความสำเร็จพอที่จะทำให้มันแข่งขันกับโปรเซสเซอร์อื่น ๆ

ดังที่โรเบิร์ตมันน์ชี้ให้เห็น - มันเป็นการขาดความเข้ากันได้แบบย้อนหลังที่ฆ่า Itanium (และเทคโนโลยี "ใหม่" อื่น ๆ อีกมากมาย)

ในขณะที่เขียนคอมไพเลอร์ใหม่อาจเป็นเรื่องยากที่คุณต้องการเพียงไม่กี่คน AC คอมไพเลอร์ซึ่งสร้างรหัสที่ปรับให้เหมาะสมเป็นสิ่งจำเป็น - มิฉะนั้นคุณจะไม่มีระบบปฏิบัติการที่ใช้งานได้ คุณต้องการคอมไพเลอร์ C ++, Java และระบุว่าฐานผู้ใช้หลักคือ Windows ประเภทหนึ่งของ Visual Basic ดังนั้นนี่ไม่ใช่ปัญหาจริงๆ มีระบบปฏิบัติการที่ดี (NT) และคอมไพเลอร์ C ที่ใช้ได้

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

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

สิ่งที่ถูกฆ่าโดย Itanium คือความล่าช้าในการจัดส่งซึ่งเปิดประตูให้ AMD64 ก้าวเข้ามาก่อนที่ผู้จำหน่ายซอฟต์แวร์จะย้ายไปที่ IA64 สำหรับแอพ 64 บิต

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

IPF นั้นหมายถึงว่าสามารถใช้งานร่วมกันได้ แต่เมื่อ AMD64 เปิดตัวมันก็กลายเป็นข้อสงสัยการต่อสู้ก็หายไปและฉันเชื่อว่าฮาร์ดแวร์ X86 ในซีพียูนั้นเพิ่งถูกปล้นใหม่เพื่อเป็นเซิร์ฟเวอร์ซีพียู Itanium ในฐานะสถาปัตยกรรมไม่เลวการเรียนการสอน 3 คำต่อคำนั้นไม่เป็นปัญหา สิ่งที่เป็นปัญหาคือการนำ Hyper-Threading ไปใช้โดยการแลกเปลี่ยนสแต็คระหว่างหน่วยความจำ IO ช้าเกินไป (การล้างข้อมูลและโหลดไพพ์ไลน์) จนกระทั่ง Montecito เป็นต้นซึ่งทำให้ไม่สามารถแข่งขันกับ PowerPC CPU ที่ล้าสมัยได้ คอมไพเลอร์ต้องแก้ไขข้อบกพร่องของการใช้งานซีพียูที่ล่าช้าเพื่อตรวจจับและประสิทธิภาพการทำงานบางส่วนได้สูญเสียไปเพื่อคาดการณ์ข้อผิดพลาด

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

แพลตฟอร์ม IPF วางเดิมพันบนคอมไพเลอร์และเครื่องมือและเป็นสถาปัตยกรรมแรกที่เปิดเผยการออกแบบ Performance Monitoring Unit (PMU) ที่สมบูรณ์และทรงพลังซึ่งต่อมาได้รับการส่งกลับมายัง Intel x86 นักพัฒนาเครื่องมือที่มีประสิทธิภาพยังไม่ได้ใช้เพื่อความสามารถเต็มรูปแบบของรหัสโปรไฟล์

หากคุณดูที่ความสำเร็จของ ISA นั้นมักไม่ใช่ด้านเทคนิคที่ทอยลูกเต๋า มันเป็นสถานที่ในเวลาและกลไกตลาด ดู SGI Mips, DEC Alpha ... Itanium ได้รับการสนับสนุนจากเซิร์ฟเวอร์เซิร์ฟเวอร์ SGI & HP บริษัท ที่มีการจัดการที่ทำข้อผิดพลาดทางธุรกิจเชิงกลยุทธ์ ไมโครซอฟท์ไม่เคยเข้าร่วมเต็มรูปแบบและยอมรับ AMD64 ที่ไม่ได้รับการบรรจุในกล่องโดยมีเพียง Intel ในฐานะผู้เล่นและ Intel ไม่ได้เล่นกับ AMD เพื่อให้พวกเขามีวิธีการใช้ชีวิตในระบบนิเวศ

หากคุณดูว่าเราอยู่ที่ไหนในวันนี้ฮาร์ดแวร์ที่ซับซ้อนของ X86 ได้นำไปสู่วิวัฒนาการที่ไม่สิ้นสุด เราติดอยู่ที่ 3 + GHz และทิ้งคอร์โดยใช้ไม่เพียงพอ การออกแบบที่เรียบง่ายของ Itanium จะเพิ่มสิ่งต่าง ๆ บนคอมไพเลอร์ (ห้องสำหรับการเติบโต) ทำให้สามารถสร้างท่อที่บางและรวดเร็วกว่า ในรุ่นเดียวกันและเทคโนโลยี fab มันจะทำงานได้เร็วขึ้นและต่อยอดเหมือนกันทั้งหมด แต่สูงกว่าเล็กน้อยโดยอาจมีประตูอื่นเปิดให้ผลักดันกฎของมัวร์

อย่างน้อยข้างต้นคือความเชื่อของฉัน :)

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

ตัวอย่างเช่นมีคุณลักษณะการวนซ้ำที่การวนซ้ำหนึ่งรอบจะทำงานกับการลงทะเบียนจากการวนซ้ำที่แตกต่างกัน x86 จัดการปัญหาเดียวกันผ่านความสามารถในการสั่งซื้อจำนวนมาก

ในเวลานั้น Java และ JVM อยู่ในช่วงแฟชั่น สิ่งที่ IBM กล่าวก็คือด้วย PowerPC คุณสามารถรวบรวม bytecode ได้อย่างรวดเร็วและ CPU จะทำให้เร็วขึ้น ไม่ได้อยู่ใน Itanium