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