hedrick@athos.rutgers.edu (Charles Hedrick) (07/13/88)
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.hsu@santra.HUT.FI (Heikki Suonsivu) (07/16/88)
In article <Jul.13.11.23.02.1988.1755@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: > >swapping, I don't think more memory would be likely to speed things up >much more, but it's always possible. It would, if you have buffers enough to hold c compiler passes and install small ramdisk as /tmp. I picked up ramdisk posted here some time ago, installed it on my 386 uport and got some speedup, specially on big modules which produce long assembler files. Compilation went from 17 minutes to 13. I have 1400 kb buffers and 1 M ramdisk, probably I could still optimize. I have 8 M of ram and 28ms drive. 386 probably makes things a bit different.
mp1@sdcc12.ucsd.EDU (Leroy Dorman) (07/19/88)
In article <Jul.13.11.23.02.1988.1755@athos.rutgers.edu>, hedrick@athos.rutgers.edu (Charles Hedrick) writes: > > 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. Kernel schedules a swap from sbrk if innsufficient core is available BEFORE releasing the core that the process has. So you need 2 * (current proc size) + requested additional bytes of core to avoid swapping. Lots of memory here is helpful. Don't know why uPort hasn't added in a scheme to simulate a releae of the proc's current memory space and THEN reallocate memory. Took me all of 1 day to make it work. Improved compiles on my Intel 286/310 machine (Multibus At&t Release V/286) (8Mhz 286, 1Mb memory) by 35%!! ld is particularly slow when searching libraries and building symbol tables because of the many mallocs/sbrks that get done. ------------------------------------------------------ Eric Dorman Kirk- "Wheels, Mr. Spock" University of California, San Diego Spock- "A flivver, Captain" Scripps Institution of Oceanography From- A Piece of the Action" siolmd!eric@sdsioa.ucsd.edu
mp1@sdcc12.ucsd.EDU (Leroy Dorman) (07/19/88)
Adding a ramdisk to a 286 uPort box will probably not get the same performance enhancement that adding one to 386 uPort would. 386 uPort supports virtual memory so much of the compiler can page in/out whereas 286 must hold the whole thing or not at all. I don't know if the sbrk code is as dumb as that on V/286 but I doubt it. For a 286, it may (for compiles, at least) be better to allocate ram for program core instead of ramdisk. I would like to see performance specs of various ramdisk sizes on 286/ATs. Would be interesting. ------------------------------------------------------------ Eric Dorman Bele-"Are you blind!?" Scripps Institution "I'm black on the right side." of Oceanography "Loki is white on the right University of California "side. All his people are siolmd!eric@sdsioa.ucsd.edu "white on the right side."