作为研究项目的一部分 已经开始向 GCC 添加一项功能，允许将编译过程划分为多个并行线程。 目前，为了提高多核系统上的构建速度，make 实用程序使用启动单独的编译器进程，每个编译器进程都会构建一个单独的代码文件。 新项目正在尝试在编译器级别提供并行化，这将有可能提高多核系统的性能。
用于测试 GCC 的一个单独的并行化分支，它提供了一个新参数“—param=num-threads=N”来设置线程数。 在初始阶段，我们将过程间优化转移到单独的线程中，每个函数循环调用这些线程，并且可以轻松并行化。 GIMPLE 操作负责独立于硬件的优化，评估函数之间的交互，这些操作被放置在单独的线程中。
下一阶段，考虑到硬件平台的特性，还计划将过程间 RTL 优化转移到单独的线程中。 之后，我们计划实现应用于函数内部代码的过程内优化 (IPA) 并行化，而不管调用的具体情况。 目前的限制环节是垃圾收集器，它添加了一个全局锁，在多线程模式下运行时禁用垃圾收集操作（将来垃圾收集器将适配GCC的多线程执行）。
为了评估性能变化，我们准备了一个测试套件来组装 gimple-match.c 文件，其中包括超过 100 万行代码和 1700 个函数。 在具有 5 个物理核心和 8250 个虚拟核心（超线程）的 Intel Core i4-8U CPU 的系统上进行的测试表明，程序内 GIMPLE 优化的执行时间从运行 7 个线程时的 4 秒减少到 2 秒，运行 3 个线程时减少到 4 秒。线程，即所考虑的组装阶段的速度分别提高了 1.72 倍和 2.52 倍。 测试还表明，使用具有超线程的虚拟核心不会提高性能。
总体构建时间减少了大约 10%，但根据预测，并行 RTL 优化将实现更切实的结果，因为此阶段在编译过程中需要花费更多时间。 大约在RTL并行化之后，总汇编时间将减少1.61倍。 此后，通过并行 IPA 优化，可以将构建时间再减少 5-10%。
来源： opennet.ru