Mengapa prosesor Itanium sulit untuk menulis kompiler?

Secara umum dinyatakan bahwa arsitektur prosesor Itanium 64-bit Intel gagal karena set instruksi EPIC yang revolusioner sangat sulit untuk menulis kompiler yang baik, yang berarti kurangnya alat pengembang yang baik untuk IA64, yang berarti kurangnya pengembang membuat program untuk arsitektur. , dan tidak ada yang ingin menggunakan perangkat keras tanpa banyak perangkat lunak untuk itu, dan platform gagal, dan semua untuk keinginanpaku tapal kuda kompiler yang bagus.

Tetapi mengapa hal-hal kompiler menjadi masalah teknis yang sulit? Tampak bagi saya bahwa jika paralelisme eksplisit dalam EPIC sulit bagi vendor kompiler untuk mengimplementasikan ... mengapa menempatkan beban pada mereka di tempat pertama? Ini tidak seperti solusi yang baik, yang dipahami dengan baik untuk masalah ini belum ada: menempatkan beban pada Intel sebagai gantinya dan memberikan kompiler-penulis target yang lebih sederhana.

Itanium keluar pada tahun 1997. Pada titik ini, sistem bytecode P-Code UCSD berusia hampir 20 tahun, mesin-Z sedikit lebih muda, dan JVM adalah bintang baru yang sedang naik daun di dunia bahasa pemrograman. Apakah ada alasan mengapa Intel tidak menentukan bahasa "bytecode Itanium sederhana", dan menyediakan alat yang mengubah bytecode ini menjadi kode EPIC yang dioptimalkan, meningkatkan keahlian mereka sebagai orang yang merancang sistem di tempat pertama?

Seingat saya pada saat itu, masalahnya bukan hanya masalah IA64, itu adalah persaingan dengan set instruksi AMD x86-64. Dengan membuat arsitektur mereka yang kompatibel dengan set instruksi x86, AMD dapat memanfaatkan alat dan set keterampilan pengembang yang ada. Langkah AMD begitu sukses sehingga Intel (dan Via) pada dasarnya terpaksa mengadopsi arsitektur x86-64.

Hambatan besar pada saat itu adalah 4 GB RAM pada PC desktop (lebih realistis ~ 3,4GB dapat digunakan pada Windows). x86-64 menghancurkan penghalang itu dan membuka komputasi daya yang lebih tinggi untuk semua orang. Seandainya AMD tidak pernah menghasilkan x86-64, saya yakin Intel akan senang memiliki semua orang yang ingin melompat ke 4GB + RAM membayar premi yang lumayan selama bertahun-tahun untuk hak istimewa itu. Menunjukkan betapa lambatnya pasar bergerak, perlu bertahun-tahun bagi aplikasi untuk mengejar pemrograman 64-bit, multi-threaded, dan bahkan sekarang 4GB RAM merupakan standar pada PC low-end.

Singkatnya, Intel mencoba membuat lompatan revolusioner dengan arsitektur IA64, dan AMD membuat langkah evolusi dengan x86-64. Di pasar yang mapan, langkah-langkah evolusi yang memungkinkan pekerja pengetahuan memanfaatkan keterampilan yang ada akan memenangkan langkah-langkah revolusioner yang mengharuskan setiap orang untuk mempelajari keterampilan baru. Terlepas dari perbedaan kualitatif antara arsitektur, IA64 tidak dapat mengatasi momentum platform x86 sendiri begitu AMD menambahkan ekstensi x86-64.

Saya tidak membeli penjelasan bahwa IA64 terlalu sulit untuk diprogram. Itu hanya relatif sulit dibandingkan dengan alternatif. @ delnan poin tentang IR tingkat rendah memukul, saya hanya tidak berpikir itu akan membuat perbedaan.

Mengapa Intel tidak mencoba memikul beban itu sendiri, siapa tahu? Mereka adalah kekuatan pasar pada saat itu. AMD adalah sesuatu yang mengancam tetapi Intel adalah raja bukit. Mungkin mereka berpikir bahwa IA64 akan jauh lebih baik daripada apa pun sehingga mereka dapat menggerakkan seluruh pasar. Mungkin mereka mencoba untuk membuat tingkat premium dan meninggalkan AMD, VIA, dll. Di tingkat kedua memperebutkan perangkat keras komoditas bermargin rendah - sebuah strategi yang digunakan baik oleh Intel maupun Apple.

Apakah Itanium merupakan upaya yang disengaja untuk membuat platform premium dan mengeluarkan permadani dari bawah AMD, VIA, dll.? Tentu saja, begitulah cara kerja bisnis.

The artikel Wikipedia pada EPIC telah digariskan banyak bahaya umum untuk VLIW dan EPIC.

Jika ada yang tidak menangkap rasa fatalisme dari artikel itu, izinkan saya menyoroti ini:

Memuat respons dari hierarki memori yang mencakup cache CPU dan DRAM tidak memiliki penundaan deterministik.

Dengan kata lain, setiap desain perangkat keras yang gagal mengatasi (*) latensi non-deterministik dari akses memori hanya akan menjadi kegagalan yang spektakuler.

(*) Dengan "mengatasi", perlu untuk mencapai kinerja eksekusi yang cukup baik (dengan kata lain, "biaya-kompetitif"), yang mengharuskan tidak membiarkan CPU jatuh menganggur selama puluhan hingga ratusan siklus begitu sering.

Perhatikan bahwa strategi mengatasi yang digunakan oleh EPIC (disebutkan dalam artikel Wikipedia yang ditautkan di atas) tidak benar-benar menyelesaikan masalah. Itu hanya mengatakan bahwa beban mengindikasikan ketergantungan data sekarang jatuh pada kompiler. Tidak apa-apa; kompiler sudah memiliki informasi itu, sehingga mudah bagi compiler untuk mematuhinya. Masalahnya adalah bahwa CPU masih akan menganggur selama puluhan hingga ratusan siklus melalui akses memori. Dengan kata lain, itu mengeksternalkan tanggung jawab sekunder, sementara masih gagal mengatasi tanggung jawab utama.

Pertanyaannya dapat diulangi sebagai: "Mengingat platform perangkat keras yang ditakdirkan untuk gagal, mengapa (1) tidak (2) tidak bisakah penulis kompiler membuat upaya heroik untuk menebusnya?"

Saya harap kalimat ulang saya akan membuat jawaban untuk pertanyaan itu jelas.

Ada aspek kedua dari kegagalan yang juga fatal.

Strategi coping (disebutkan dalam artikel yang sama) mengasumsikan bahwa prefetching berbasis perangkat lunak dapat digunakan untuk memulihkan setidaknya sebagian dari kehilangan kinerja karena latensi non-deterministik dari akses memori.

Pada kenyataannya, pengambilan awal hanya menguntungkan jika Anda melakukan operasi streaming (membaca memori secara berurutan, atau sangat dapat diprediksi).

(Yang mengatakan, jika kode Anda membuat akses sering ke beberapa area memori lokal, caching akan membantu.)

Namun, sebagian besar perangkat lunak untuk keperluan umum harus membuat banyak akses memori acak. Jika kami mempertimbangkan langkah-langkah berikut:

• Hitung alamatnya, lalu
• Baca nilainya, lalu
• Gunakan dalam beberapa perhitungan

Untuk sebagian besar perangkat lunak serba guna, ketiganya harus dijalankan secara berurutan. Dengan kata lain, tidak selalu mungkin (dalam batas-batas logika perangkat lunak) untuk menghitung alamat di muka, atau untuk menemukan cukup banyak pekerjaan yang harus dilakukan untuk mengisi kios di antara tiga langkah ini.

Untuk membantu menjelaskan mengapa tidak selalu mungkin menemukan pekerjaan yang cukup untuk mengisi kedai, berikut adalah bagaimana orang dapat memvisualisasikannya.

• Katakanlah, untuk menyembunyikan warung secara efektif, kita perlu mengisi 100 instruksi yang tidak bergantung pada memori (jadi tidak akan menderita latensi tambahan).
• Sekarang, sebagai seorang programmer, silakan memuat semua perangkat lunak pilihan Anda menjadi disassembler. Pilih fungsi acak untuk analisis.
• Bisakah Anda mengidentifikasi di mana saja urutan 100 instruksi (*) yang secara eksklusif bebas dari akses memori?

(*) Jika kita bisa NOPmelakukan pekerjaan yang bermanfaat ...

CPU modern mencoba untuk mengatasi hal yang sama dengan menggunakan informasi dinamis - dengan secara bersamaan melacak kemajuan setiap instruksi ketika mereka beredar melalui pipa. Seperti yang saya sebutkan di atas, bagian dari informasi dinamis tersebut adalah karena latensi memori yang non-deterministik, oleh karena itu tidak dapat diprediksi pada tingkat akurasi apa pun oleh kompiler. Secara umum, tidak ada cukup informasi yang tersedia pada waktu kompilasi untuk membuat keputusan yang mungkin dapat mengisi kios-kios itu.

Menanggapi jawaban oleh Pemrogram

Bukannya "compiler ... mengekstraksi paralelisme itu sulit".

Penataan ulang memori dan instruksi aritmatika oleh kompiler modern adalah bukti bahwa ia tidak memiliki masalah mengidentifikasi operasi yang independen dan dengan demikian secara bersamaan dapat dieksekusi.

Masalah utama adalah bahwa latensi memori non-deterministik berarti bahwa "pasangan instruksi" apa pun yang telah dikodekan untuk prosesor VLIW / EPIC pada akhirnya akan terhenti karena akses memori.

Mengoptimalkan instruksi yang tidak terhenti (hanya register, aritmatika) tidak akan membantu dengan masalah kinerja yang disebabkan oleh instruksi yang sangat mungkin terhenti (akses memori).

Ini adalah contoh kegagalan untuk menerapkan aturan optimasi 80-20: Mengoptimalkan hal-hal yang sudah cepat tidak akan secara bermakna meningkatkan kinerja keseluruhan, kecuali hal-hal yang lebih lambat juga dioptimalkan.

Menanggapi jawaban oleh Basile Starynkevitch

Ini bukan "... (apa pun) yang sulit", EPIC tidak cocok untuk platform apa pun yang harus mengatasi dinamika tinggi dalam latensi.

Misalnya, jika sebuah prosesor memiliki semua hal berikut:

• Tidak ada akses memori langsung;
  • Setiap akses memori (baca atau tulis) harus dijadwalkan dengan transfer DMA;
• Setiap instruksi memiliki latensi eksekusi yang sama;
• Eksekusi dalam pesanan;
• Unit eksekusi lebar / vektor;

Maka VLIW / EPIC akan cocok.

Di mana orang menemukan prosesor seperti itu? DSP. Dan di sinilah VLIW berkembang.

Jika dipikir-pikir, kegagalan Itanium (dan upaya R&D yang terus-menerus mengalir ke dalam kegagalan, terlepas dari bukti nyata) adalah contoh kegagalan organisasi, dan layak untuk dipelajari secara mendalam.

Memang, usaha vendor lainnya, seperti hyperthreading, SIMD, dll., Tampaknya sangat sukses. Ada kemungkinan bahwa investasi dalam Itanium mungkin memiliki efek yang memperkaya pada keterampilan para insinyurnya, yang mungkin memungkinkan mereka untuk menciptakan generasi berikutnya dari teknologi yang sukses.

TL; DR: 1 / ada aspek lain dalam kegagalan Itanium daripada masalah kompiler dan mereka mungkin cukup untuk menjelaskannya; 2 / a byte code tidak akan menyelesaikan masalah kompiler.

Secara umum dinyatakan bahwa arsitektur prosesor Itanium 64-bit Intel gagal karena set instruksi EPIC yang revolusioner sangat sulit untuk menulis kompiler yang baik untuk

Yah, mereka juga terlambat (direncanakan untuk 98, pengiriman pertama pada tahun 2001) dan ketika mereka akhirnya mengirimkan perangkat keras, saya bahkan tidak yakin bahwa itu memberikan apa yang dijanjikan untuk tanggal sebelumnya (IIRC, mereka setidaknya menjatuhkan sebagian dari emulasi x86 yang awalnya direncanakan), jadi saya tidak yakin bahwa meskipun masalah kompilasi telah diselesaikan (dan AFAIK, belum), mereka akan berhasil. Aspek kompiler bukan satu-satunya aspek yang terlalu ambisius.

Apakah ada alasan mengapa Intel tidak menentukan bahasa "bytecode Itanium sederhana", dan menyediakan alat yang mengubah bytecode ini menjadi kode EPIC yang dioptimalkan, meningkatkan keahlian mereka sebagai orang yang merancang sistem di tempat pertama?

Saya tidak yakin di mana Anda menempatkan alat.

Jika berada di prosesor, Anda hanya memiliki arsitektur mikro lain dan tidak ada alasan untuk tidak menggunakan x86 sebagai ISA publik (setidaknya untuk Intel, ketidakcocokan memiliki biaya yang lebih tinggi daripada apa pun yang dapat membawa ISA publik yang lebih bersih).

Jika eksternal, mulai dari kode byte membuatnya lebih sulit daripada memulai dari bahasa tingkat yang lebih tinggi. Masalah dengan EPIC adalah bahwa ia hanya dapat menggunakan paralelisme yang dapat ditemukan oleh kompiler, dan mengekstraksi paralelisme itu sulit. Mengetahui aturan bahasa memberi Anda lebih banyak kemungkinan daripada jika Anda dibatasi oleh sesuatu yang sudah dijadwalkan. Ingatan saya (diakui tidak dapat diandalkan dan dari seseorang yang mengikuti dari jauh) adalah bahwa apa yang gagal dicapai HP (*) dan Intel pada front kompiler adalah ekstraksi paralelisme tingkat bahasa, bukan level rendah yang seharusnya ada dalam byte kode.

Anda mungkin meremehkan biaya prosesor saat ini mencapai kinerja mereka. OOO lebih efektif daripada kemungkinan lain, tetapi jelas tidak efisien. EPIC ingin menggunakan anggaran area yang digunakan oleh implementasi OOO untuk menyediakan lebih banyak komputasi mentah, berharap bahwa kompiler akan dapat memanfaatkannya. Seperti yang ditulis di atas, tidak hanya kita masih tidak dapat - seperti AFAIK, bahkan dalam teori - untuk menulis kompiler yang memiliki kemampuan itu, tetapi Itanium mendapatkan cukup banyak fitur yang sulit untuk diimplementasikan sehingga terlambat dan daya bakunya tidak bahkan kompetitif (kecuali mungkin di beberapa ceruk pasar dengan banyak perhitungan FP) dengan prosesor high-end lainnya ketika keluar dari hebat.

(*) Anda juga tampaknya meremehkan peran HP dalam EPIC.

Beberapa hal.

IPF salah, salah satunya. Ini berarti Anda tidak bisa mengandalkan pemesanan ulang untuk menyelamatkan Anda jika ada cache miss atau acara jangka panjang lainnya. Akibatnya, Anda akhirnya harus mengandalkan fitur spekulatif - yaitu, beban spekulatif (beban yang dibiarkan gagal - berguna jika Anda tidak tahu apakah Anda akan membutuhkan hasil beban) dan muatan lanjutan (muatan yang bisa Jalankan kembali, menggunakan kode pemulihan, jika terjadi bahaya.) Melakukan ini dengan benar sulit, beban lanjutan terutama! Ada juga petunjuk prefetch cabang dan cache yang benar-benar hanya dapat digunakan secara cerdas oleh programmer perakitan atau menggunakan optimasi yang dipandu profil, biasanya tidak dengan kompiler tradisional.

Mesin lain pada saat itu - yaitu UltraSPARC - dalam urutan, tetapi IPF memiliki pertimbangan lain juga. Salah satunya adalah ruang encoding. Instruksi Itanium, pada dasarnya, tidak terlalu padat - bundel 128-bit berisi tiga operasi dan bidang templat 5-bit, yang menggambarkan operasi dalam bundel, dan apakah mereka semua bisa mengeluarkan bersama. Ini dibuat untuk ukuran operasi 42,6 bit yang efektif - dibandingkan dengan 32 bit untuk sebagian besar operasi RISC komersial pada saat itu. (Ini sebelum Thumb2, dkk - RISC masih berarti kekakuan dengan panjang tetap.) Lebih buruk lagi, Anda tidak selalu memiliki cukup ILP agar sesuai dengan template yang Anda gunakan - jadi Anda harus NOP-pad untuk mengisi template atau bundel. Ini, dikombinasikan dengan kepadatan rendah relatif yang ada, berarti bahwa mendapatkan tingkat hit i-cache yang layak adalah a) sangat penting,

Sementara saya selalu merasa bahwa argumen "kompiler adalah satu-satunya masalah" terlalu banyak - ada masalah mikroarsitektur yang sah yang benar-benar tidak menyukai kode tujuan umum - itu tidak terlalu menyenangkan untuk menghasilkan kode untuk dibandingkan ke mesin OoO yang lebih sempit dan lebih tinggi waktunya. Ketika Anda benar-benar bisa mengisinya dengan benar, yang sering melibatkan PGO atau pengkodean tangan, itu sangat bagus - tetapi seringkali, kinerja dari kompiler benar-benar tidak menarik. IPF tidak membuatnya mudah untuk menghasilkan kode yang hebat, dan itu tidak bisa dimaafkan ketika kode itu tidak bagus.

Tetapi mengapa hal-hal kompiler menjadi masalah teknis yang sulit? Tampak bagi saya bahwa jika paralelisme eksplisit dalam EPIC sulit bagi vendor kompiler untuk mengimplementasikan ... mengapa menempatkan beban pada mereka di tempat pertama? Ini tidak seperti solusi yang baik, yang dipahami dengan baik untuk masalah ini belum ada: menempatkan beban pada Intel sebagai gantinya dan memberikan kompiler-penulis target yang lebih sederhana.

Apa yang Anda jelaskan adalah apa yang Transmeta coba lakukan dengan perangkat lunak morphing kode mereka (yang secara dinamis menerjemahkan x86 "bytecode" ke dalam kode mesin internal Transmeta).

Mengenai mengapa Intel gagal membuat kompiler yang cukup baik untuk IA64 ... Saya kira mereka tidak memiliki keahlian kompiler yang cukup di rumah (bahkan jika mereka memang memiliki beberapa ahli kompiler yang sangat baik di dalam, tetapi mungkin tidak cukup untuk membuat massa kritis). Saya kira manajemen mereka meremehkan upaya yang diperlukan untuk membuat kompiler.

AFAIK, Intel EPIC gagal karena kompilasi untuk EPIC sangat sulit, dan juga karena ketika teknologi kompiler perlahan dan bertahap ditingkatkan, pesaing lain di mana juga dapat meningkatkan kompiler mereka (misalnya untuk AMD64), berbagi beberapa pengetahuan kompiler.

BTW, saya berharap AMD64 akan menjadi set instruksi RISCy lagi. Bisa jadi itu adalah POWERPC64 (tapi mungkin bukan karena masalah paten, karena tuntutan Microsoft pada waktu itu, dll ...). Arsitektur set instruksi x86-64 sebenarnya bukan arsitektur "sangat bagus" untuk penulis kompiler (tapi entah bagaimana "cukup baik").

Juga arsitektur IA64 telah membangun dalam beberapa batasan yang kuat, misalnya 3 instruksi / kata sudah baik selama prosesor memiliki 3 unit fungsional untuk memprosesnya, tetapi begitu Intel pergi ke chip IA64 yang lebih baru mereka menambahkan lebih banyak unit fungsional, dan instruksi- paralelisme tingkat sekali lagi sulit dicapai.

Mungkin RISC-V (yang merupakan sumber terbuka ISA) secara bertahap akan cukup berhasil untuk membuatnya bersaing dengan prosesor lain.

Seperti yang dikatakan Robert Munn - kurangnya kompatibilitas ke belakang yang membunuh Itanium (dan banyak teknologi "baru" lainnya).

Saat menulis kompiler baru mungkin sulit, Anda hanya perlu beberapa di antaranya. Kompiler AC yang menghasilkan kode yang dioptimalkan adalah suatu keharusan - jika tidak, Anda tidak akan memiliki Sistem Operasi yang bisa digunakan. Anda memerlukan kompiler C ++, Java dan mengingat bahwa basis pengguna utama adalah Windows semacam Visual Basic. Jadi ini bukan masalah. Ada sistem operasi yang layak (NT) dan kompiler C yang baik tersedia.

Apa yang tampak seperti upaya sepele bagi perusahaan yang menawarkan produk perangkat lunak - kompilasi ulang dan uji ulang basis kode C Anda (dan pada saat itu sebagian besar akan ditulis dalam C murni!) Tidak sesederhana itu; mengkonversi sejumlah besar program C yang diasumsikan bilangan bulat 32 bit dan diasumsikan pengalamatan 32 bit ke arsitektur 64 bit asli penuh dengan perangkap. Seandainya IA64 menjadi chip yang dominan (atau bahkan yang populer!) Sebagian besar perusahaan perangkat lunak akan menggigit peluru dan melakukan upaya.

Begitu cepatnya chip dengan OS yang masuk akal tetapi perangkat lunak yang tersedia sangat terbatas, oleh karena itu tidak banyak orang yang membelinya, oleh karena itu tidak banyak perusahaan perangkat lunak yang menyediakan produk untuk itu.

Apa yang membunuh Itanium adalah keterlambatan pengiriman yang membuka pintu bagi AMD64 untuk melangkah sebelum vendor perangkat lunak berkomitmen untuk bermigrasi ke IA64 untuk aplikasi 64 bit.

Meninggalkan pengoptimalan ke kompiler adalah ide yang bagus. Banyak hal dapat dilakukan secara statis yang sebaliknya tidak efisien dalam perangkat keras. Kompiler menjadi sangat baik dalam hal itu, terutama ketika menggunakan profil PGO (saya bekerja di HP dan kompiler HP cenderung mengungguli Intel). Namun PGO sulit dijual, ini merupakan proses yang sulit untuk kode produksi.

IPF dimaksudkan untuk kompatibel ke belakang, tetapi begitu AMD64 diluncurkan menjadi diperdebatkan, pertempuran itu hilang dan saya percaya perangkat keras X86 dalam CPU baru saja dilucuti untuk retarget sebagai CPU server. Itanium sebagai arsitektur tidak buruk, 3 instruksi per kata tidak menjadi masalah. Apa yang menjadi masalah adalah implementasi hyper-threading dengan menukar tumpukan selama memori IO terlalu lambat (untuk mengosongkan dan memuat ulang pipa) sampai Montecito, dll. Yang mencegahnya bersaing dengan CPU PowerPC yang tidak sesuai pesanan. Kompiler harus menambal kelemahan yang terlambat untuk mendeteksi kelemahan implementasi CPU, dan beberapa sisi kinerja hilang karena sulit untuk memprediksi kesalahan.

Arsitekturnya memungkinkan Itanium menjadi relatif sederhana sambil menyediakan alat bagi kompiler untuk mendapatkan kinerja darinya. Jika platform itu hidup, CPU akan menjadi lebih kompleks, dan akhirnya menjadi berulir, rusak dll. Seperti x86. Namun gen pertama yang memfokuskan transistor mengandalkan skema kinerja lain karena kompiler menangani banyak hal sulit.

Platform IPF bertaruh pada kompiler dan peralatan, dan itu adalah arsitektur pertama yang mengekspos desain Unit Pemantauan Kinerja (PMU) yang sangat lengkap dan kuat, yang kemudian diangkut kembali ke Intel x86. Jadi pengembang alat yang hebat masih tidak menggunakannya untuk kemampuan penuhnya ke kode profil.

Jika Anda melihat keberhasilan ISA, seringkali bukan sisi teknis yang melempar dadu. Ini tempatnya dalam kekuatan waktu dan pasar. Lihatlah SGI Mips, DEC Alpha ... Itanium baru saja didukung oleh loosers, SGI & server HP, perusahaan dengan manajemen yang bertumpuk pada kesalahan bisnis strategis. Microsoft tidak pernah full-in dan merangkul AMD64 untuk tidak menjadi box-in dengan hanya Intel sebagai pemain, dan Intel tidak bermain dengan AMD untuk memberi mereka cara untuk hidup di ekosistem, karena mereka bermaksud untuk menghabisi AMD.

Jika Anda melihat di mana kita hari ini, perangkat keras X86 yang kompleks telah membawanya ke jalan buntu evolusi sejauh ini. Kami terjebak pada 3 + GHz, dan membuang inti dengan penggunaan yang tidak cukup. Desain Itanium yang lebih sederhana akan mendorong lebih banyak barang pada kompiler (ruang untuk pertumbuhan), memungkinkan untuk membangun jaringan pipa yang lebih tipis dan lebih cepat. Pada generasi yang sama dan teknologi yang luar biasa, itu akan berjalan lebih cepat dan menutup semua sama tetapi sedikit lebih tinggi, dengan mungkin pintu lain terbuka untuk mendorong hukum Moore.

Yah setidaknya yang di atas adalah keyakinan saya :)

Memori semakin kabur ... Itanium memiliki beberapa ide hebat yang membutuhkan dukungan kompiler hebat. Masalahnya adalah itu bukan satu fitur, itu banyak. Masing-masing bukan masalah besar, semuanya bersama-sama.

Misalnya, ada fitur pengulangan di mana satu iterasi dari pengulangan akan beroperasi pada register dari iterasi yang berbeda. x86 menangani masalah yang sama melalui kemampuan out-of-order yang masif.

Pada waktu itu Java dan JVM sedang dalam mode. Apa yang IBM katakan adalah bahwa dengan PowerPC, Anda dapat mengkompilasi bytecode dengan cepat dan CPU akan membuatnya cepat. Bukan pada Itanium.