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.
j...@jfpossibilities.com
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
