Hi,
what should I be looking to upgrade in my computer to be able to compile faster?
thanks,
reno
Hi,
what should I be looking to upgrade in my computer to be able to compile faster?
thanks,
reno
The CPU would probably make the biggest difference, followed by the hard drive (either a faster one or using RAID 0 or 5...), and if you're short on RAM, getting more RAM would obviously help.
Then again, if you're using a crappy compiler, then switching to a better one might speed it up too.
Using task manager, what %CPU are you using when you compile at the moment?
If say it's at 20% (so you get a CPU twice as quick), your CPU time will likely go down to 10% and you might see a small improvement in overall compile times.
The initial stages of compilation are heavy on file I/O (what with all those #includes containing #includes etc).
So if the hard disk is making lots of noise (and low %CPU) with all the file accesses going on, then look at that as a place to start. For example, check your drivers to see if there are specific ones for your hardware (and not the default "maximum compatibility" ones from MS).
How well written is the code?
Here are some bad things which will slow down compilation.
1. #include "file.c"
If your large program is completed by including all source code in main.c, then you need to figure out how to use projects.
2. #include <everything.h>
If you include lots of headers because you're too lazy to figure out which headers you really need, then that will slow things down as well.
3. #include <unnecessary.h>
If you're including lots of files in a module, just for the sake of one small bit of functionality, then consider removing that functionality to somewhere else in the system.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Experience with Gentoo (a Linux distribution that compiles every package from source) shows the following:
1) Disk I/O is rarely the bottleneck. There are people who do their entire compiling on a RAM disk, but the improvements limit themselves to very specific packages.
2) RAM is almost never the bottleneck. There are some offenders among C++ programs that need an absurd amount of RAM (don't attempt to compile OpenOffice unless you have at least a gigabyte), but unless you have wild template adventures, it's highly unlikely the compiler will ever consume more than 300 megabytes. However, if you have parallel compilations, this can add up, so a dedicated multi-core 32-bit compilation machine should be maxed out with 4 gigs anyway.
3) CPU is always the bottleneck. Note that compilation of a single source file cannot be parallelized, so multi-cores don't help for those cases. However, compilation of different sources can be excellently parallelized, leading to nearly linear scale-up in general. For a machine dedicated to compilation, get a quad-core CPU.
To formulate it differently: I have two computers. My desktop system is an Athlon64 2000GHz running 64-bit Linux with 1GB RAM. My laptop is a Core Duo 2200GHz running 32-bit Linux with 1 GB RAM. Hard disk throughput is about the same on both.
The laptop is, using wall time measure of large projects, more than twice as fast at compiling. The scale-up due to the CPU is indeeed about linear.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
thanks everyone!
really informative and appreciated
I'm looking forward to consult these boards
If you're doing a lot of compiling, you could network a few computers together and use a distributed compiler like icecc. I've never tried it, but it should be significantly faster.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
Oh yeah, I'm good at overclocking
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
CornedBeef runs LN2 24/7.
Sent from my iPadŽ
Yeah, i hate the whole AMD equivelancy marketing numbers they use.
In AMD's defence, I must say that Intel's P4 really didn't do very much for all those GHz that it used - which is the whole idea originally behind those numbers. At the time, AMD's top offerings running at 1300MHz would quite easily beat the Intel 1500-1600MHz variants.
Of course, right now the shoe is on the other foot - the Core2 processors run faster for the same clock-speed compared to AMD's current products.
At one time I explained to someone that measuring GHz is like comparing the red-line of the rev-counter of different engines. In that "race" a Honda CBR250 would win over just about anything [including todays top-end 800cc MotoGP bikes], as it red-lines at 18500 RPM. The fact is that this engine is a 250 four-cylinder four-stroke engine, so it has about 45 bhp, compared to the latest 800cc MotoGP bikes that put out 4-5x that amount. And of course, it's pretty easy to find a regular car engine that outputs well over 100 bhp at much lower rpm.
Unfortunately, it's not quite so obvious to understand when it comes to the marketing BS that various computer manufacturers produce(d) regarding the comparative performance of different machines. A large proportion of computer buyers do not understand the difference in "work per clock cycle" on architecture A or architecture B, so do not understand why they should be paying more for a "slower" processor.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.