coleman@sask.UUCP (Geoff Coleman @ College of Engineering) (09/24/87)
Ok all you experts out there who can explain this new
feature of Ultrix 2.0 and its C compilers.
We just installed Ultrix 2.0 on a uVax-II. Last night I
recompiled a couple of C programs using both the VAX C
compiler and the default comnpiler. The new executables were
~2.5 times the size of the old one.
Anybody out there have a good explanation for this.
--
Geoff Coleman | BITNET: Coleman@sask
College of Engineering | UUCP: {utcsri,ihnp4}!sask!skul!geoff
University of Saskatchewan | Compserve: 76515,1513 just a number
Saskatoon, Saskatchewan | voice: (306) 966-5415gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/27/87)
In article <867@sask.UUCP> coleman@sask.UUCP (Geoff Coleman @ College of Engineering) writes: >The new executables were ~2.5 times the size of the old one. You didn't provide much information -- It would have been helpful to know if the size increase was in the .text PSECT or .data. My initial guess would be that the new compiler initializes .data for global uninitialized data rather than using .bss. At least, that's one difference between old and new VAX PCCs (e.g. BSD's and System V's). That certainly makes for larger object files.
davew@gvgpsa.UUCP (09/27/87)
In article <867@sask.UUCP> coleman@sask.UUCP (Geoff Coleman @ College of Engineering) writes: >Ok all you experts out there who can explain this new >feature of Ultrix 2.0 and its C compilers. > >We just installed Ultrix 2.0 on a uVax-II. Last night I >recompiled a couple of C programs using both the VAX C >compiler and the default comnpiler. The new executables were >~2.5 times the size of the old one. > > Anybody out there have a good explanation for this. I have noticed the same thing, although not as exaggerated. The executables from my compilations with the VAX C Compiler were about 1.2 - 1.4 times as large as those with the standard C compiler. I was comparing stripped files which makes me wonder if Geoff was comparing stripped vs. unstripped files. What I am really curious about is whether anyone has done any benchmarks between the standard C compiler and the VAX C compiler supplied with Ultrix 2.0-1? I can live with larger executables if they execute faster. -- =================================================================== Dave White Grass Valley Group, Inc. P.O. Box 1114 Grass Valley, CA 95945 UUCP: ...!tektronix!gvgpsa!davew PHONE: +1 916 478 3052
tp@td2cad.intel.com (t patterson) (09/28/87)
In article <6473@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <867@sask.UUCP> coleman@sask.UUCP (Geoff Coleman @ ) writes: > >The new executables were ~2.5 times the size of the old one. > > You didn't provide much information -- It would have been helpful > to know if the size increase was in the .text PSECT or .data. > ... here's a few numbers to gnaw on... Ultrix 2.0 binaries do seem to have gotten markedly bigger than the 1.2 binaries. Note that /lib/libc.a on 2.0 is 262760 bytes and is only 167076 on Ultrix 1.2. I suppose most of the difference is the added NFS and YP code (leading to NFS-bloat just like in 4.3 + NFS). My seat-of-the-pants feeling is that Ultrix 2.0 has made most of the executables for my programs 10-20 % bigger. But why listen to me? I did a 'size /bin/*' on an Ultrix 1.2 and on an Ultrix 2.0 system; for each column output by 'size', I calculated size for Ultrix 2.0 - size for Ultrix 1.2. For example, in the listings below, /bin/ls has 21 K more text space in Ultrix 2.0 than in 1.2 and about 5 K more data space ( doing ls -l reveals 2.0 ls to be 43 K and 1.2 ls to be 16 K, so the difference seems to agree with actual file size). Interpret the results as you wish -- if I had Ultrix 2.0 source now, I'd have a better idea how much DEC monkeyed with the programs -- still, I'd guess that some of the size changes are due to calling library routines with NFS-related code in them. (of course, the contents of /bin are not perfectly representative samples of code, but you all know what these programs do, so you can apply your own mental extrapolations to your own code...) and the new DEC vcc is entirely another issue... Differences between 2.0/1.2 as reported by /bin/size (bytes of bloat) text data bss dec /bin/ls 21504 5120 28968 55592 /bin/mdtar 36864 8192 6220 51276 # tar was heavily modified /bin/tar 36864 8192 6220 51276 # by DEC (for the worse?) /bin/login 24576 4096 4960 33632 /bin/mail 22528 3072 6068 31668 /bin/su 22528 4096 1936 28560 /bin/chgrp 22528 3072 2576 28176 /bin/make 20480 5120 2540 28140 /bin/csh 21504 2048 3100 26652 /bin/who 19456 5120 1988 26564 /bin/ps 20480 3072 2172 25724 /bin/dd 5120 0 44 5164 # sharp break here; differences /bin/awk 2048 0 784 2832 # from here down are probably /bin/as 2048 0 84 2132 # insignificant /bin/passwd 0 0 1420 1420 /bin/adb 1024 1024 -664 1384 /bin/ar 1024 0 308 1332 /bin/diff 1024 0 304 1328 /bin/write 1024 0 124 1148 /bin/sed 1024 0 60 1084 /bin/sh 1024 0 8 1032 /bin/cp 1024 0 0 1024 /bin/nice 1024 0 0 1024 /bin/pwd 1024 0 0 1024 /bin/size 1024 0 0 1024 /bin/tee 1024 0 0 1024 /bin/ed 792 0 0 792 /bin/wall 0 0 380 380 /bin/pr 0 0 304 304 /bin/du 0 0 196 196 /bin/ld 0 0 188 188 /bin/ln 0 0 180 180 /bin/od 0 0 172 172 /bin/mt 0 0 112 112 /bin/mv 0 0 84 84 /bin/date 0 0 24 24 /bin/kill 0 0 12 12 /bin/[ 0 0 0 0 { cat, cc, chmod, cmp, echo, expr, hostid, hostname, mkdir, nm, rm, rmail, rmdir, strip, stty, sync, test, and time all had 0 size difference } /bin/df 1024 -1024 -12660 -12660 how I got this: rsh ctdove size '/bin/*' | grep -v 'not an object' >dove.sizes #dove is an Ultrix 2.0 uvax rsh ctdune size '/bin/*' | grep -v 'not an object' >dune.sizes #dune is an Ultrix 1.2 uvax join -j 6 dove.sizes dune.sizes | awk ' NF == 11 { print $1 \ "\t" $2-$7 "\t" $3-$8 "\t" $4-$9 "\t" $5-$10 }' | \ sort +4nr >foo vi foo # to straighten up columns and produce this output The only program which shrank appreciably is 'df'; it also appears to have been broken in 2.0. ("df /usr" or "df /any_file_system" keeps giving me same output as "df /" ) -- ..tp.. t patterson domain: tp%td2cad.intel.com@relay.cs.net path: {ihnp4,cbosgd,uunet}!wucs1!td2cad!tp {decwrl,hplabs,oliveb}!intelca!mipos3!td2cad!tp
jpn@teddy.UUCP (John P. Nelson) (09/28/87)
>We just installed Ultrix 2.0 on a uVax-II. Last night I >recompiled a couple of C programs using both the VAX C >compiler and the default comnpiler. The new executables were >~2.5 times the size of the old one. This has nothing to do with the Compiler per-se: It is related to the C library. Ultrix 2.0 supports NFS and YP (yellow pages). No doubt your (relatively small) program calls pwuid() (or other password file routines). Since the password file can now be shared via yellow pages, the entire yellow pages library is loaded. Of course, if you do not use YP, you still have to carry around the YP code. I don't know of any way to prevent this. Note that since ULTRIX defaults to demand-page loading of tasks, if you do not use YP, this code never even get loaded off disk!
cck@cunixc.columbia.edu (Charlie C. Kim) (09/28/87)
Ultrix 2.0 introduces YP/NFS + nameserver support. You're probably picking most of it up from YP. In other words, it's not the compiler, it is the new libraries. Charlie C. Kim User Services Columbia University
mcm@rti.UUCP (Mike Mitchell) (09/29/87)
I've noticed that the compiler inserts NOOP's and HALT's to align branch
targets and subroutines to long-word boundries. This is not necessary on
a VAX, but I guess that the pre-fetches in the instruction unit could
throw out the noops when it sees them. Aligning things to 32-bit boundries
might make it a little faster. I have not done any timings to confirm this.
Besides, what is faster for a uVAX-II might be slower for an 8600. Who knows
what CPU they optimized the code generator for?
--
Mike Mitchell {decvax,seismo,ihnp4,philabs}!mcnc!rti!mcm mcm@rti.rti.org
"There's laughter where I used to see a tear. w (919) 541-6098
It's all done with mirrors, have no fear." h (919) 361-2048steve@nuchat.UUCP (Steve Nuchia) (09/30/87)
In article <6473@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <867@sask.UUCP> coleman@sask.UUCP (Geoff Coleman @ College of Engineering) writes: > >The new executables were ~2.5 times the size of the old one. > > You didn't provide much information -- It would have been helpful > to know if the size increase was in the .text PSECT or .data. Indeed. We don't even know for sure that it was any of the above. The first source for that kind of expansion that pops into my head is the symbol table. If you're stripping the binaries before comparing them this idea is all washed up; otherwise the new compiler may be trying to do you a favor by including more useful debugging info in the symbol table. Or it might be broken and not leaving out all the useless stuff it should. The next most likely cause is rampant dependancies in the library. To track this down you need to run nm (with appropriate incantations) and see how much of the bloat is your code and how much is library expansion of one form or another. -- Steve Nuchia Of course I'm respectable! I'm old! {soma,academ}!uhnix1 Politicians, ugly buildings, and whores !nuchat!steve all get respectable if they last long enough. (713) 334 6720 - John Huston, Chinatown
zyg@geovision.UUCP (Zygmunt Wiercioch) (10/03/87)
In article <867@sask.UUCP> coleman@sask.UUCP (Geoff Coleman @ College of Engineering) writes: > >Ok all you experts out there who can explain this new >feature of Ultrix 2.0 and its C compilers. >We just installed Ultrix 2.0 on a uVax-II. Last night I >recompiled a couple of C programs using both the VAX C >compiler and the default comnpiler. The new executables were >~2.5 times the size of the old one. > Did the executables grow with cc and vcc ? I suspect that the executables grew in size only when you used vcc and lk. There is a bug in the vcc/lk combination of VAX C on Ultrix 2.0 (at least the version we have). The problem occurs with modules that include <stdio.h> and/or <math.h>. The vcc compiler marks externals in these headers in such a way that the lk linker brings in all functions having refernces to these externals. The problems are errno in math.h and the io buffer in stdio.h I belive. Can't check, our 2.0 machine is off the net at moment, but try an ln on a simple object file. A simple test comsisting of these three files should show this behaviour: main.c: #include <stdio.h> main() { a(); } a.c: #include <stdio.h> a() { printf ("Function a was called\n"); } b.c: #include <stdio.h> b() { printf("B was called\n"); c(); } Now vcc a and b and place in a library. Note that function c is not in the library. vcc main, and serach the library containing a and b. You will get c as an unresolved. If c were in the library, it would go into the executable. As a result, if you compile and link using vcc, and use libraries, your executables will become huge, since virtally all the functions in your libraries will be dragged in, needed or not. The other big problem I have with VAX C on Ultrix is that it issues warnings about constructs such as: #if 3b2 ... #if tahoe .. which <math.h> is full of. The lk linker reports all modules which were compiled with warnings, resulting in a lot of junk output. In the lovely VMS LK%W%... style too. :-) VAC C does do a good job of optimizing the code for the VAX architecture, but it is not usable in the current state. Sure hope DEC gets it right with version 1.1. -- Zygmunt Wiercioch 613-722-9518 GeoVision Corp, 350-1600 Carling Ave Ottawa Canada K1Z 8R7 UUCP: ...!utzoo!dciem!nrcaer!cognos!geovision!zyg