[fpc-pascal] FreePascal 2.0.2 available

[Adrian Veith]

Marco van de Voort schrieb:
>> Congratulations,
>>
>> with fpc 2.0.2 it's the first time, we were able to compile and run our 
>> dbGonzales database server (complete delphi code). In earlier versions 
>> of fpc, we always had some problems (mostly with variants), which caused 
>> runtime crashes.
>> First tests show that the execution speed of  the server is about 10% - 
>> 30% slower than the same code compiled with delphi (win32). On the first 
>> glance, i would say, that these performance problems are in the string 
>> related routines. But this is really a minor problem, since with fpc we 
>> are now able to port to other platforms and it seems that the code 
>> quality improves with each release of fpc.
>>     
>
> - do you compile with optimizations, e.g. -OG2p2r ?
>   
yes I did compile with -OG3p3r, but I did a rebuild with -OG2p2r and  
the results look the same.
> - a few strategically helped inline directives in tight code can do wonders. However this
> 	is not universal.
>   

I already use some inline directives for the delphi2005(6) compiler, and 
have them also enabled when the source compiles with fpc. but anyway, 
this shouldn't be source of the differences in runtime performance.
> - Delphi apps are often hand-tuned to the default memory manager (iow it's deficiencies
>     are worked around with e.g. pooling, and the strengths are left relatively unoptimized)
>      Profiling time spent in the memory manager on both systems and e.g. on Delphi 
>      with an alternate memmgrs like FastMM can help decide if this is the issue.
>   
right, it looks like that some of the performance issues come from the 
memory handler and the string routines. when i compile the delphi code 
without FastMM4, the delphi results are more closer to fpc, but still 
faster. With FastMM4 delphi leads in the string intensive benchmarks 
about factor 1.5 - 1.8. Has somebody already ported FastMM4 to fpc ?

> - A profile comparison in both cases is interesting anyway.
>   

I will try to nail the problem down to some example code. But at the 
moment the picture for me is like this:
Task: Full table scan 100 times of 25000 records
a) Comparing an integer field with a constant value: delphi 0.750 sec - 
fpc 0.765 - factor 1.02
b) Comparing a char field with a constant value ( = operation): delphi 
3.219 sec - fpc 4.734 - factor 1.47
c) Comparing a char field with a constant value (like operation): delphi 
3.453 sec - fpc 6.547 sec - factor 1.89
d) Comparing a char field with a constant value (optimized like 
operation): delphi 2.219 sec - fpc 3.968 sec - factor 1.78

the database dependent operations are similar for all 3 tests. the 
difference is in the operation which is performed 250.000 times.
in a) its getting the integer value of the database field and compare it 
to the value (the compare is without a runtime library call)
b) get the string value of the database field and compare it to the 
value (the compare is done with a runtime lib call to AnsiCompareStr).
c) same as b) but call a function which does a like operation. this 
function is the same for delphi and fpc.
d) get a pointer to string in the database field and call the same like 
function as in c)

I will try to analyze which part of the code makes these differences.