On Fri, Dec 28, 2001 at 11:30:40PM +0000, Russell King - ARM Linux wrote: > I then rebuilt the benchmarks using gcc 2.7.2.2 against libc 4, and > therefore a.out. Here are my results: > > GCC 2.96, GLIBC 2.1.3, ELF > -------------------------- > > BYTE UNIX Benchmarks (Version 3.11) > System -- assabet > Start Benchmark Run: Thu Jan 1 03:01:26 /usr/local/arm 1970 > 1 interactive users. > Process Creation Test 349.4 lps (10 secs, 6 samples) > > GCC 2.7.2.2, LIBC 4.6.27, A.OUT > ------------------------------- > > BYTE UNIX Benchmarks (Version 3.11) > System -- assabet > Start Benchmark Run: Thu Jan 1 03:09:35 /usr/local/arm 1970 > 1 interactive users. > Process Creation Test 600.2 lps (10 secs, 6 samples) > > Both these results were taken from the same machine running the same > kernel without a reboot between the two runs.
Interesting, and not good. I'm not sure if I'm asking na�ve questions, but: Are both the a.out and ELF binaries your compiled against shared libc? If so, does recompiling them with static linking change the performance ratio? 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] 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? Nicholas Clark _______________________________________________ http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm Please visit the above address for information on this list.
