C++ 编译器能否优化非相关命令以使用不同的内核执行？

编译器可以根据优化更改非相关命令的顺序。 它是否也可以无声地优化它们以在不同的内核中执行

例如：

...
for (...) 
{
    //...
    int a = a1+a2;
    int b = b1+b2;
    int c = c1+c2;
    int d = d1+d2;
    //...
}
...

在优化方面，可能不仅会改变执行顺序，还会改变内核数量吗？编译器在标准中有任何限制吗

---

UPD：我不是问如何并行化代码，我是问如果代码没有显式并行化，编译器还能并行化吗？

是的，编译器可以按任何顺序做事情（包括根本不做），只要生成的可观察行为与代码的可观察行为相匹配。汇编指令、运行时、线程计数等都是不可观察的行为

---

我应该补充一点，如果没有程序员的明确指示，编译器不太可能决定这样做；尽管标准允许，编译器的存在是为了帮助程序员，随机启动额外的线程在很多情况下是出乎意料的。最有可能的是，指令（在您的示例中）最终将并行运行，但这不是您所想的

CPU中有许多级别的硬件并行性，多个核只是最高的一个（1）。在一个CPU内核中，你有其他层次的硬件并行化，它们大部分是透明的（你不通过软件控制它们，你也看不到它们，只是有时可能会有副作用）。管道、额外的总线通道、每个核心的多个ALU（算术逻辑单元）和FPU（浮点单元）就是其中的一些

指令的不同阶段将在流水线中并行运行（现代x86处理器有十几个流水线阶段），可能不同的指令将在不同的ALU中并行运行（现代x86 CPU每个核心大约有5个ALU）

所有这些都是在编译器不做任何事情的情况下发生的（2）。而且它是免费的（考虑到硬件，在硬件中添加这些功能不是免费的）。在不同的内核中执行指令不是免费的。创建不同的线程成本很高。将数据移动到其他核心是昂贵的。等待其他内核执行的同步代价高昂。创建和同步线程会带来大量开销。对于像这样的小指令来说，这是不值得的。而多线程真正有好处的案例将涉及到一种分析，这种分析在今天过于复杂，因此实际上是不可行的。将来的某一天，编译器将能够识别串行算法实际上是一种排序，并高效、正确地对其进行并行化。在此之前，我们必须依赖语言支持、库支持和/或开发人员对并行化算法的支持

1） 事实上，超线程是

2） 正如MSalters所指出的：

现代编译器非常了解各种ALU，并且会这样做 努力从中受益。特别是，注册分配是 优化了，这样你就不会让ALU竞争同一个寄存器， 抽象事物从抽象事物中看不明显的事物 模型

---

所有这些都会间接影响执行，从而有利于硬件体系结构，没有明确的指令或声明。

Google about threads。但是编译器不能在另一个内核上运行另一个线程，操作系统会选择哪个线程在哪个内核上运行。@mch线程是显式并行化的好方法，但是如果不这样做，有人能保证命令将在一个内核内执行吗？或者如果编译器可以改变顺序，它是否强制执行是并行的？编译器可能（并且在实践中也经常这样做）发出在一个核心上并行执行这些操作的代码，这是你的问题似乎没有考虑的可能性。all@Arkady如果在同一个周期内发生多件事情，那就是parallelism@Arkady请参阅-例如，在8对浮点上执行8个加法的单个指令谢谢！这是已知的编译器可能性，但在可观察到的行为情况下，它是否也可以强制在2个内核上执行此类指令？@Arkady“force”否，因为运行时环境可能没有多个内核，例如，在只有一个核心的虚拟操作系统上assigned@Caleth当然，我的问题是正确的，只要环境有多个核。）老实说，现代编译器非常了解各种ALU，并将努力从中受益。特别是，寄存器分配是经过优化的，这样你就不会让ALU竞争同一个寄存器，这在抽象顺序模型中可能并不明显。编译器不能生成代码来使用GPU进行并行计算吗，比如说，如果计算是在数组元素上执行的？今天，人们可能需要一个不同的工具链（CUDA、OpenMP）来实现这一点，但对于编译器本身来说，没有任何逻辑障碍，我认为。@PeterA.Schneider不是真的没有。GPU编程的一个重要部分（如果你想要任何类型的实际性能）是对齐和洗牌数据，顺序模型中没有出现的东西。@PeterA.Schneider如果编译器足够聪明，可以在GPU上自动执行，那么下一个问题就是编译器不能生成代码来上传云计算算法吗？@PeterA.Schneider，然后，如果编译器足够聪明，能够从一个顺序编写的算法中完成这一切，那么下一个问题就是我们需要程序员做什么？在这一点上，编译器基本上是一种能够理解算法的高级人工智能。