[fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/18/2017 07:19 AM, Reimar Grabowski wrote:
> On Thu, 18 May 2017 20:32:57 +0700
> Ryan Joseph<ryan at thealchemistguild.com>  wrote:
>
>>> On May 18, 2017, at 8:23 PM, Graeme Geldenhuys<mailinglists at geldenhuys.co.uk>  wrote:
>> The compiler must be doing something really stupid for it mess up like that but how can we know?
> By getting the source of Graemes test, using a profiler on it and having a look at the results?
>
I compiled Graeme's code which was surprisingly easy. I guess I already had 
SDL installed with the dev files. FPC on my old 2GHz Intel gets 2fps. With 
Java (OpenJDK 1.6.x) I get a pretty steady 14fps. On my 3yr notebook with a 
1.9GHz Intel I get 4fps for FPC and 18fps for Java. I find it amusing the 
slower chip is faster. But there has been significant hardware improvements 
over the years.

I would have provided the fps for C++ but I haven't figured out how to get 
it to render the same content. It was doing half the resolution. I upped 
the window size which was obvious but it appears to be magnifying the same 
low pixel count. I've got to get back to work so I'll have to stop fiddling 
with this.

Both devices are multi-core Intel processors, obviously two different 
families, running 32bit Linux with Xorg for the display. FPC is version 
3.0.0. For the benchmark runs I used "-XXs -O3" for compiler switches.

I limited run time to 10secs, and used "time" to verify actual run time. 
Here are the results, time output listed first and the first section of the 
gprof output without comments:

10.05user 0.01system 0:10.11elapsed 99%CPU (0avgtext+0avgdata 9188maxresident)k
0inputs+272outputs (0major+1010minor)pagefaults 0swaps

Flat profile:

Each sample counts as 0.01 seconds.
   %   cumulative   self              self     total
  time   seconds   seconds    calls  Ts/call  Ts/call  name
  62.44      1.33     1.33                             fpc_frac_real
  26.76      1.90     0.57 MATH_$$_FLOOR$EXTENDED$$LONGINT
  10.33      2.12     0.22                             FPC_DIV_INT64
   0.47      2.13     0.01 SYSTEM_$$_GENRAND_MT19937$$LONGINT
   0.00      2.13     0.00       43     0.00     0.00 P$TEST_$$_RENDER
   0.00      2.13     0.00        8     0.00     0.00 
P$TEST_$$_INTTOSTR$LONGINT$$ANSISTRING
   0.00      2.13     0.00        1     0.00     0.00  P$TEST_$$_INIT
   0.00      2.13     0.00        1     0.00     0.00  main


The code that is slow appears to be all standard floating point and integer 
math (* / mod + - >> <<). All of the time is spent in the render() 
function's main loops (lines 191-282 inclusive). I might have missed 
something but I didn't see any function calls of any concern. I rem'd those 
lines out and my frame rate jumped to ~1200. Obviously all I saw was a 
black screen. But I wanted to eliminate the SDL calls from the suspect list 
and make sure I had targeted the right lines.

I'm convinced that its not the integer math from the benchmarks I published 
earlier. And I thought everyone used the FPU so .... I never imagined there 
could be a significant speed difference with floating point. But this feels 
like the compiler is using software math instead of the FPU. I tried 
various -Cf... switches and either got the same results or "Access 
Violation". Even tried "-Ce" and the compiler said it was an invalid switch.

I suppose there could be something else I'm missing. Much more work to do 
to find the culprit.

Seems like the compiler team should be very interested in this. Fortunately 
I don't do much with floating point math or I'd probably be heading back to 
C/C++. Ugg. I can still churn through millions of web log lines in pretty 
quick order. :-D
-- 

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

Jon Foster
JF Possibilities, Inc.
jon at jfpossibilities.com
541-410-2760
Making computers work for you!