Re: what kind of computer for programmer ?

On Mon, 27 Jun 2005 11:47:54 -0500, Rob Thorpe wrote
(in article
<1119890874.761686.181400@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>):

> Randy Howard wrote:

>> No doubt. The problem is, projects small enough to fit easily
>> into most ramdisk setups compile so quickly that they aren't
>> needed. The really big projects, which do take a long time to
>> compile, and really need a speeding up, are too large to fit in
>> any but the really agressively sized ramdisks (think 64-bit
>> address spaces, or at least >32).
>
> A project would have to be very big indeed to fill a modern PC's
> memory.

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.

For something
>> As such, more RAM to avoid paging, parallel compiles (if your
>> system supports make -j and particularly with multiple
>> processors), and a very good storage subsystem are the better
>> general solution. This is precisely why ramdisks have gone from
>> being common to being rare over time.
>
> If you have an extremely large project to compile, then yes a very good
> storage subsystem is better. Parallel compiles are useful either way.

For really slow storage devices, parallel compiles can actually
slow things down from the excess seek overhead. Just as in
benchmarking anything else, it depends.

> (If you have a project that large I'd be tempted to go to distributed
> compiles, or a remote compile server with high-bandwidth disks and many
> processors)

You need to have compiles that take hours, not minutes to
justify that. Fact is, if you're using a ram disk to get
compile time down from 30 seconds to 10 seconds, you have to
wonder why it's worth it.

> But, this is never the problem. If you change something and a handful
> of files recompile, that's ok however you do it. The problem comes
> when many files need to be recompiled, or an entire rebuild is needed.

Either it is small enough that this rare rebuild-all event can
happen while you go get a drink of water (or eliminate same
naturally), or it's probably too big to fit in your ramdisk
anyway on modern hardware.

Once upon a time, large project builds (like the enter SVR4 tree
for a release build) would take almost a full day to complete on
contemporary hardware. But, it was far too large for a ramdisk
to make a difference on anyway. So, going to one of the very
early RAID hardware controllers took the build time down by over
8 hours. IOW, that expense paid for itself almost immediately.
No more taking turns sleeping on a couch in the lab waiting or
the console to start beeping.

Again, YMMV, but I would much rather add RAM to avoid paging,
improve the storage subsystem and maybe even go SMP before
fooling with a ramdisk for a payoff only on compiles. These
improvements make EVERYTHING go smoother on the system.




.

Relevant Pages

  • Re: what kind of computer for programmer ?
    ... >>> compiles) ... Same goes for hard drives. ... The file system buffer cache does almost as well ... overall a ramdisk was faster. ...
    (comp.programming)
  • Re: what kind of computer for programmer ?
    ... >> compiles) ... > Thats a nice idea, does anyone know of a trustable and free tool for ... Same goes for hard drives. ... With a ramdisk, you still have to copy everything into it, then ...
    (comp.programming)
  • Re: 1541 too slow on CPM
    ... because the code that gets generated is so huge, it won't fit into RAM. ... At that point I would become a bit more interested in "native mode", ...
    (comp.sys.cbm)