21–30 of 156 posts
Pharo 3's results (JIT enabled VM) [(1 to: 100000000) sum] timeToRun 0:00:00:07.335 http://pharo.org Version 4 with new VM due in 2015. Will perform much much better as with the range used, we need to use LargeIntegers as the 32 bit VM must promote to LargeInteger objects. With the 64bit VM, all fits in.
> pypy -mtimeit 'sum(xrange(1, 100000001))'
10 loops, best of 3: 153 msec per loop
Short answer: because it doesn't JIT
http://blog.reverberate.org/2014/10/the-overhead-of-abstract...
I vastly prefer to use tools which don't come misshapen out of the box, personally.
> 2. Python is interpreted rather than compiled. Can we stop saying things like this? Virtually all Python is compiled, as part of the interpretation process. There is a valid point here, of course. The point is that the top Python compilers do not compile to native code. So say that. Words have meanings. Use them correctly.
There are three primary methods of running code: interpretation, compilation to object code, and running on a VM/JIT. Obviously python is interpreted by any meaningful definition of interpretation and thus it is not compiled in the typically sense of the word (at least not in the implementation everyone uses). The reason human language is so expressive is because we can leave out a lot of context and formalism that i…
This is very different from Perl, where a line of code isn't parseable until you know the values of the variables, e.g.
whatever / 25 ; # / ; die "this dies!";Quite a few years ago I wrote a little Runge-Kutta solver in Perl for some simulation work. It seemed like a good idea at the time. The equations of motion had to be integrated over a very long time, and it could take hours for a single run (still much faster than the Monte Carlo it was being used to do a sanity-check on). I re-wrote everything in C++, and picked up less than a factor of two in speed.
So it isn't that "Python is interpreted" that is the problem, because "Perl is interpreted" in exactly the same way. It really does seem to come down to the Python object model. Perl's scalar types have vastly less overhead, so much so that you can actually do reasonably efficient numerical computation in it.
I abandoned Perl for Python shortly thereafter because once I got over the "oh my god it's full of whitespace" thing Python was just more fun to code in, but the speed that Perl provided is something I've definitely missed, and it was a real awakening to the notion that interpreted languages don't have to be slow. The striking thing was that unlike Java (say) where it can be fast but you generally have to think about it, I was getting fast Perl without even really trying.
Another reason python is slower than other languages is that abstraction adds significant overhead which most implementations cannot optimize away. See here: http://blog.reverberate.org/2014/10/the-overhead-of-abstract...
Short answer: because it doesn't JIT
That's a lossy short answer. LuaJIT with JIT turned off still runs circles around CPython.
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
Another reason python is slower than other languages is that abstraction adds significant overhead which most implementations cannot optimize away. See here: http://blog.reverberate.org/2014/10/the-overhead-of-abstract...
The overhead of abstraction...unless you're using Haskell where typeclass instances get specialized, so you can abstract without slowing things down.