[fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/12/2017 03:43 AM, Michael Schnell wrote:
> On 12.05.2017 01:57, Jon Foster wrote:
>>
>>  One of the last set of benchmarks I did that focused on integer math 
>> and procedure call speed came out as follows:
> Thanks for sharing !
You're welcome.
>> pascal:        2:09s - 2:12
>> js (JIT):      2:23s - 2:27
>> python:       36:43s - 37:02
>
> Funny that JS (Text) with JIT is so good, and that Python (binary 
> byte-code, also supposed to use a kind of JIT), is so bad.
>
As you can tell from the figures Python, at least v2.7.x as supplied with 
Deb7, does not perform any kind of native-code compilation. The performance 
hit of interpretation is unavoidable. Python does provide tools to 
byte-code compile into *.pyc or *.pyo files and attempts to do so 
automatically (if it has write perms). This removes the parsing step and is 
essentially what PHP "accelerators" (other than HipHop) do. Parsing can 
really add to "launch" time, which really hurts web app performance, since 
so little is accomplished with each invocation.

There is also "cython" which turns a variation of Python into C usable as a 
Python extension. But this is not an automatic process.

So to compare apples to apples you have to compare Python to the "JS 
(interp)" time. However interpreter bench marking is fraught with even more 
peril than compiler bench marking since so much of interpreter performance 
is based on what can be offloaded to the machine code parts. Something like 
a routine to XOR encode a string will be 100x (or more) faster if provided 
in a language construct or native-code backed method, rather than writing 
the same thing with the language itself. In fact this is one of the things 
that Python might suck at since it has immutable strings. You have to 
decompose it to a "list" of "characters", do the transform, then recompose 
it back to a string. This would hurt Java too as its string implementation 
is immutable as well.

Speaking of Java ... that's a hard comparison to make. There are so many 
Java implementations. Good performance with OpenJDK does not necessarily 
make good Android performance, or good performance using any other Java 
environment. Just at SpiderMonkey's JS times are not necessarily indicative 
of Google's V8. I should load NodeJS and try it out. :-) But I really don't 
care enough to. This is also why Google has been "silently" moving towards 
a compile-at-install-time methodology. About bloody time! I was looking for 
a way to do that in the mid '80s.

-- 
Sent from my Debian Linux laptop
Jon Foster
JF Possibilities, Inc.
jon at jfpossibilities.com