Question

The language shootout benchmarks at http://benchmarksgame.alioth.debian.org/ indicate that FPC programs use about 1/50th of the memory that comparable programs using g++ use. Do these benchmarks unintentionally favor fpc or is it really true that FPC is this much better than g++? I’ve always considered these benchmarks as a collection of decent micro-benchmarks, so I’m surprised at these results, since a factor of 50 times is pretty significant IMHO.

References:

http://benchmarksgame.alioth.debian.org/u32/pascal.php
http://benchmarksgame.alioth.debian.org/u64q/pascal.html

Edit:
This is becoming even more interesting since this page claims that pascal used only 8KB for some of the programs, which seems amazingly low

Answer 1

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 sort this out, and since the shootout is open source, the question if you can provide a better measurement is open.

Either that or there is something fundamentally wrong with (g)libc. (I’m no expert at that). A possible solution to get more relevant information would be to run the benchmark on FreeBSD, or a Linux with uclibc. In short anything else but glibc.

As Igouy’s post states, when linking to libc, FPC gets the (bad) characteristics of the other development systems. This is another indicator that the question should be “why do glibc using binaries perform bad in the shootout memory benchmark” rather than “why does FPC perform well in the shootout benchmark”

Note that FPC originally avoided libc because of cross-distribution compatibility concerns, and not performance or filesize.

So to all that assume this is a fluke wrt to measuring the memory usage of FPC, ever considered it is a problem with glibc memory use or the measurement of it? Or rather, that the high glibc number is wrong, and not the low FPC number….

…. A FPC developer ….

(*) and before you can say it is merely developed to be efficient for “sizable” applications, remember that the Unix philosophy is about chaining small tools together, and many Unix processes are shorted lived.