In message <9411120801.AA22990@alpha.bostic.com>,
	"Chris G. Demetriou" writes:
>> 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?

ahem. on every other machine *i've* tried, dhrystones isn't bothered
by the test binary being static or dynamic. it uses times(), which
is called from main(), once before the benchmark code starts, and again
after the run is through. it's not like we're sitting around running time(1)
on things; all of the dynamic linking is finished.

dhrystone comes up with about the same number, regardless of whether
the binary is static or not on my HPs.

>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-)

the point of vareck's mail was that there appears to be something just
a _bit_ off on the SPARCs, and it seems to revolve around shared libraries.
i just, for instance, sat through my SS2 w/64megs take over _three times
longer_ to do a 'make build' than my hp425 (a 25Mhz '040 with 32megs) takes.

programs linked with the shared C lib are physically _slower_, the
hit of dynamic linking aside.

--
                    ----------------------------------------
-------------------// jason downs // downsj@CSOS.ORST.EDU //------------------
                   ----------------------------------------      JD105
	       All new home page! http://www.CSOS.ORST.EDU/downsj