Re: [fpc-pascal] FPC Graphics options?
On 2017-05-13 18:02, Jon Foster wrote: Speaking of Java ... that's a hard comparison to make. There are so many Java implementations. Doesn't IBM, Linux, FreeBSD etc use OpenJDK? I was also under the impression that Oracle now also uses OpenJDK as the base for their releases - with some of their own additions. If this is all correct, it means they all pretty much use the same Java VM and Compiler implementations. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
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
Re: [fpc-pascal] mssqlconn.ppu on darwin
On 13/05/17 16:05, Mattias Gaertner wrote: The unit mssqlconn is not compiled on FPC 3.0.2/3.0.3 on Darwin. Why? My policy for Darwin is to only compile units that have been tested by someone. Shipping a ton of untested units only because they compile mostly results in a lot of frustration with end-users, since they (rightfully) expect things to work if they are included. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] mssqlconn.ppu on darwin
Hi, The unit mssqlconn is not compiled on FPC 3.0.2/3.0.3 on Darwin. Why? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Size of program vs library ?
Hello. Sorry to come back with this story but there are (good) news. Using *--gc-sections* makes the library smartlinked. So the question is: Why FPC does not provide *--gc-sections* to the linker with the -XX paramer for libraries ? (Bug ?) Fre;D - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728548.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
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 ! 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. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
