[fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/11/2017 02:48 PM, Graeme Geldenhuys wrote:
> On 2017-05-11 19:43, James Richters wrote:
>> Any Suggestions?
>
> Speed:
>   In recent graphics work I've done, I've noticed that FPC is fantastic
>   at created cross-platform applications. But the generated binaries
>   are NOT fast at all - no matter how many compiler parameters and
>   artificial speed optimisations we tried to implement. Sloppy Java
>   code ended up 3x faster than the best I could get out of FPC
>   generated binaries.
>
>   I'm not saying this is your performance problem (especially comparing
>   a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another
>   problem contributing to your speed issue.
Wow, Graeme! That's harsh. One of the last set of benchmarks I did that 
focused on integer math and procedure call speed came out as follows:

Run 1M numbers
Intel 2GHz 2016:
===================================
pascal:        2:09s - 2:12
c:             2:06s - 3:05
Java           2:11s - 2:24
js (JIT):      2:23s - 2:27
python:       36:43s - 37:02
php:          38:16s - 40:45
js (interp):  60:51s - 64:10
perl:         69:19s - 74:26

Times are in minutes:seconds.

"Pascal" is, of course, FPC. I believe I used fpc 2.6.4 w/ -O2 on that run. 
Its been a while. The code that was used was as identical as it could be 
for each of the languages represented. I was interested in the speed of the 
languages' general mechanics, not special features that one might have over 
the others. These are the performance ranges from my Linux box running at 
2GHz. I ran four runs each. On average the Pascal code performed about the 
same for each run and the C code, for whatever reason, tended to get slower.

Two things surprised me when I ran this: the Java speed and the speed of 
the initial JavaScript run. I used SpiderMonkey (Mozilla) for the JS test 
and OpenJDK 6 for Java. Both apparently have *VERY* effective JIT 
compilers. You can see from the "js (interp)" entry what you would expect 
if the benchmark were run in a browser. But I think Chrome(ium) is/are 
starting to ship with JIT enabled in V8. I didn't bother to find out how to 
turn off JIT in OpenJDK. If I had, I'd expect it to fall in the 40minut 
range like the rest of the interpreters.

As far as raw computational power I'd pit FPC against any 
native-code-compiled language, especially considering the register calling 
convention. I've rewritten several of the standard *nix routines provided 
by GNU simply because I can do it 100x or more faster in FPC.

In short if your suffering a performance issue I'd look to the libraries in 
use for poor implementations. Like anything else, bad software can be 
written with FPC too.

A funny story:

Back in 2000 I wrote a TStringList replacement because the Delphi/Kylix 
version was astoundingly slow (specifically TStringList.IndexOf()). I 
thought I'd get fancy and provide a mode where I'd keep the list sorted and 
use a binary search to find elements. I figured it'd be fast because 
reordering the list was just moving pointers. In either mode it was way 
faster than the Borland's implementation. Fast forward to about 2010 and I 
was parsing millions of Apache log lines and using my trusty string list 
when I noticed it was taking a LOT longer than expected. I turned off the 
fancy sorted-binary-search mode and performance was significantly better. 
But that left me scratching my head. What was wrong with my logic?

Last year I finally got mad at it and took a closer look. Since I could not 
find a flaw in my logic I looked at the assembly code produced by FPC. 
Turns out that every time you assign a long string to a variable it makes a 
function call to inc & dec the use counter as necesary. This was adding a 
*HUGE* performance penalty! I now fake FPC out by casting to pointers to 
move the strings in the list, since I'm not actually changing the use 
count. The performance gain was staggering!

-- 
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
jon at jfpossibilities.com