Note that startup time is IIRC another benchmark where FPC peaks
I think the answer must be primarily sought in the fact that Free Pascal statically links programs by default, avoiding libc and other auxiliary libraries
This has several consequences:
- For the simple programs that are being benchmarked, FPC programs are static using only the own RTL (no static copy of libc) and have no dynamic linking overhead (both in time and memory). Including mapping shared glibc segments (is this so?) that might be mistaken for application memory use.
- libc might do potentially unneeded but involved initializations that FPC doesn't do for these simple programs. (like initializing zoneinfo)
- since FPC uses a totally independent memory manager, the initial block of the heap suballocator might have a different size. Possibly FPC's is systematically smaller.
- For threads, the size of the new thread's stack might cause various differences (size and maybe the fact if it is (partially) only a reservation or committed memory, or whatever the *nix equivalent is of that)
All in all, I think this observed behaviour is less about FPC, and more about lack of variation amongst the other benchmarked development systems . FPC merely stands out, because nearly everything else is built on top of the gcc/glibc technology (either because they are a direct gcc derivate or because their VM/interpreters are built on top of gcc), and thus all share libc's general treats. FPC being different merely highlights (g?)libc's bad scaling towards simple programs. (*)
The shootout probably might be biassed in the sense that either shared adress space is counted rather than actually used private bytes, or because it doesn't differentiate enough between private bytes allocated by the suballocator and private bytes actually used by the process. It would probably require a libc/libmalloc core devel however to s
answered 2012-06-28T19:15:44.590