-- System Information ------------------------------------------- Debian Release: stable on Pentium III Kernel Version: Linux 2.2.18pre21/2.2.19 gcc version: 2.95.2 -----------------------------------------------------------------
Hi, While trying to optimize some C code for speed, we have encountered what we think is a very strange bug with gcc: the execution time depends on the name of the executable (!). As an example, here is a bares bones C code snippet which reproduces the problem: /* strange.c ==================================================*/ #define N 1000000000 double content() { return 0; } int main() { int i; double bucket=0; for (i=0; i<N; i++) bucket += content(); return 0; } /*=============================================================*/ When we compile this program (gcc strange.c) and time its execution (time a.out) we obtain: real 0m23.247s user 0m23.240s sys 0m0.000s where "user" is the time we are interested in. Upon renaming the executable we find two widely different execution times: trial name of executable user time (s) --------------------------------------------------------- 1 a 23.24 2 aa 23.25 3 aaa 23.24 4 aaaa 23.24 5 aaaaa 49.92 6 aaaaaa 49.91 7 aaaaaaa 49.92 8 aaaaaaaa 49.92 9 aaaaaaaaa 49.91 10 aaaaaaaaaa 49.90 11 aaaaaaaaaaa 49.90 12 aaaaaaaaaaaa 49.94 13 aaaaaaaaaaaaa 23.24 14 aaaaaaaaaaaaaa 23.21 15 aaaaaaaaaaaaaaa 23.39 16 aaaaaaaaaaaaaaaa 23.62 17 aaaaaaaaaaaaaaaaa 23.79 18 aaaaaaaaaaaaaaaaaa 23.82 19 aaaaaaaaaaaaaaaaaaa 23.57 20 aaaaaaaaaaaaaaaaaaaa 22.83 21 aaaaaaaaaaaaaaaaaaaaa 48.06 22 aaaaaaaaaaaaaaaaaaaaaa 49.02 23 aaaaaaaaaaaaaaaaaaaaaaa 49.93 24 aaaaaaaaaaaaaaaaaaaaaaaa 49.91 etc. --------------------------------------------------------- We are not familiar with the intricate workings of the compiler, but this must have to do with an alignment problem when the executable is launched, as the changes typically occur when the name length is increased by 8 bytes. This is a serious bug since in our simple example it more than doubles the execution time when we choose a "bad" name! We have reproduced the problem on Pentium III machine with gcc 2.95, with a variety of kernels, and with C and C++ codes of varying complexity. The "time" function is not the culprit, since we can confirm our results with a wall clock. We would like to know: 1) Does this behavior occur on other systems? 2) Is this a known issue? 3) Can the cause of the problem be identified? 4) Is there any workaround (e.g. compiler option)? Thanks a bunch, Fred.