Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've seen a bunch of sites that benchmark new hardware on gaming performance, zipping some files, encoding a movie, or whatever. Are there any that test the impact of new hardware (like SSDs, new CPUs, RAM speeds, or whatever) on compile and link speeds, either linux or windows?

It'd be really good to find out what mattered the most for compile speed and be able to focus on that, instead of just extrapolating from other benchmarks.

share|improve this question

closed as not constructive by gnat, BЈовић, Jalayn, Yusubov, Robert Harvey Jun 4 '13 at 17:41

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
I think this belongs on SuperUser. –  Mahmoud Hossam Mar 19 '11 at 0:06
    
@Mahmoud Hossam: Sort of a mixed topic, compilation is an intensely programmer only activity, whilst hardware benchmarks are definitely a different territory. –  Orbling Mar 19 '11 at 0:13
    
@Orbling well, he's not asking whether he should compile X or Y, he's asking if people use compiling in general to do benchmarks. –  Mahmoud Hossam Mar 19 '11 at 8:53
    
@Mahmoud Hossam: Well it's an issue that only effects programmers. –  Orbling Mar 19 '11 at 11:24

3 Answers 3

I did that for a while - see here and here.

At the time, I was working on GTK+ and X11 hacks for a Linux cell phone distro, and every time I touched something on such a low level, it triggered rebuilding all kinds of things. One of my colleagues never did complete builds because, on the computer the company supplied with the standard compile options, it took five hours.

I had all kinds of crazy hardware sitting around at home, so I ran benchmarks on some machines while I coded on others, and you can see the results at the links.

For what we were doing on Ubuntu, once I maxed out CPU utilization - which you can do really easily with the -j argument to make - the bottleneck seemed to be the disk.

But then the company had big layoffs, so I was out the door, and didn't finish scoping that all out. I had a lot of data and interpretation I didn't post on that blog, too.

share|improve this answer
    
Shame to build it up with two detailed posts and them stop. Do you still have all that data? In any case, it would be very interesting to see some blog posts/answers with some conclusions of what you found. –  Hugo Jul 17 '11 at 8:16
    
@Hugo: No, I'm afraid not - the raw data is long gone. But basically what I came up with is that for the systems (1-8 CPU cores) and source code (the Linux kernel) I was testing, the fastest build times were when the -j option was at 1.5x the number of cores, with -j=2 being best for one core. Below that, the systems were CPU bound, and above that, they were I/O bound. It's an interesting question - maybe I should take it up again someday. –  Bob Murphy Jul 17 '11 at 21:08

First on my wishlist is a Solid State Drive. It won't have a huge impact on compile time, but opening applications becomes drastically faster (IDE, PhotoShop, ETC). http://joelonsoftware.com/items/2009/03/27.html

The biggest factor for compile time is going to be CPU. You're pretty safe using this for the benchmark http://www.cpubenchmark.net/.

share|improve this answer
1  
Then again a lot depends on your build chain. If your build chain only uses a single thread for compilation on a multi-CPU, a multi-core or even a multi-threaded CPU, you are wasting an opportunity for massive gains. A plain CPU benchmark wont show that, and a compilation benchmark would only be good for a given toolchain. –  asoundmove Mar 19 '11 at 2:03
2  
Actually, I found by experiment that once you do parallel compilation, it's your disk that's the bottleneck. Within reason, you're better off with a slower CPU and a faster disk than vice versa. –  Bob Murphy Jun 17 '11 at 1:18

Tom's Hardware used to, but it looks like they stopped doing it back in 2008: http://www.tomshardware.com/charts/desktop-cpu-charts-q3-2008/benchmarks,31.html. None of the newer CPU charts include the Linux Kernel compiling test.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.