CPU体系结构是否偏向于程序运行时？

是否可以对CPU进行任何更改，以使它们在诸如Rust的并行运行时性能更好？例如，是否对分支预测实现或缓存大小进行了更改，以帮助并发运行时？

我的印象是，当前的CPU设计可能会针对诸如C之类的过程运行时进行更多优化。如果我们改为针对并发运行时进行优化，那么CPU看起来会有什么不同？

出于重要性，分支预测是基于分析过程代码的研究论文中得出的概括来实现的。我想知道并发抽象是否会给运行时添加一个重要的工作集，从而对现有分支预测算法产生不利影响。例如，在for循环中进行预测是一回事，但是当分支的目标始终是内存的某些新部分（图形，文本等）时，它将始终是缓存未命中，并且永远不会存在分支它的历史-因为还没有人碰过它。

这可能是一个愚蠢的问题，因为尽管内容可能始终位于RAM中，但其内容将被分支到比将要使用的数量级小（一旦被加载到缓存中）...但是仍然在过程运行时中，它应该是存储在缓存和分支预测变量中的上下文的可观察时间边界，这在更加并行化的环境中将表现为抽象边界。所以我想知道...是否遵守了这些界限？有研究论文对此进行分析吗？

CPU体系结构是否偏向于过程代码而不是并发代码？还是现代的CPU具有足够的通用性而不会遭受高并发语言的困扰？

computer-architecture concurrency functional-programming

— 增加
source

您是否看过有关Itanium（IA-64）体系结构的文献？它的设计梦想着超并行技术的宏伟梦想，但是后来人们未能开发出能够利用CPU功能的编译器，而软件毕竟表现不佳。

— 吉尔（Gilles）“所以，别再邪恶了”

@吉尔斯是的。尽管是一个不同的问题，但这实际上是一个有趣的观察-也许Itanium中引入的并行性会更适合现代并发语言？

— pa增加

@Gilles：同样，新的Mill架构似乎是在考虑并行性和低成本开关的情况下构建的。例如，通过为所有“进程”使用单个虚拟地址空间，它会将TLB推回最后一个缓存级别和设备控制器之间（请参见millcomputing.com/docs/memory的幻灯片49 ）。

— Matthieu M.

@pedAntic Rust需要运行时是一个容易造成的误解：chat.stackoverflow.com/transcript/message/24171983#24171983。您的问题似乎支持这种误解，对于Rust而言，这不是一件好事。

— ArtemGr 2015年

@pedAntic您看到，Rust 有一个并发运行时（用于绿色线程），但是现在已经没有了。就并发性能而言，Rust目前在很大程度上与C处于同一联盟。与C的唯一区别在于，Rust中的静态分析使并发几乎是安全的。

— ArtemGr 2015年

Answers:

现代计算机体系结构的设计目标可能是更多的情况是旨在提高编译器生成的代码的质量，而不用浪费模具成本和功耗。运行时库只是需要高效执行的已编译代码的特定实例。

长期以来，大多数体系结构的目标语言都是“ C”语言。这反映了该语言对其硬件提出的适度要求，以及它已成为几乎通用的系统编程语言的事实（对不起，Rust和Go，要击败C还有很长的路要走）。

这样做的结果似乎是，新语言通常仅根据它们的C等效语义来定义，以便避免使用当前计算机上可能缺少的处理器功能。

与现代编译器完美匹配的处理器的收益在于，这些编译器的代码运行良好，并且处理器至少有机会具有竞争力。在这里，失败的代价注定了处理器无法启动。否定的例子只有两个，分别是Intel的iAPX-432和Itanium。两家公司与他们的编译器（分别为Ada和C）的关系非常差，因为产品的失败变成了芯片和软件之间的非常规游戏。

— 彼得·卡米利里
source

毫无疑问，是的。

特别地，C99所隐含的通信模型是共享内存。更高级的并发语言具有更丰富的通信模型，例如消息传递通道（如Rust）。

现代CPU架构确实对共享内存具有显式的硬件支持。特别是，像MESI这样的缓存一致性协议是在实际的门和线路中实现的。即使消息传递的想法与CPU无关，也没有对进程之间的消息传递的真正支持。现代的PCI-e总线甚至使用消息传递来模拟共享内存，而CPU进程必须使用共享存储器来模拟消息传递！

— 杂项
source