On Sat, Dec 29, 2001 at 02:24:04PM +0000, Nicholas Clark wrote:
> Are both the a.out and ELF binaries your compiled against shared libc?
Yep.
> If so, does recompiling them with static linking change the performance
> ratio?
Recompiling them as static ELF reveals:
BYTE UNIX Benchmarks (Version 3.11)
System -- flint
Start Benchmark Run: Sat Dec 29 22:45:38 GMT 2001
9 interactive users.
Arithmetic Test (type = double) 446.0 lps (10 secs, 6 samples)
Dhrystone 2 without register variables 345533.6 lps (10 secs, 6 samples)
Execl Throughput Test 78.0 lps (9 secs, 6 samples)
Pipe-based Context Switching Test 2477.8 lps (10 secs, 6 samples)
Shell scripts (1 concurrent) 381.4 lpm (23 secs, 3 samples)
Shell scripts (2 concurrent) 202.4 lpm (21 secs, 3 samples)
Shell scripts (4 concurrent) 103.5 lpm (22 secs, 3 samples)
Shell scripts (8 concurrent) 52.0 lpm (24 secs, 3 samples)
Process Creation Test 330.8 lps (10 secs, 6 samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Arithmetic Test (type = double) 2541.7 446.0 0.2
Dhrystone 2 without register variables 22366.3 345533.6 15.4
Execl Throughput Test 16.5 78.0 4.7
Pipe-based Context Switching Test 1318.5 2477.8 1.9
Shell scripts (8 concurrent) 4.0 52.0 13.0
=========
SUM of 5 items 35.2
AVERAGE 7.0
ie, very little change (its interesting to note the difference in the
dhrystone 2 result). Compare these values with the fb2218 line.
> What are the relative sizes of the two programs?
> What are the relative amounts of RAM they use? [probably most influenced by
> runtime structures generated by the C library that the fork has to copy, or
> at least arrange to copy-on-write]
For the process creation test:
a.out ELF
VSZ 880 1248
RSS 80 344
ELF:
text data bss dec hex filename
1742 304 32 2078 81e pgms/spawn
text data bss dec hex filename
1093047 21224 15560 1129831 113d67 /lib/libc-2.2.2.so
text data bss dec hex filename
87754 1676 980 90410 1612a /lib/ld-2.2.2.so
A.OUT:
text data bss dec hex filename
32736 32768 0 65504 ffe0 pgms/spawn
text data bss dec hex filename
618464 65536 182064 866064 d3710 /lib/libc.so.4.6.27
text data bss dec hex filename
98272 32768 0 131040 1ffe0 /lib/ld.so.1.7.14
> Is it possible to take the 2.7.2.2 compiled main program, convert the a.out
> files to ELF and link against the glibc? [or the other way] to reduce the
> number of variables being changed at the same time? It appears that the
> two programs differ in (at least)
>
> a.out vs ELF
> 2.7.2.2 vs 2.96
> libc4 vs glibc
>
> and it could be any one of these factors that accounts for the slow down.
>
> With a static executable, is it possible to convert it between a.out and ELF?
> If so, could this effectively make an a.out binary of the glibc linked code?
Unfortunately, you can only have an ELF toolchain that doesn't understand
a.out, or an a.out toolchain that doesn't understand ELF.
[note: Binutils does allow the toolchain to support both a.out and ELF via
the BFD backend (except for as and ld). We just don't allow it because
no one has put the effort in to make it work].
Another interesting datapoint - the byte benchmarks also have a system call
overhead test. Using this to compare a.out to dynamic ELF to static ELF
reveals nothing to write home about - the results are as close as to be
identical (within 5 to 10%).
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
