Does Freepascal really use *far* less memory than gcc

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.

Answer 2

Yes, it's really true that the unix utility top reports that those Pascal programs use that much memory, and those C++ programs use that much memory.

For example, on x64, while the Free Pascal n-body program is run and while the C++ n-body program is run, top reports these measurements --

VIRT        RES       SHR
 608          4         0 FPC
7208        420       332 C++

The memory use top reports for the Free Pascal programs is the memory use that the benchmarks game reports for the Free Pascal programs.

---

Now look at that x64 quad-core comparison

We can see 2 different cases:

1. Both the Pascal and C++ programs use multiple MBs and the memory use is very similar, differing by less than ~2x. When additional memory is allocated to solve the task, there's not much difference between the programs.

2. The C++ programs uses a few hundred KB and the Pascal program uses a few KB. When additional memory is not allocated to solve the task, the Pascal programs use a few hundred KB less.

---

The question presents 2 alternatives, but there's usually a third alternative - Have I misunderstood what's going on?

The fact that a C++ mandelbrot program could use 4000x more memory than a Pascal mandelbrot program was too much for the OP to believe, it seemed impossible to the OP - but there's a simple enough explanation, time/space tradeoff.

The C++ program is multi threaded, written to use multi core; but the Pascal program is single threaded, written to use single core.

The memory use of a Pascal multi threaded mandelbrot program is very similar to that of the C++ multi threaded program.

---