> On May 21, 2017, at 2:34 AM, Jonas Maebe <jo...@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
