beaucham@uxh.cso.uiuc.edu (11/23/89)
In developing new programs in C I find that the most time is taken in waiting for compile and link (including some fairly large libraries). ( I am working with a genuine 6 MHz AT.) Even if I go to V DISK, it is still slow. My question is -- What factors most strongly determine the speed of compile? If I upgrade to a 386 CPU using, for instance, the MicroWay FastCACHE-AT/SX board (which includes 32K cache), will I see a big improvement? Jim Beauchamp j-beauchamp@uiuc.edu
rob@prism.TMC.COM (11/25/89)
>In developing new programs in C I find that the most time is taken in waiting >for compile and link (including some fairly large libraries). ( I am working >with a genuine 6 MHz AT.) Even if I go to V DISK, it is still slow. My >question is -- What factors most strongly determine the speed of compile? A big factor is the speed of the compiler. Given the same program, different compilers can take very different amounts of time to digest it. Turbo C and Quick C are quite fast. Microsoft C takes 2 to 3 times as long to handle most programs. I've seen one compiler, which I won't name, that takes several times as long as Microsoft C. Depending on what you're working on, breaking programs down into smaller modules, so that you're recompiling smaller programs, may be an option. Assuming a reasonably fast disk, compiling is mostly a CPU bound job. Using VDISK, or a disk cache, will give you some improvement, but isn't likely to make a drastic difference except on very small programs. >If I upgrade to a 386 CPU using, for instance, the MicroWay FastCACHE-AT/SX >board (which includes 32K cache), will I see a big improvement? If you've got the budget, that'll do the job, and it'll make everything, not just your compiler, run several times faster.
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (11/26/89)
< BACK TO THE FUTURE PART III (coming May 1990): It's about time. > In article <19500044@uxh.cso.uiuc.edu>, beaucham@uxh.cso.uiuc.edu writes: > In developing new programs in C I find that the most time is taken in waiting > for compile and link (including some fairly large libraries). (I am working > with a genuine 6 MHz AT.) Even if I go to V DISK, it is still slow. My > question is -- What factors most strongly determine the speed of compile? It'd help if you mentioned if the time was being taken in the compilation proper (generation of the .OBJ's) or the link. Also, VDISK uses *extended* memory, which requires resetting the CPU; it's far slower than a RAM disk based on *expanded* memory. For the compilation itself, you want to put the header files on a RAM disk if you can. (Turbo C, which #includes tons of junk, is fast; Turbo Pascal, which picks up the same kind of information from pre-compiled, compact binary files, is *awesome*.) I once heard an estimate that twenty percent of a compiler's time was spent skipping blanks and comments; you could try taking them (carefully!) out of the standard header files. For the link, obviously, put the libraries (and maybe the final .EXE) on a RAM disk. Getting the .OBJ files in a RAM disk would save time in both compilation and linking, but I don't see it as a serious bottleneck. Someone mentioned buying the right compiler. Microsoft C has several passes, each of them a separate program that has to be run, with temporary files between each pass. Put both the programs and the temporary files on a RAM disk (see your manual for details). Turbo C does the whole compilation in one executable (except for linking with the command line version, which invokes the separate linker), and stores all inter-phase information in RAM (except for object files). > Jim Beauchamp j-beauchamp@uiuc.edu Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
larry@macom1.UUCP (Larry Taborek) (11/27/89)
From article <19500044@uxh.cso.uiuc.edu>, by beaucham@uxh.cso.uiuc.edu: > > In developing new programs in C I find that the most time is taken in waiting > for compile and link (including some fairly large libraries). ( I am working > with a genuine 6 MHz AT.) Even if I go to V DISK, it is still slow. My > question is -- What factors most strongly determine the speed of compile? > > If I upgrade to a 386 CPU using, for instance, the MicroWay FastCACHE-AT/SX > board (which includes 32K cache), will I see a big improvement? > Jim, I am using SCO XENIX 386 with a Mylex 25MZ motherboard with 64K of static ram and 4MB of memory and a fast disk and controller. My C compiles are lightening fast. On my Altos 586, a compile that use to take 1 minute to do the link, now occures in 2 seconds. If you want more info, send me email or call me at (703) 758-7000. Hope this helps... -- Larry Taborek ..!uunet!grebyn!macom1!larry Centel Federal Systems larry@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 My views do not reflect those of Centel 703-758-7000
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (11/30/89)
In article <19500044@uxh.cso.uiuc.edu> beaucham@uxh.cso.uiuc.edu writes:
$In developing new programs in C I find that the most time is taken in waiting
$for compile and link (including some fairly large libraries). ( I am working
$with a genuine 6 MHz AT.) Even if I go to V DISK, it is still slow. My
$question is -- What factors most strongly determine the speed of compile?
Well, I'm using a 12 MHz AT (1 ws) with a 25 ms hard drive and a 384K disk
cache, and using Turbo C 2.0 and TLINK 2.0, and I find things compile
and link pretty quickly. Actually, it seems that about 40-60% of the time
is spent reading in the header files!
Obviously, the speed of your processor, disk transfer rate and seek
time are pretty important factors ... what are you putting in your
VDISK ... the program, the libraries, everything used in the development
cycle? If you have the whole thing on a VDISK and it's still too slow,
the only major factor left is your clock speed. Probably the only benefit
I get from my disk cache is a) the .c file stays in the cache and b) it
performs batch reads from the disk ... I end up accessing much more than
384K of disk during an edit/compile/link cycle.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
They say the best in life is free // but if you don't pay then you don't eatakcs.larry@nstar.UUCP (Larry Snyder) (12/01/89)
Lines: 7 > Well, I'm using a 12 MHz AT (1 ws) with a 25 ms hard drive and a 384K disk >cache, and using Turbo C 2.0 and TLINK 2.0, and I find things compile >and link pretty quickly. Actually, it seems that about 40-60% of the time >is spent reading in the header files! I'm running SCO Xenix 2.3.3 on a 25mhz '386 with 4 megs of RAM and usually I load the header files into a RAM disk - which makes the compiles really