[fpc-pascal] FPC Graphics options?

[Ryan Joseph]

> On May 21, 2017, at 2:34 AM, Jonas Maebe <jonas at freepascal.org> wrote:
> The Pascal test program that was benchmarked here contains a number of bugs/wrong translations from the C code (some stem from the original version, another one was added):

Thanks for looking this over. I’m personally a little worried when I see this kind of thing because I don’t know the causes and how it affects my code. Despite all the noise I think we finally got down to bed rock though. Unfortunately as a person who doesn’t understand compilers well all I can conclude from this is to avoid floating point math in tight loops. That’s probably not accurate enough but that’s the only way I can understand it right now.

What I’m hearing is there are some bad C translations and some missing FPC features. Not sure what percent is translations and what is FPC but I think it’s mainly on the side of the compiler.

> 
> Then, there's one thing that can be done to optimize the Pascal version (after removing the bugs above):
> 1) Compile with SSE3 or higher, in particular because SSE3 can be used to implement trunc() with a single instruction (otherwise we pass via a helper that uses the x87 fpu, which moreover has to reconfigure it to change the rounding more and restore it afterwards). However, there does seem to be a bug in FPC 3.0.2 whereby compiling this program for -O2 -Cfsse3 causes it to crash, because then it loads data from an 8-byte aligned location on the stack. It works fine when compiled with trunk and -O2 -Cfsse3 though (at least for 64 bit).

I just compiled with ppcx64 3.1.1 (from 3.0.2) and went from 8fps to 22fps without optimizations and 28fpc with (I got some divide by zero errors but that’s just translations). What is that about? What changed?

Just curious, why isn’t -Cfsse3 always enabled in optimizations? It seems like we want this on always.

> 
> There's at least one minor twist of the classic "C compiler evaluates constant stuff at compile time":
> 1) oy and oz are constant. The "floor" function is a standard C library function, and hence C compilers know what it does and can evaluate it at compile time. Therefore, the oy-floor(oy) and oz-floor(oz) expressions are (equal) constants for C compilers.

How are those constants? I see them defined as "float oy = 32.5;” in the c version.


Regards,
	Ryan Joseph