Very Computer

compiling large programs takes a long time when I use gcc. Mozilla took
6 hours!  What would be the best way to speed it up?  I am thinking I
would have improve the following most important listed first:

1. Fast hard drive.

2. More memory.

3  Fast CPU.

I currently have a 750 mgz amd cpu, an ata 100 ide hard drive and 64
megs or ram.

Something is screwed up.  I have a 500 PIII, 128M ram, and 10krpm ultra2
scsi drives and it didn't take 20 minutes.

But this is one of the cases where 64 MB more memory could make a lot of a
difference... If you have enough memory most of the header files etc. will
stay cached in memory and no disk accesses are necessary (and beside, you
seem to have a faster disk also). If this really explains the difference
between 6 hours and 20 min I don't dare to claim to know.
But a question to the original poster: Did you, by any chance do a make
with a -j option? Having too many processes running, all possibly waiting
for disk I/O can really slow down the machine as I had to learn the hard
way ;-)
                                            HTH, Jens
--
      _  _____  _____

  _  | |  | |    | |          AG Moebius, Institut fuer Molekuelphysik
 | |_| |  | |    | |          Fachbereich Physik, Freie Universitaet Berlin
  \___/ens|_|homs|_|oerring   Tel: ++49 (0)30 838 - 53394 / FAX: - 56046

Quote:>compiling large programs takes a long time when I use gcc. Mozilla took
>6 hours!  What would be the best way to speed it up?  I am thinking I
>would have improve the following most important listed first:

>1. Fast hard drive.

>2. More memory.

>3  Fast CPU.

>I currently have a 750 mgz amd cpu, an ata 100 ide hard drive and 64
>megs or ram.

For 64M RAM I'd definitely at least double that first. Even before
getting a faster disk. This _especially_ if you're running X with
some memory-hungry desktop on the machine.

Then, check that the IDE drive "optimizations" are turned on as much
as possible/safe on your hardware. Things like actually using the DMA,
running in the proper UDMA-mode, 32-bit transfers to/from the adapter,
possibly even enabling the on-drive write caching.

This is OS-dependent; you don't mention what Unix you're running, so
I don't have the details. On Linux "hdparm" is the command to use to
tune IDE disks; on my system the following is reported:
-----

/dev/hda:
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  1 (on)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 1247/255/63, sectors = 20044080, start = 0

 Model=QUANTUM FIREBALL EL10.2A, FwRev=A08.1100, SerialNo=341834534130
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
 BuffType=DualPortCache, BuffSize=418kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=20044080
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
-----
... which gives at least somewhat decent performance:
-----

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.14 seconds =112.28 MB/sec
 Timing buffered disk reads:  64 MB in  5.68 seconds = 11.27 MB/sec
-----
The machine is a PII-400MHz, with the disk being UDMA-66-capable, IIRC;
with your machine you should see a bit better results after tuning.
Before tuning I'd claim your figures (the disk reads at least) should
be below this. Note though that plain UDMA-100-interface isn't the key
to speed; also disk rotational speed and seek time play a part.

You probably don't need faster/more of anything since your computer is
already sufficiently pimped up to compile mozilla.  The problem most
likely is that you're not using all of those resources efficiently.  At
work we just switched to something called dmake (distributed make) to
compile our product "more parallely" so to speak.  Basically you're
looking at a multi-threaded make.  I bet compiling takes only a few
minutes while linking takes up your other 5.+ hours - linking is not very
CPU-intensive!   Why not use that idle time efficiently?

Just type "dmake" in google and look for an entry appropriate to your OS.

Ryan.