delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/03/29/05:28:03

To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: DJGPP Speed
Date: Tue, 29 Mar 94 11:52:25 +0200
From: eliz AT is DOT elta DOT co DOT il

  This summarizes some testing I did for the DJ GCC 1.11maint4 as far as
the compilation speed goes.

  All the tests were done when compiling the source of Makeinfo program.  It
resides on a single 7500-line long file, so that the overhead of loading the
different compiler passes could be safely ignored (I think).  The compilation
command was:

  gcc -c -I. -I../libtxi -DREMOVE_OUTPUT_EXTENSIONS -O2 -o makeinfo.o makeinfo.c

(this is taken from the makefile.djg as distributed in Texinfo source Zipfile).

  This command causes GCC to compile and assemble about 9000 lines of C code,
including about 1500 lines in the header files (I counted them following the
suggestion of Bob Babcock, peprbv AT cfa0 DOT harvard DOT edu, for which thanks).  The ld
phase is *not included*. 

  This was run on 3 machines:

  1) 486DX2-66 with 16MBytes of RAM, ISA bus and SCSI disk connected to
     AHA-1542F controller, under MS-DOS 6.2;
  2) 486DX-33 with 8MBytes of RAM, ISA bus and 12-ms IDE disk connected to
     JC2000 VESA Local bus controller working in Turbo mode, under MS-DOS 5.0;
  3) 40MHz Sun Sparc2 with 32MBytes of RAM.

  Both PCs were configured with QEMM 7.03, QDPMI 1.02, RAM drive of 1.5MByte
(via RAMDRIVE.SYS) and 2MByte SMARTDrive disk cache.  The TMPDIR variable for
GCC pointed to the RAM disk.  The GO32 variable said ``nodpmi''.

  Results (compilation speed in lines per second):

     DX2-66        DX-33        Sparc2
    ------------------------------------
     260           180           220

  Additional testing showed that:

  a) When TMPDIR points to a real drive, the compilation is about 10% slower.
  b) The above numbers do not change if the ``nodpmi'' is removed from GO32.

  Conclusion 1: DX2-66 indeed *is* (a bit) faster than Sparc2, and not only for
                Dhrystones.
  Conclusion 2: With a fairly good disk cache, the I/O is probably NOT the
                decisive factor (at least for the above-mentioned machines).
                This is also supported by looking at the flashing of that LED
                marked with "Hard Disk Access": for the above set-up it
                flickered for about 5-7 seconds overall time.  Suppose our I/O
                is lightning-fast (uses 0 time) -- how much would we gain?
  Conclusion 3: GCC is *much* slower than TCC: that little thingy did the whole
                work in about 5 seconds on the DX-33 (of course, I had to tinker
                a little bit with the includes, some of which TCC doesn't have).

	Eli Zaretskii

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019