有人在编译代码方面做过硬件基准测试吗？[关闭]

21

我见过很多网站，它们对游戏性能上的新硬件进行了基准测试，压缩了一些文件，对电影进行了编码等等。是否有任何测试可以测试新硬件（例如SSD，新CPU，RAM速度等）对编译或链接速度（Linux或Windows）的影响？

找出最重要的编译速度并能够专注于该速度，而不是仅仅从其他基准进行推断，将是非常好的。

benchmarking 
— 科伦
source
我认为这属于SuperUser。
— Mahmoud Hossam
2
@Mahmoud Hossam：有点复杂，编译只是程序员的一项活动，而硬件基准肯定是不同的领域。
— 2011年
@Orbling好，他不是在问他应该编译X还是Y，而是在问人们是否一般使用编译来做基准。
— Mahmoud Hossam
1
— Kokizzu
1
这里有一个基于Linux内核编译时间的CPU基准测试：openbenchmarking.org/showdown/pts/build-linux-kernel
— sjakobi

Answers:

4

我做了一段时间- 在这里和这里看到。

当时，我正在为Linux手机发行版开发GTK +和X11骇客，每次我接触到如此低的级别时，都会触发各种东西的重建。我的一位同事从未完成过完整的构建，因为在公司提供的标准编译选项的计算机上花了五个小时。

我在家里有各种各样疯狂的硬件，因此我在某些机器上运行基准测试，而在其他机器上进行编码，则可以在链接上查看结果。

对于我们在Ubuntu上所做的事情，一旦我最大限度地利用了CPU利用率-使用-j参数可以很容易地做到这一点-瓶颈似乎就是磁盘。

但是后来公司裁员了很多，所以我出门了，还没有完成所有的任务。我也没有在该博客上发布过很多数据和解释。

— 鲍勃·墨菲
source
羞耻地用两个详细的帖子来构建它，然后他们停了下来。您还有所有数据吗？无论如何，看到一些博客文章/答案以及所发现内容的一些结论将非常有趣。
— 雨果
@Hugo：不，恐怕不是-原始数据早已不复存在。但是基本上我想到的是，对于我正在测试的系统（1-8个CPU内核）和源代码（Linux内核），最快的构建时间是-j选项的内核数量是1.5倍， -j = 2最适合一个内核。在此之下，系统受CPU限制，在其之上，受I / O限制。这是一个有趣的问题-也许有一天我应该再讨论一下。
— 鲍勃·墨菲
0

首先在我的愿望清单上是固态硬盘。它不会对编译时间产生重大影响，但是打开应用程序的速度大大加快（IDE，PhotoShop，ETC）。http://joelonsoftware.com/items/2009/03/27.html

编译时间的最大因素将是CPU。使用它作为基准http://www.cpubenchmark.net/是非常安全的。

— 埃文
source
1
然后，这很大程度上取决于您的构建链。如果您的构建链仅使用一个线程在多CPU，多核甚至多线程CPU上进行编译，那么您就是在浪费大量的机会。普通的CPU基准测试不会表明这一点，而编译基准测试只会对给定的工具链有用。
— 2011年
2
实际上，我通过实验发现，一旦执行并行编译，就是磁盘成为瓶颈。在一定程度上，与相反的情况相比，使用速度较慢的CPU和更快的磁盘更好。
— 鲍勃·墨菲
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.