What are you compiling and what program are you using?
I'd say get 3930K.12 threads @ 3.2Ghz and unlocked. You can probably push it close to 4Ghz on air and it should cut your compile time a lot. The downside is the price, ~550USD+whatever the board is.
Actually the FX CPUs are likely bad value in this context. It's about saving time by using the highest-end hardware available, time which is worth several thousand dollars over an assumed 3-year lifecycle for the machine. A $400 difference for CPU+MB is insignificant here. If you save $400 dollars on initial investment, but loose time worth $600 over the next three years, you actually take a loss of $200. Welcome to the wonderful world of economic analysis.The FX 8120 and 8150 are great value (better price/performance than SB in heavily multi-threaded tasks). AMD recently reduced the prices even more. You can get a 8120 for around 150 USD now.
Ignore people suggesting the Opterons. You need strong single threaded performance for compilation- if you have a dependency chain in your build and wind up waiting on one or two especially large CPP files to finish compiling before the build system can start building the next bit, then it doesn't matter how many threads you have sitting spare. (I speak from experience here- it's frustrating as hell when my 12 core workstation has 22 threads sat idle, while 2 cores are maxed out for minutes at a time.)
Agreed. The Sandy Bridge E chips have quad channel memory too, which will help with feeding your cores. You can get more cores with the Xeon chips (up to 16 cores/32 threads in a dual socket workstation), but you'll get lower clock speeds and since you can only parallelise 10-wide those threads won't make a bit of difference. Overclocked 6 core and fast quad-channel RAM is the way to go.
The other piece of the puzzle is disk access- you might want to move to an SSD (or at the very least a high performance hard drive).
Thanks. Does extra memory bandwidth help compile? I thought the object files were small enough to fit in cache. Also already on SSD.
Absolutely true. Which is why I can't get good parallelization more than approx 6 threads depending on the stage of compilation. Also the linking stage (which is very long) is single threaded.
I'd say get 3930K.12 threads @ 3.2Ghz and unlocked. You can probably push it close to 4Ghz on air and it should cut your compile time a lot. The downside is the price, ~550USD+whatever the board is.
When you compile, are you only running one job at a time or do you load up your computer with more than one compile job (multitask the compiling efforts of many jobs?).
The parallelization within a given job may not be all that stellar, but you can parallelize the workload itself by loading up multiple independent jobs in parallel. If this is the case for you then going with a sea-of-cores will likely be better for you in the end.
If you are only working on one project at a time then this approach doesn't help you, naturally, and you are better off going with a CPU that has great single-threaded performance and really aggressive turbo-clocking to minimize the time spent processing serial portions of the job.
(I'm assuming you aren't overclocking since you mentioned your time is worth money and it would be rather foolish to OC your CPU by 20% with the risk of trashing all the output and having to double your time spent on the job to get it right the second time through)
Actually my entire project has only something like 20 files to compile, however some files generates temporary files which need a second pass for compile, but it takes around 30 secs to compile the entire project. I literally do hundreds of compiles a day, so if I reduce this compile time by 50%, it really adds up in terms of time value money.
And no, I will not (and currently do not) OC. I only buy Intel Mobos too, yes they cost $20 more, but I also rather not spend extra time googling around how to get XXX hardware working together with YYY hardware. I pay that extra $20 and believe Intel did that extra grunt work for hardware validation.
You don't mention what OS your tool chain is on?
If you're on Windows, double check that your build directories are excluded from your anti-virus scanning - when I was working on firmware at Intel, adding our build directory to the AV exclusion list gained us about 20-30% performance boost.
My other suggestion is to use performance monitoring tools to characterize what are your current bottlenecks - compile toolchains can have different bottlenecks depending on the tools you're using, and how the compiler is written. Check your memory, disk IO, and CPU utilization.
In my current job, we have a mix of tools that run on each build. Some, like the compiler seem to be constrained either CPU, or disk IO (largely based on how many dependencies a particular object has). Others, like our static analysis tools are primarily constrained by CPU.
Also check how many concurrent builds your toolchain allows - some build tools (gmake, etc) allow you to specify a flag to concurrently build things (though
this can cause issues if your dependencies aren't good). It's always nice to get a free boost if you can turn on concurrent builds
Good luck!