Subject: Re: Strange libc shared vs. unshared performance
To: Vareck Bostrom <bostrov@lava.cs.orst.edu>
From: Chris G. Demetriou <cgd@alpha.bostic.com>
List: port-sparc
Date: 11/12/1994 03:01:40
> Figure this one out guys: 
> 
> (in makefile):
> $(DEFINES) -O4 -funroll-loops -fomit-frame-pointer -static
> 
> % dhry21
> Please give the number of runs through the benchmark: 500000
> 
> ...blah...blah...
> Microseconds for one run through Dhrystone:    40.0
> Dhrystones per Second:                         25020.2
> VAX MIPS rating =     14.240
> 
> 
> 
> Now, try this:
> (in makefile):
> FLAGS = $(DEFINES) -O4 -funroll-loops -fomit-frame-pointer        
> (note lack of -static) 
> 
> % dhry21
> Please give the number of runs through the benchmark: 500000
> 
> ...blah...blah...
> Microseconds for one run through Dhrystone:   113.6
> Dhrystones per Second:                          8801.3
> VAX MIPS rating =      5.009

and why does this surprise you?

if the binary is dynamically linked (i.e. -static is not specified),
then the dynamic linking must take place!  it takes place when
the program is stated, and it's quite likely that depending on how
the program is timed, the dynamic link time is included in the program
runtime.

In general, dynamic linking wins for:
	disk space usage
	memory consumption
and loses for:
	execution time

(note that some execution time can be made up by the smaller memory
consumption, depending on the load on the machine.)

this is a classic space-time tradeoff, and i suggest that you
statically link the binaries for which you care only about speed.
(benchmarks are included in that class of binaries, unless you're
specifically benchmarking the shared linker.  8-)



chris