Hi.

I just tried to unfairly compare fpc-compiled binary and gcc-compiled binary under my Gentoo box. FPC is incredible. `ps` data shows the fpc one costs nearly no memory? But I still notice it is a little slow. It usually costs 0.5~1.0 time more than the gcc one. It seems as if fpc saves memory in the cost of performance loss. Is it true? If so, is there any options for better performance and no such insane memory saving?

Interestingly, I just tried gpc also, gpc binary sometimes has a better performance, but even cost more memory than gcc, which is not tolerable.

Another question. I cannot find any declaration of the system procedures such as WriteLn and ReadLn. I tried to find in fpcsrc directory with grep but achieve nothing. FreePascal's documents says the declarations are in rtl but the line number is 0. Are these system procedures implemented in the compiler(built-in) or in the system unit? I would like also to know the situation in C. (I mean declaration of printf and scanf. Are they implemented in glibc or gcc?)

Thank you very much.

章宏九 wrote

I just tried to unfairly compare fpc-compiled binary and gcc-compiled binary under my Gentoo box. FPC is incredible. `ps` data shows the fpc one costs nearly no memory?

The FPC run time library is much less extensive than the GNU C library (e.g., it does not include all of the locale information that the C library has). In case you are linking statically, then you should also note that the GNU C library is absolutely not optimized in any way to produce small binaries when linking statically (while the FPC run time library /is/ optimized for that purpose). A comparison with something like uClibc would probably give somewhat more comparable results.

I'm also not sure how you are measuring "memory usage". If you are looking at the VSIZE, note that this does not mean anything (since not all that memory is actually used; RSS is better).

But I still notice it is a little slow. It usually costs 0.5~1.0 time more than the gcc one. It seems as if fpc saves memory in the cost of performance loss. Is it true?

No. FPC simply has a lot less optimization passes than gcc. Depending on the compiled program and the host processor, this may matter a lot or very little.

If so, is there any options for better performance and no such insane memory saving?

The memory usage is completely unrelated to the code speed.

read(ln)/write(ln) is handled internally in the compiler, and translated into calls to different helpers in the RTL based on the actually used types. You can find these helpers in rtl/inc/text.inc (search for fpc_read and fpc_write). You can also compile with -al and look at the resulting .s files to see how the compiler translates the Pascal statements into assembler code (and which helpers it calls).

I would like also to know the situation in C. (I mean declaration of printf and scanf. Are they implemented in glibc or gcc?)

In glibc.

Jonas

2009/9/24 Jonas Maebe :

Not VSIZE. RSS. I know these are not accurate data. And I said this is unfair, rather unfair. I read shootout.alioth.debian.org. Their result might be more accurate, which proves that fpc does. I know all these test cannot tell everything. But qualitative result are approximately the same and, IMHO, can be refered.

Unlike pascal?

(Your swift response surprised me...)

Depends completely on what you are doing. In general fpc is known to use not that much memory. If you want a faster executable you can try the different optimization options. Also keep in mind that by default fpc compiles code which can work on the oldest pentium processors. (or maybe even i486?) Try for example -Oppentium4. (if you're not using 64-bit)

If you use writeln a lot, that's known to be slow by default because the output buffer is rather small. You can use google for tips how to increase this buffer.

WriteLn and friends are implemented with some 'compiler-magic'. That's because you can do things with writeln you can't do with other procedures, like: writeln(stringtype, ': ', integertype); ie: use an unlimited list of parameters which type may be almost everything.

I would like also to know the situation in C. (I mean declaration of printf and scanf. Are they implemented in glibc or gcc?)

gcc, I would guess.

Joost

Yes and no. In both Pascal and C, the internal functionality of the read/write (scan/print) code is in the run time library. However a) in Pascal, the compiler parses the types that you pass to the read/ write code and directly calls the appropriate helper routines b) in C, the types are specified in the format string and the run time library itself determines the actual types at run time

So scanf/printf are more complex than the Pascal read/write routines. FPC and Delphi nowadays also have printf/scanf-style routines though. They are called format and scanf (part of the sysutils unit).

Jonas

Thank you very much.

2009/9/24 Jonas Maebe :

In our previous episode, 章宏九 said:

Performance is not an homogenous entity where you can pull on a lever, and it will optimize the program in the direction that you imagine.

First you will have to determine what the bottleneck exactly is, and if it is similar to the bottleneck in your real application.

It might not be related to the actual generated code at all, just a overly big reliance one bit of library functionality that happens to be slightly faster in gcc.

It could even be a matter of slightly different defaults, like that FPC has standard fairly small I/O buffers iirc, and setting larger buffers on I/O might help.