我正在考虑带NVPTX卸载的GCC（特别是在Windows/MinGW-w 64上），我想知道GCC本身是否可以利用这一点，所以它有更多的处理能力来做更快的编译/链接？或者这个问题没有什么意义，因为这些过程在本质上不够数学化？还有一个事实是，GCC有一些本质上是数学的依赖关系（mpfr，gmp，mpc，isl），所以也许他们可以利用卸载的优势，使GCC更快地使用GPU？
ttisahbt1#
“可以......？”：不，这不可能;否则它会在手册中：-）“可以......？"：大概不会;编译主要是遍历数据结构，而不是执行并行算术运算，并且除非在非常高的级别上，否则显然不是并行的。一次编译需要前一次编译创建的状态，因此存在严格的排序，并且您不能轻易地并行执行多次编译。（每次编译更新代码的单个表示）。当前的方法是使用make -j8或类似的方法来同时编译多个文件，但即使这样，也不太可能有足够的并行性来保持GPU的忙碌。
make -j8
bq3bfh9z2#
它能使用它吗？是的。它应该吗？可能不能，但不是因为许多人陈述的原因。大多数工具链都被陈旧过时的技术、数据结构和算法所困，这些都是由非常陈旧的计算机所设计的。与许多声称编译和链接不可并行化的人相反，它们是可并行化的。通常，链接实际上是过程中最慢的部分。链接和编译基本上没有在“作业服务器”实现之外实现并行化，这主要有两个原因。第一，直到最近，大多数计算机都没有足够的内存或CPU线程来使这种技术有价值，任何有足够资金购买足够GPU来执行这种任务的人都可以通过购买多个CPU和进行分布式编译来获得更好的投资回报。其次，虽然优化和其他技术（如链接时优化（也在链接时进行编译和代码生成））方面的新发明改善了编译器和链接器的输出，但大多数工具都是基于非常旧的想法和代码设计的，并携带了大量的粗制滥造和负担，由于不规则的代码库而阻碍了进步。无论如何，使用GPU可能仍然是不值得的。较新的工具，如模具链接器，在CPU上创造指数级的速度。模具已经“重新实现”尽可能多的基本链接任务，以利用现代的并行能力和高内存可用性。它还不支持LTO，但它实现了近似文件复制（最大I/O带宽）速度。使用implemental/cached build，Clang和Chrome可以在32核线程抓取器处理器上在不到一秒的时间内链接，相比之下，在相同的处理器上，GNU的gold linker大约需要60秒，而lld需要10秒。如果您愿意，可以在此处了解有关霉菌的更多信息：https://github.com/rui314/mold
2条答案
按热度按时间ttisahbt1#
“可以......？”：不，这不可能;否则它会在手册中：-）
“可以......？"：大概不会;编译主要是遍历数据结构，而不是执行并行算术运算，并且除非在非常高的级别上，否则显然不是并行的。一次编译需要前一次编译创建的状态，因此存在严格的排序，并且您不能轻易地并行执行多次编译。（每次编译更新代码的单个表示）。
当前的方法是使用
make -j8或类似的方法来同时编译多个文件，但即使这样，也不太可能有足够的并行性来保持GPU的忙碌。bq3bfh9z2#
它能使用它吗？是的。它应该吗？可能不能，但不是因为许多人陈述的原因。
大多数工具链都被陈旧过时的技术、数据结构和算法所困，这些都是由非常陈旧的计算机所设计的。
与许多声称编译和链接不可并行化的人相反，它们是可并行化的。通常，链接实际上是过程中最慢的部分。链接和编译基本上没有在“作业服务器”实现之外实现并行化，这主要有两个原因。
第一，直到最近，大多数计算机都没有足够的内存或CPU线程来使这种技术有价值，任何有足够资金购买足够GPU来执行这种任务的人都可以通过购买多个CPU和进行分布式编译来获得更好的投资回报。
其次，虽然优化和其他技术（如链接时优化（也在链接时进行编译和代码生成））方面的新发明改善了编译器和链接器的输出，但大多数工具都是基于非常旧的想法和代码设计的，并携带了大量的粗制滥造和负担，由于不规则的代码库而阻碍了进步。
无论如何，使用GPU可能仍然是不值得的。较新的工具，如模具链接器，在CPU上创造指数级的速度。模具已经“重新实现”尽可能多的基本链接任务，以利用现代的并行能力和高内存可用性。它还不支持LTO，但它实现了近似文件复制（最大I/O带宽）速度。使用implemental/cached build，Clang和Chrome可以在32核线程抓取器处理器上在不到一秒的时间内链接，相比之下，在相同的处理器上，GNU的gold linker大约需要60秒，而lld需要10秒。
如果您愿意，可以在此处了解有关霉菌的更多信息：https://github.com/rui314/mold