RCAPENER@cc.utah.edu (06/10/90)
In article <1990Jun8.213230.10693@cbnewsl.att.com>, arny@cbnewsl.att.com (arny.b.engelson) writes: [ Hello World code and other stuff deleted ] > I can't believe I'm doing this. I got curious enough to go run these on > a VAX/VMS system using DEC's Ada and C compilers. Given the results, I > decided to post them (and start a war I'm sure, but what the hell)... > > First of all, I ran the compilers with their default settings, no special > optimizations, pragmas, options, nothing. Second, the source looks exactly > like Mike's programs above. Last, the results: > > Ada executable = 6 blocks (512 byte blocks) > C executable = 87 blocks " > I can't either, since I assume you already know that Ada (and almost all other languages on VAX-VMS) link in the shared libraries by default, while C does not. To do that you need a file (name it SHARE.OPT) in your SYS$LOGIN directory that has the following line in it: sys$share:vaxcrtl/share then you link your files as follows: link file1,file2,file3,sys$login:share.opt/opt You can also create a simple clink.com file for handling one *.obj file that was created from one C source file. Put it in your SYS$LOGIN dir. It is as follows: $ if "''p1'" .nes. "" then goto$ setlinkfile $ if "''shlinkprevfile'" .eqs. "" then goto$ getfile $ $goto dolink $ getfile: $ inquire p1 "enter filename" $ setlinkfile: $ shlinkprevfile == "''p1'" $ dolink: $ link 'shlinkprevfile',sys$login:share.opt/opt $ assign/user sys$command sys$input $ exit You also need the following line in your LOGIN.COM file: $ clink :== @sys$login:clink You will notice that now that the C code is linked with the shareable libraries, it shrinks drastically in size, and is usually smaller than the equivalent Ada *.exe file. This blurb was provided for the enlightenment for those in the Ada community that work strictly on UNIX and DOS machines. If you link the non-shared libraries with C (the default), and link the shared libraries with Ada (also the default) on VAX-VMS, you are comparing apples with oranges. Link the C generated code shared, and we have a fairer apples - apples comparison. I am sure Arny knew this, and produced it solely for the entertainment of the VAX-VMS community. Happy times with Ada (pun intended)
arny@cbnewsl.att.com (arny.b.engelson) (06/11/90)
In article <68773@cc.utah.edu> RCAPENER@cc.utah.edu writes: >In article <1990Jun8.213230.10693@cbnewsl.att.com>, >arny@cbnewsl.att.com (arny.b.engelson) writes: > > [ Hello World code and other stuff deleted ] > >> Ada executable = 6 blocks (512 byte blocks) >> C executable = 87 blocks " > >I can't either, since I assume you already know that Ada (and almost all >other languages on VAX-VMS) link in the shared libraries by default, while >C does not. To do that you need a file (name it SHARE.OPT) in your SYS$LOGIN > >You will notice that now that the C code is linked with the shareable >libraries, it shrinks drastically in size, and is usually smaller than >the equivalent Ada *.exe file. > >This blurb was provided for the enlightenment for those in the Ada >community that work strictly on UNIX and DOS machines. If you link >the non-shared libraries with C (the default), and link the shared >libraries with Ada (also the default) on VAX-VMS, you are comparing >apples with oranges. Link the C generated code shared, and we have >a fairer apples - apples comparison. I am sure Arny knew this, and >produced it solely for the entertainment of the VAX-VMS community. Well, yes, if you link the C code with the shareable libraries it gets much smaller (actually I believe it ends up to be almost the same size as the Ada executable, give a block one way or the other), and yes this then becomes more of an apples to apples comparison. But, the problem is a lot of people DON'T take these issues into account when doing language comparisons. When your novice programmer (or an experienced programmer in a new environment) sits down to write some code, they will come up with the results I posted, since there will probably be nobody there to enlighten him/her. Depending on when you receive the articles, you may already have seen another post of VMS results with even worse numbers for C than mine (FYI, I am running different versions of the products than he is). Sure gets your attention, doesn't it? In any case, this is part of the reason such language comparison results are often meaningless, despite the fact that they ignore the larger issues such as life cycle costs. Reminds me a lot of statistics. Which language is more efficient? Well, which language do you WANT to be more efficient? -- Arny Engelson att!wayback!arny