为什么Itanium处理器很难为其编写编译器？

通常说英特尔的Itanium 64位处理器体系结构失败是因为革命性的EPIC指令集很难为其编写好的编译器，这意味着缺乏IA64的良好开发人员工具，这意味着缺乏开发人员为该体系结构创建程序，因此没有人愿意使用没有太多软件的硬件，因此该平台出现了故障，并且全都需要马蹄钉 好的编译器。

但是，为什么编译器之类的东西这么难解决技术问题？在我看来，如果编译器供应商难以实现EPIC中的显式并行性，为什么首先要把负担加在它们身上？似乎还没有解决该问题的好方法，它不是一个很好的解决方案：而是将负担加在Intel上，并为编译器-编写器提供一个更简单的目标。

Itanium于1997年问世。到那时，UCSD P-Code字节码系统已有近20年的历史，Z机才更年轻，而JVM是编程语言世界中新出现的炙手可热的新星。英特尔为什么没有指定“简单的Itanium字节码”语言，而是提供一种工具，将这些字节码转换为经过优化的EPIC代码，从而利用他们最初设计系统的人员的专业知识呢？

我当时记得，问题不仅仅在于IA64的细节，还在于与AMD x86-64指令集的竞争。通过使其架构向后兼容x86指令集，AMD能够利用现有工具和开发人员技能集。AMD的举动如此成功，以至于Intel（和Via）实际上被迫采用x86-64架构。

当时最大的障碍是台式机上的4 GB RAM（实际上在Windows上约为3.4 GB可用）。x86-64打破了这一障碍，并向所有人开放了更高性能的计算。如果AMD永远不会提出x86-64，我相信英特尔会很高兴让所有想要跳到4GB + RAM的人为此特权付出多年的高额费用。为了说明市场的发展速度，应用程序花费了数年的时间才能赶上64位多线程编程，甚至现在低端PC上都标有4GB RAM。

简而言之，英特尔试图通过IA64架构实现革命性的飞跃，而AMD借助x86-64迈出了革命性的一步。在成熟的市场中，允许知识工作者利用现有技能的进化步骤将战胜要求所有人学习新技能的革命步骤。无论架构之间在质量上的差异如何，一旦AMD添加了x86-64扩展，IA64就无法克服其自身x86平台的势头。

我不接受IA64太难编程的解释。相对于其他选择而言，这只是困难。@delnan关于低级IR的观点一直存在，我只是认为这不会有所作为。

至于为什么英特尔不愿意自己承担这个负担，谁知道呢？它们是当时的市场力量。AMD是一种威胁，但英特尔是领导者。也许他们认为IA64会比其他任何东西都要好得多，以至于他们可以占领整个市场。也许他们试图在高端市场中脱颖而出，而让AMD，VIA等进入第二层争夺低利润商品硬件的竞争-英特尔和苹果公司都非常成功地采用了这一策略。

安腾是否有意制造高端平台并将产品从AMD，VIA等公司撤下？当然，这就是业务运作的方式。

EPIC上的Wikipedia文章已经概述了VLIW和EPIC的许多常见风险。

如果没有人从那篇文章中了解宿命论，让我强调一下：

来自包括CPU缓存和DRAM的内存层次结构的负载响应没有确定的延迟。

换句话说，任何无法解决（*）内存访问带来的不确定性延迟的硬件设计都将成为一个重大失败。

（*）通过“应付”，有必要获得相当好的执行性能（换句话说，“具有成本竞争力”），这有必要使CPU如此频繁地闲置数十至数百个周期。

请注意，EPIC所采用的应对策略（在上面链接的Wikipedia文章中提到）实际上并未解决问题。它只是说指示数据依赖性的负担现在落在了编译器上。没关系; 编译器已经具有该信息，因此编译器很容易遵守。问题在于，在访问内存时，CPU仍将闲置数十到数百个周期。换句话说，它外部化了次要责任，但仍然无法应付主要责任。

这个问题可以改写为：“鉴于注定要失败的硬件平台，为什么（1）没有（2）编译器编写者不能做出巨大的努力来赎回它？”

我希望我的改写将使该问题的答案显而易见。

失败的第二个方面也是致命的。

应对策略（在同一篇文章中提到）假定基于软件的预取可用于恢复由于内存访问的不确定延迟而导致的至少部分性能损失。

实际上，只有在执行流操作（以顺序或高度可预测的方式读取内存）时，预取才有收益。

（也就是说，如果您的代码频繁访问某些本地化的内存区域，则缓存会有所帮助。）

但是，大多数通用软件必须进行大量的随机内存访问。如果我们考虑以下步骤：

• 计算地址，然后
• 读取值，然后
• 在一些计算中使用它

对于大多数通用软件，这三个必须快速连续执行。换句话说，并非总是可能（在软件逻辑的范围内）预先计算地址，或者找到足够的工作来填充这三个步骤之间的停顿。

为了帮助解释为什么总是找不到足够的工作来填补摊位的原因，这是人们如何可视化它的原因。

• 假设，要有效地隐藏停顿，我们需要填充100条不依赖于内存的指令（这样就不会遭受额外的延迟）。
• 现在，作为程序员，请将您选择的任何软件加载到反汇编程序中。选择一个随机函数进行分析。
• 您能否在任何地方识别100条指令（*）的序列，而这些指令完全没有内存访问？

（*）如果我们能够做NOP一些有用的工作...

现代的CPU尝试使用动态信息来应对这些问题-通过同时跟踪每条指令在管道中循环时的进度。如上所述，该动态信息的一部分归因于不确定的内存延迟，因此编译器无法将其预测为任何准确性。通常，在编译时根本没有足够的信息来做出可能填补这些停顿的决策。

回应AProgrammer的回答

并不是说“编译器...提取并行性很困难”。

现代编译器对内存和算术指令的重新排序证明了它可以毫无问题地识别可独立执行的操作。

主要问题是不确定的存储器等待时间意味着，为VLIW / EPIC处理器编码的任何“指令配对”最终都将因存储器访问而停滞。

优化不会停顿的指令（仅用于寄存器，算术）将无法解决由极可能停顿（存储器访问）的指令所引起的性能问题。

这是无法应用80-20优化规则的一个例子：优化已经很快的事物不会有意义地提高整体性能，除非较慢的事物也得到了优化。

作为对Basile Starynkevitch的回答

这并不是说“……（无论如何）都很难”，这是因为EPIC不适合任何必须应对高动态延迟的平台。

例如，如果处理器具有以下所有功能：

• 没有直接的内存访问；
  • 任何内存访问（读或写）都必须通过DMA传输进行调度；
• 每条指令具有相同的执行延迟；
• 有序执行；
• 宽/矢量化执行单元；

那么VLIW / EPIC将是一个很好的选择。

在哪里可以找到这样的处理器？DSP。这就是VLIW蓬勃发展的地方。

事后看来，Itanium的失败（尽管有明显的证据，但R＆D努力仍不断地失败）是组织失败的一个例子，值得深入研究。

当然，供应商的其他业务，例如超线程，SIMD等，似乎都非常成功。对Itanium的投资可能会对其工程师的技能产生丰富的影响，这可能使他们能够创造下一代成功的技术。

TL; DR：1 / Itanium的失败还涉及编译器问题以外的其他方面，它们可能足以解释它；2 /字节代码无法解决编译器问题。

通常说英特尔的Itanium 64位处理器体系结构失败是因为革命性的EPIC指令集很难为

嗯，他们也很晚（计划于98年投入使用，于2001年首次交付），当他们最终交付硬件时，我什至不确定它能否交付较早的承诺（IIRC，他们至少放弃了一部分）。最初计划的x86仿真），所以我不确定即使编译问题已解决（并且AFAIK尚未解决），它们是否也会成功。编译器方面不是唯一过于雄心勃勃的方面。

英特尔为什么没有指定“简单的Itanium字节码”语言，而是提供一种工具，将这些字节码转换为经过优化的EPIC代码，从而利用他们作为最初设计系统的人员的专业知识呢？

我不确定您将工具放在哪里。

如果它在处理器中，则您只有另一个微体系结构，没有理由不将x86用作公共ISA（至少对于Intel而言，不兼容的成本要比带来更清洁的公共ISA的成本更高）。

如果是在外部，则从字节码开始比从高级语言开始更难。EPIC的问题在于，它只能使用编译器可以找到的并行性，而很难提取并行性。知道语言规则会给您带来更多的可能性，而不是受到已经安排好的事情的束缚。我（被认为是不可靠的，并且从后来的人那里得到的回忆）的回忆是，在编译器方面，HP（*）和Intel无法实现的是语言水平的并行性提取，而不是字节级中存在的低层级别。码。

您可能低估了当前处理器实现其性能所需的成本。OOO比其他可能性更有效，但肯定不是有效的。EPIC希望使用OOO实施所使用的面积预算来提供更多原始计算，希望编译器能够使用它。如上所述，不仅像AFAIK一样，即使在理论上，我们仍然无法编写具有这种能力的编译器，而且Itanium具有足够的其他难以实现的功能，以至于迟到了并且其原始功能没有当它离开工厂时，与其他高端处理器甚至具有竞争力（也许在某些具有大量FP计算能力的利基市场中除外）。

（*）您似乎也低估了HP在EPIC中的作用。

一些东西。

IPF是有秩序的。这意味着在发生缓存未命中或其他长期运行的事件时，您不能依靠重新排序来保存您。结果，您最终需要依赖推测性功能-即推测性负载（允许失败的负载-如果您不知道是否需要负载结果，则很有用）和高级负载（可能是负载如果发生危险，请使用恢复代码重新运行。）正确解决这些问题非常困难，尤其是高级负载！还存在分支和缓存预取提示，这些提示实际上只能由汇编程序员或使用配置文件引导的优化智能地使用，而通常不能与传统的编译器一起使用。

当时的其他机器（即UltraSPARC）是有序的，但是IPF也有其他考虑事项。一种是编码空间。从本质上讲，Itanium指令不是特别密集-128位捆绑软件包含三个操作和一个5位模板字段，用于描述捆绑软件中的操作以及它们是否可以一起发出。有效的操作大小为42.6位-当时大多数商用RISC的操作为32位。（这是在Thumb2等之前发布的-RISC仍然意味着固定长度的刚性。）更糟糕的是，您并不总是具有足够的ILP来适合您所使用的模板-因此，您必须使用NOP-pad来填写模板或捆绑包。加上现有的相对较低的密度，这意味着获得不错的i-cache命中率非常重要：

尽管我一直觉得“编译器是唯一的问题”的说法过分夸张-存在合法的微体系结构问题，但I2确实对通用代码没有任何帮助-生成用于比较的代码并不是一件特别有趣的事情应用于当今较窄，时钟较高的OoO机器。当您真正正确地填充它（通常涉及PGO或手工编码）时，它的确很棒-但在很多时候，编译器的性能确实令人鼓舞。IPF不能轻松地生成出色的代码，并且当代码不好时，这是不容忍的。

但是，为什么编译器之类的东西有这么棘手的技术问题呢？在我看来，如果编译器供应商难以实现EPIC中的显式并行性，为什么首先要把负担加在它们身上？似乎还没有解决该问题的好方法，它不为人知：将负担转嫁给英特尔，并为编译器编写者提供一个更简单的目标。

您所描述的是Transmeta尝试使用其代码转换软件（将x86“字节码”动态转换为Transmeta内部机器代码）进行的操作。

至于为什么英特尔没有作出一个足够好的编译器为IA64 ...我的猜测是，他们没有足够的编译器专业知识的房子（即使他们当然也有一些内部的很好的编译器专家，但可能还不够达到临界质量）。我猜想他们的管理层低估了制作编译器所需的工作。

AFAIK和Intel EPIC之所以失败，是因为针对EPIC的编译确实非常困难，而且还因为当编译器技术逐渐逐步改进时，其他竞争对手也能够改进其编译器（例如AMD64），共享了一些编译器专业知识。

顺便说一句，我希望AMD64将是更多的RISCy指令集。可能是一些POWERPC64（但可能不是因为专利问题，因为当时微软的要求等等）。对于编译器编写者来说，x86-64指令集体系结构确实不是一个“非常好”的体系结构（但是某种程度上它是“足够好”的）。

IA64架构还内置了一些强大的限制，例如，只要处理器具有3个功能单元来处理它们，那么3条指令/字就可以了，但是一旦英特尔使用更新的IA64芯片，它们就会增加更多的功能单元，并且指令-级别并行性再次难以实现。

也许RISC-V（这是一个开放源代码的ISA）将逐渐取得成功，使其在其他处理器中具有竞争力。

正如罗伯特·芒恩（Robert Munn）所指出的那样-缺乏向后兼容性导致了Itanium（以及许多其他“新”技术）的灭亡。

虽然编写新的编译器可能很困难，但您只需要其中的几个。生成优化代码的AC编译器是必须的-否则您将没有可用的操作系统。您需要使用Java的C ++编译器，并且鉴于主要用户群是Windows，因此需要某种Visual Basic。因此，这并不是真正的问题。有一个不错的操作系统（NT）和一个不错的C编译器。

对于一家提供软件产品的公司来说，似乎不费吹灰之力-重新编译和重新测试您的C代码库（那时大多数时候都是用纯C语言编写的！），这并不是那么简单。将假定32位整数并假定32位寻址的大量C程序转换为本机64位体系结构充满了陷阱。如果IA64成为占主导地位的芯片（甚至是流行的芯片！），大多数软件公司都会硬着头皮做出努力。

如此快速的芯片具有合理的操作系统，但可用的软件却非常有限，因此购买的人并不多，因此没有多少软件公司为其提供产品。

导致安腾失败的原因是发货延迟，这为软件供应商承诺针对64位应用程序迁移到IA64之前打开了AMD64介入的大门。

将优化留给编译器是一个好主意。很多事情可以静态完成，否则硬件效率低下。编译器非常擅长于此，尤其是在使用PGO分析时（我在HP工作，HP的编译器往往胜过Intel的）。PGO很难销售，但是对于生产代码而言却是困难的过程。

IPF本来是向后兼容的，但是一旦AMD64启动，它就变得毫无意义，战斗就败了，我相信CPU中的X86硬件被剥夺了重新定位为服务器CPU的目标。安腾作为一种体系结构还不错，每个字3条指令不是问题。问题在于，超线程实现是在内存IO太慢（无法清空并重新加载管道）期间交换堆栈，直到Montecito等为止，这阻止了它竞争与无序PowerPC CPU的竞争。编译器必须修补CPU实现中较晚发现的缺陷，并且由于难以预测错误而失去了一些性能优势。

该架构使Itanium相对简单，同时为编译器提供了从其监视性能的工具。如果平台运行良好，CPU将会变得更加复杂，最终变得像x86一样变得线程化，混乱。但是，由于编译器处理了很多困难的工作，因此第一代将晶体管的数量集中在其他性能方案上。

IPF平台押注在编译器和工具上，它是第一个公开极其完整且功能强大的性能监视单元（PMU）设计的体系结构，该设计随后又移植回Intel x86。因此，功能强大的工具开发人员仍然无法充分利用它来分析代码。

如果您看一下ISA的成功经验，通常不是技术方面的因素。它是时间和市场力量的地方。看看SGI Mips，DEC Alpha ... Itanium只是受到松散的服务器，SGI和HP服务器的支持，这些公司的管理人员堆积在战略业务错误中。微软从来没有全力以赴，并且拥抱AMD64不能只接受英特尔作为参与者，而英特尔也没有与AMD合作，给他们一种生存在生态系统中的方式，因为他们打算扼杀AMD。

如果您看看我们今天所处的位置，那么到目前为止，X86的复杂硬件已导致其发展陷入僵局。我们被困在3 + GHz的频率上，并且没有足够的用途来抛弃内核。Itanium的更简单设计将在编译器上增加更多内容（增长空间），从而允许构建更细，更快的管道。在同一代技术和晶圆厂技术下，它本来可以运行得更快，上限相同，但要更高一些，也许还有其他大门可以推动摩尔定律。

好吧，至少以上是我的信念：)

内存越来越模糊... Itanium有一些很棒的想法，需要强大的编译器支持。问题在于这不是一个功能，而是很多功能。每个人都没什么大不了的，所有的都在一起。

例如，有一个循环功能，其中循环的一个迭代将对来自不同迭代的寄存器进行操作。x86通过大量的无序功能来处理相同的问题。

当时，Java和JVM很流行。IBM所说的是，使用PowerPC，您可以快速编译字节码，而CPU则可以使其快速编译。不在Itanium上。