Re: what kind of computer for programmer ?

Randy Howard wrote:
> On Mon, 27 Jun 2005 13:27:50 -0500, Rob Thorpe wrote
> > It's worth mentioning that the main reason most peoples compiles are
> > slow is because they haven't thought about building.
>
> Or, they simply are doing it on old hardware. A "fast" PC is
> now around $500. A "smoking fast" PC is around $1000. If your
> time is worth anything at all, either of those pays for itself
> VERY quickly if you spend a lot of time in front of a compiler.
>
> If you have a super-sized project that really takes a long time
> to build, bump that up to around $2000 and you can literally
> make the problem go away.
>
> > To make them fast:-
> >
> > * Find the fastest compiler switches you can use. It's normal to have
> > debug and release build, but you can have a third one, say "fast".
>
> If you think you need a special "fast build", then you probably
> have bigger problems.
>
> > * Clean out spurious dependencies, a useful thing to do anyway
>
> True.
>
> > In C or C++
> > * Split up "kitchen-sink" include files, again useful anyway
>
> Even the big header files, like those in class libraries compile
> almost instantly on modern hardware. The days of leisurely
> watching the compiler progress one message at a time are long
> gone. (I have heard rumors that .NET compiles can seem that
> way, but I haven't tried it since C# was in beta).
>
> > * Use caching pre-compiled headers if available
>
> and hope it doesn't cause more problems than its worth.
>
> > * Use --pipe if you're using gcc
>
> Yes.
>
> > * If you're really keen use compilercache
>
> Which is mostly smoke and mirrors, as a machine with a lot of
> ram and a decent file system does much of this automatically.
> Again, any benefit you do receive is only for compiler, not for
> your overall system.
>
> > ... AND get fast hardware.
>
> This should have been step 1, then most (or all) of the above
> would not have even been necessary for 95% or more of the
> projects out there.

Much of this is a matter of taste, it's down to how individuals and
team prefer to work. Many prefer to work from hard-drives, in fact I
do most of the time. Also, some people don't mind small compiles of a
few thousand lines of code taking 10 seconds or so, others try to make
everything instantaneous. But I think everyone can agree that it's
useful for very large projects, hundreds of Kloc or millions to compile
quickly. Most of what I've said in earlier posts was on that topic.

The question of how fast the build stuff is is also a matter of
personal taste. For most of my projects it's completely unoptimized,
and will stay that way. But if the amount of source is large, and will
get larger then spending a few hours looking at the build stuff is
useful.

This issue of speed, the speed of truely large builds, is really
separate from personal taste. I think we both agree that buying some
fast hardware is one of the first things to do to speed up a large
project's build. Also, if you have projects like this then it's useful
to use ram-disks.

In another post you said:

> No modern PC has a ramdisk = sizeof(installed RAM). Lots of
> projects, including source, intermediate files, object files and
> linked executables are larger than a typical ramdisk setup.
>
> A relative simple suite of command line applications all written
> in straight, portable C, with no GUI, bitmaps, icons, etc. I
> have handy here has a build tree over 100MB in size.

Firstly, your "simple suite of command line application" can't be that
simple if it has a build tree over 100MB in size. Let's assume that
build files take up 5 times the size of source. Under this assumption
your project would be about 500000 lines long. (I'm sure I'm not right
about that, I'll give it a confidence interval of +/-200%.)

Anyway, even 500MB is not an unreasonable size for a ram-disk if you
have 2GB of RAM (which is not an unreasonable amount of RAM). For
projects like this I expect a ram-disk would often be faster than a
hard-disk, even a striped raid array.

Ram-disks only really pay-off for compiles. Making the system faster
for other reasons is another issue. (For instance the Xeon machine I
mentioned earlier is fast for the purposes of 3D CAD.)

.

Relevant Pages

  • Re: Another Anders H. interview
    ... "Nick Hodges [TeamB]" wrote ... but in fairness neither generality is worth much other than as a ... since no one compiles 'average' code--only what they ...
    (borland.public.delphi.non-technical)
  • Re: Code or library or compiler bug?
    ... P. Steinbach) wrote, ... >I had the impression that this should work fine, ... For what it's worth, compiles without error using Digital ...
    (comp.lang.cpp)
  • Re: Code or library or compiler bug?
    ... >>I had the impression that this should work fine, ... For what it's worth, compiles without error using Digital ... I am compiling it on Digital UNIX. ...
    (comp.lang.cpp)
  • Re: Mac mini OK for development?
    ... but I'm having a hard time seeing this with Activity Monitor. ... more RAM would be efficiently used during compiles. ... Not unuseable, just sluggish. ...
    (comp.sys.mac.programmer.help)
  • Re: How good are F50 and H50
    ... It has like 1 gb of ram which is all fine. ... compiles. ... In this relation I was offered a F50 with two cpu's or perhaps a H50. ...
    (comp.unix.aix)