Conference turris::digital_unix

    
    
    
    
    Hello !
         Thx for reply. But SUN also claims that their OS is 64 bit OS.
         Here are the details. can anybody give details on this.
    
Hardware      : Sun 4/280 , SS1 , SS4 , SS10 , SS20 , SS1000 
                Ultra 140 , Ultra 170


OS version    : Sun OS 4.1.3 , Sun OS 4.1.3_u1 , Sun Solaris 2.3 
                Sun Solaris 2.5

Compiler      : GNC ( Solaris OS) , Sun compiler (Sun OS)

Compilation 
switches      : cc -I.   -O  -xcg92   ( On Sun Solaris)
   
                cc -I.   -O  -DA_OSF  ( on Digital Unix V3.2D-1 )

Code size 
difference    : code sizes on DU systems exactly double that of 
                the sizes in SUN solaris or Sun OS.



                                                               

Some suggestions: if you look at a specific image that is bigger (I doubt that
all, if any, are "exactly double"):

- what are you using to determine the file size?  ls -l, or something else?
- are you looking at each file in its 'native' location?
- are the files statically or dynamically linked?
- do the images claim to offer identical functionality (if system utilities)?
- are they compiled from exactly the same source file (if your own code)?
- if your own code, are identical compilers being used?
- were both compilers using the same optimisation techniques (speed vs space)?
- does either image contain debugging or other symbol table information?
- etc

If you can find a distinction between the two images in the above list, that
would go some way to explain image size differences.

A more fundamental question is: why is this a problem?

Scott

    
    
     Thx for reply.
    
    >  - what are you using to determine the file size?  ls -l, or something else?
    
    ls -l 
    
    >- are you looking at each file in its 'native' location?
    
     Yes.
    
    >- do the images claim to offer identical functionality (if system utilities)?
    
     Yes. Images provide identical functionality.
    
    >- are they compiled from exactly the same source file (if your own code)?
    
     Yes. It is same source code. 
    
    >- were both compilers using the same optimisation techniques (speed vs space)?
    
     I don't have idea about that.
    
     On DU : flags used is.  CC -I  -O -DA_OSF 
    
     on SUN OS               CC -I  -O -XCG92
  
     >- does either image contain debugging or other symbol table information?
    
     No. it does not contain.
    
    regards
    Nagaraj Hegde
    

    Don't use "ls -l", use "size". Second, we may well produce somewhat
    larger executables, so what ? Third, none of the SUN operating systems
    you listed is 64-bit (Solaris 2.6 would have a 64-bit mode but
    it would have to be explicitly invoked). Lastly, have the customer
    also try
    
    	cc -std1 -migrate -O3 
    
    on the executables they are concerned about.

I didn't see what version of OSF1 / Digital UNIX / DIGITAL UNIX you were
using.  The newer the release, the smaller the file will be; you should be
using one of the V4.0 variants.

You haven't explicitly acknowledged using the "strip" command -- this is
essential in a comparison of disk space usage.

And as noted, disk space usage tells you nothing about memory usage; you
have to use the "size" command to determine that.

    Hello !
     Thx a lot for clarifications. Now it is clear for me that the SUN guy
    is bluffing. So code size is not a matter of concern for me now. I can 
    clearly tell my customer now.
    
     BTW I am running Digital Unix V3.2D-1.
    
     Regarding performance problem  I have posted the entry in OSF tuning
    notes conference. 
    
     Thx a lot for you all for helping me on this.
    
     Regards
    Nagaraj Hegde

    Hello !
     Thx a lot for you all clearing my doubts and hence my customers's.
    
     This system is running DU 3.2D-1. 
     I could not try 'strip' command on the program which customer is
     running. But when I tried on a sample program The code size 
     reduced by 66.6% on an avarage. (ls -l output ). size command
     dec part showed equal on both part. It showed the size equal to 
     stripped version of code.
    
     Thx a lot for al the help and advice. Now only thing I have to 
    look into performance aspect. I have put an entry in OSF_tuning
    notes entry 113 on this regard. 
    
     Now  I am sure that SUN guy is bluffing. SUN OS which is being used
    is not 64 bit. It gave me a lot of help. And strip command reduced 
    the code size by 66%. So now code size not much of concern. 
    
     Now I can  clear the doubt of customer.
    
     regards
    Nagaraj Hegde

>      But when I tried on a sample program The code size 
>      reduced by 66.6% on an avarage. (ls -l output ).....
>     
>     .... And strip command reduced 
>     the code size by 66%. So now code size not much of concern. 

	You're using the wrong terminology.  The "code size"
	was *not* reduced.  It was the file size that was
	reduced.  See the strip(1) man page, it removes the
	symbol table and relocation bits.

	If you want to reduce code size you'll need to use a compiler
	for which you can tell it to optimize for "size" instead
	of "speed".

    Hello !
     Thx for correcting me. I went through man pages and then used strip 
    command and gave reply. But used a wrong terminology.
    
      File size is reduced as it clearly indicated in man page. 
      Thx a lot.
    
     Regards
    Nagaraj Hegde

    Hello !
     Here is one source and the  statistics of image generated. On SUN OS's
    file size is 1/8th of that in DU 3.2C. On DU4.0A also the size is same.
    
     Is such  drastic difference will happen? Can anybody tell me how can
    I decrease this file size?
    
     
    
The source code is


main
{
	printf("hello world")
}


The executables sizes are :


		DU3.2c		SUNOS4.1	 SUNOS5.5	     HPUX10.1

   ls -l	16384		16384	 	     3604	        12337


   Size		text:8192	text:8192	     2101	         4413
		data:8192	data:8192	      240	          252
		Total:16384	Total:16384 	        4	            8
					       Total:2345 	   Total:4673


	In DU there is no diff. if u compile with -O or -O3 option.



    
    
     Thx & regards
    Nagaraj Hegde

> Here is one source and the  statistics of image generated. On SUN OS's
> file size is 1/8th of that in DU 3.2C. On DU4.0A also the size is same.

	You mean on Solaris it's smaller, as you've shown on plain old
	SunOs the size is the same.

> Is such  drastic difference will happen? Can anybody tell me how can
> I decrease this file size?

	"drastic"?  16kb is still pretty small.  There's going to
	be a certain amount of fixed overhead.  Try a more realistic
	real-world program (ie. something bigger).

	What is interesting about the Solaris and HP sizes is
	that they aren't page multiples.  It seems unlikely
	that when running it could manage to use less than a
	page per program section.  But it would be easy to
	report the minimum byte sizes and then round them up
	to page sizes when running.  Since both Solaris and
	HP-UX have a very strong System V background, it may
	be more than coincedence that neither are page multiples.

    Re. .20:
    
    As both posters before have pointed out, you are just getting the
    minimum size possible for *nay* demand page program, namely
    one text and one data page.
    
    If they want to compare such tiny programs, the should do it at
    the executable function level:
    
    	cc -O -c hello.c
    	size hello.o
        text    data    bss     dec     hex
        64      64      0       128     80
    
    I.e. the program itself compiles to 128 bytes.