Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!gatech!udel!princeton!njin!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.microport Subject: compilation speed with enough memory Message-ID:Date: 13 Jul 88 15:23:03 GMT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 65 I made a comment in a previous posting that compilation and loading on SV/AT seem incredibly slow. I now believe that much of that was due to insufficient memory. At the time I wrote my posting, I had 1.6M of memory (640K plus 1M). I just added another 512K, to make 640K+1.5M. This seems to have gotten rid of most of the extraneous swapping during compilation and loading. (As far as I can tell, by the way, this swapping is not caused by insufficient memory, but is done to shuffle memory in order to satisfy sbrk requests. One would think it would be possible to avoid this, but having not looked at the kernel, it's hard to be sure. Certainly you can prevent most of it in your own large-model programs by using my malloc, which tries to minimize the number of sbrk calls.) Anyway, with the extra 512K of memory, things don't seem so slow. Here are some speed comparisons: doing a full build of micrognu, I compared SV/AT with a diskless Sun 2/50. This is a 68010 machine doing all file I/O across the Ethernet from an Eagle. If you believe Intel, a 286 (in my case, running at 10MHz) should be at least the equivalent of a 68010, though we were always inclined to be sceptical. Anyway, SV/AT takes about twice as long to build mg, both with and without optmization. I was particularly disturbed by the speed of ld before, so I timed it separately. It is also slower by the same factor of 2. Obviously some of the differences here are due to the fact that the Sun has access to a faster disk. (Mine is a 60msec access time disk.) However CPU times also differ by about a factor of two, so that isn't all. Since I always thought the 68010 was significantly faster than the 286 (except for Intel benchmarks), these comparisons didn't surprise me. To get a better idea of how SV/AT itself is doing, I tried a comparison with MS/DOS on the same machine. I compared times to build a modified version of the rolodex program on SV/AT and MS/DOS, using MSC version 4.0. I'm not sure I believe the CPU times I get from MS/DOS, so I'm just going to report real times. Under SV/AT I had nothing else going on, so these should be comparable. -O not -O msdos 4m7sec 3m38sec sv/at 7m21sec 4m41sec (Actually on MS/DOS -O was -Os, and not -O was -Od. MSC defaults to -O, so you have to disable it explicitly.) The SV/AT optimizer is much slower than MSC's. Without optimization, I'd bet the difference is almost entirely due to the fact that SV/AT uses the traditional C compiler organization into many phases: preprocessor, compiler, optimizer, and assembler. Pyramid found that they could speed things up a lot by generating .o files directly, rather than calling as. Printf isn't all that fast, and of course as has to parse your file again, recreating the symbol table. Presumably MSC does something like this, since it certainly doesn't require the assembler to be present. Loading was actually slightly faster on SV/AT than MS/DOS (21 sec vs 28). So it seems that going from 1.5M to 2M of memory makes a significant difference for compilation. I'd say that I no longer consider the loader to be particularly slow. I do still think that cc is no speed daemon, but aside from the optimizer, it's probably doing about as well as you can do with a straight-forward Portable C Compiler type organization. The new generation of fast MS/DOS compilers are likely to run rings around it. That's because they are carefully tuned for fast compilation, which as far as I can tell was not a serious goal for PCC. Looking at CPU time and real time figures, and also noting that I don't hear the rather distinctive sound that my disk makes when swapping, I don't think more memory would be likely to speed things up much more, but it's always possible.