4 ms·
With disk caches primed, the main culprit may be the dynamic linker. Some of those environments (Java, Perl, Python, PHP that others mention in this thread) alw
by dexen 15y ago
With disk caches primed, the main culprit may be the dynamic linker. Some of those environments (Java, Perl, Python, PHP that others mention in this thread) always load substantial number of dynamic libraries before doing anything useful. That doesn't come free. Numberous symbols have to be resolved, some static data initialized. There's non-trivial VirtualMemory to set up for such libraries, too.
For some more info: http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/
EDIT: a micro-benchmark between static and dynamic C program:
gcc -- static a.c
time (for i in `seq 1024`; do ./a.out > /dev/null; done; )
real 0m0.958s
####
gcc a.c # that's dynamic linking
time (for i in `seq 1024`; do ./a.out > /dev/null; done; )
real 0m1.292s
...and that's just libc alone! Those times were quite stable across several runs, so it's not some random one-time fluctuation.
The code:
#include <stdio.h>
int main(void) {
puts("hello world!");
return 0;
}
- uriel 15y agoThis is one more reason why I love dynamic linking, fork/exec for static binaries is much faster than for dynamic ones, even for simple C programs that only use libc.
- comex 15y ago> This is one more reason why I love dynamic linking, fork/exec for static binaries is much faster than for dynamic one Hm... huh?
- dexen 15y ago`⸮' is the symbol you are looking for -- and uriel missed :-) http://en.wikipedia.org/wiki/Irony_punctuation http://en.wikipedia.org/wiki/Irony_punctuation
- igouy 15y agohttp://shootout.alioth.debian.org/gp4/program.php?test=hello&lang=gcc&id=3 http://shootout.alioth.debian.org/gp4/program.php?test=hello...
- dexen 15y ago[nitpick mode] What a misleading example. That's not GNU hello world, that's Linux hello world. The difference: it does not use GNU libc nor any other parts of GNU project -- except for the `unistd.h' -- but instead interfaces with the kernel directly. Another matter is that it's not a C program, as it doesn't have int main(...) :P [/nitpick mode]
- igouy 15y ago>>does not use GNU libc nor any other parts of GNU project<< On the contrary: - The program is compiled with GCC - "GCC development is a part of the GNU Project..."
- dexen 15y agoThat you used GCC is irrelevant; other compilers would give pretty much the same result. GCC is not required by the program by any means. Nothing of GCC is part of the program itself due to the -nostartfiles flag. The program doesn't use GCC, you (the software developer) do :-) For sake of example, consider Linux (the kernel); usually compiled with GCC -- but ICC works as well -- and distributed under GPL, yet is not part of GNU project. Moreover, the program in question can be ran directly on bare Linux, with no GNU stuff present anywhere, if passed via `init=PATH_TO_THE_PROGRAM' boot param. Of course the kernel would panic right after the syscall(__NR_exit, 0)... so I'm bailing out of nitpick mode right now ;-)
- igouy 15y ago>> The program doesn't use GCC... << Before your kernel panic out of nitpick mode, shouldn't you at least have compiled and run that hello world program with ICC? ;-)