Yes, but the point is the actual memory aloc/de-alloc implementation of the C compiler you used.
E.g. with other such "tests" on Raspbian and Debian arm I get much differing results between cmem and the default memory manager with GNU C for armhf.
cmem runs out of memory sooner because of the page size. Other C compilers for ARM do have a noticable effect (the one from ARM itself is a good example).
It depends on application., likely even the type of C libraries you interface with if it has any positive impact at all.
Also note the FPC default settings are extremely conservative compared to C compilers, so you may want to explore the optimization options first:
Alignment, CPU settings, optimization -O settings and even the FPU, e.g. vector math for moves is not used in default fpc. But all these things may have been done in a C version for you and they are not done for you in FPC.
Also note the LLVM back-end can improve things. And furthermore, at least on Intel, there are third-party open source Delphi memory managers that outperform both cmem and the fpc default by several magnitudes in a mutithreading application. These memory managers are easily adapted to Freepascal. There are several real - solid - performance tests available for those memory managers in which cmem is also tested and comes second from last. Memory use can be explosive with cmem, whereas fragmentation is an issue with the FPC default, both when stressed.
The delphi ones I mentioned all have per thread allocators, btw. Cmem does not do that, at least not with the GCC compiler.
One thing to note: in the compiler shoot-out (even with an older fpc) the fpc default memory allocator performs best in memory use offset to others that favor speed at the cost of memory.
But then again: memory managers are pluggable in FPC.