Why Python Is Slow: Looking Under the Hood
jakevdp.github.io
jakevdp.github.io
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.
Perl also has PDL (http://pdl.perl.org/), which is very similar in scope to numpy, but predates it by several years.
If you want to get technical, Numpy is a continuation of Numeric which in turn pre-dates pdl.
In microbenchmarks, Perl is 2-125x slower than C++: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
And Java is quite a bit faster than Perl too: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
Perl isn't really that fast. It's faster than Python in most cases, but gets beat by Lua pretty consistently: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
Doing a Perl-type problem in a general-purpose language would be considerably slower. However, Python or others will perform much better in the "can I read my own code six months later" benchmark.
It's true that unsupervised, weak coders using perl turn out worse code than in other languages. But it really doesn't take much to produce good code if you have a tiny bit of supervision/discipline (which stems mostly from 80% of perl tutorials on the web are teaching 1997-era perl anti-patterns). And/or if you happen to be a stronger programmer in something else, hopefully you stumble across perlcritic and modern perl patterns more quickly.
Well-written Moose code involves less boilerplate, the declarative nature and composability of classes, types and data members with free type/value validation is a delight to maintain, and results in more robust code with a lot fewer silent failures (or objects happily chugging along silently with invalid state) than typical Python classes.
Of course, now that I can't use Moose and the Python community actively seems to discourage the very thought of relying on any superset of core Python OO features like enthoughts' traits package - I really want to revisit static/stronger typed programming languages for large projects. So it feels like I've come full-circle in my programming career...
import rdstdin, strutils
let
time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt)
hours24 = time24[0]
minutes24 = time24[1]
flights: array[8, tuple[since: int,
depart: string,
arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."),
(583, "9:43 a.m.", "11:52 a.m."),
(679, "11:19 a.m.", "1:31 p.m."),
(767, "12:47 p.m.", "3:00 p.m."),
(840, "2:00 p.m.", "4:08 p.m."),
(945, "3:45 p.m.", "5:55 p.m."),
(1140, "7:00 p.m.", "9:20 p.m."),
(1305, "9:45 p.m.", "11:58 p.m.")]
proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int =
hours * 60 + minutes
proc cmpFlights(m = minutesSinceMidnight()): seq[int] =
result = newSeq[int](flights.len)
for i in 0 .. <flights.len:
result[i] = abs(m - flights[i].since)
proc getClosest(): int =
for k,v in cmpFlights():
if v == cmpFlights().min: return k
echo "Closest departure time is ", flights[getClosest()].depart,
", arriving at ", flights[getClosest()].arrive
Nim is pretty awesome and has been around for a while. I wish one of big entities out there Google, Mozilla, Microsoft, Apple would have adopted Nim and ran with it instead of inventing their own langauges.
For someone mainly in the Python/Java/C++ world is Moose something worth looking at as a mind expansion exercise? Your description makes it sound appealing.
And, dare I ask, what about Perl 6?
Roles/traits/method modifiers/MOP/composability etc. are all great things for getting more reusability... however (and this might sound stupid) the thing that saddens me most when writing Python code is when I find myself adding a bunch of asserts or adding program logic "manually" in situations where I'd normally specify that sort of thing declaratively in a Moose class definition or by referring to a centrally managed Type or delegate stuff through attribute features.
On the other hand, I'm barely into year 2 of full-time Python dev, so perhaps I've yet to find the idiomatic way of doing Python things I used to take for granted in Moose.
Regarding Perl 6, I don't know much about it, except that the original authors of Moose had some inspiration from it.
Is picking up Perl+Moose mind-expanding? It was for me, but I feel that what Moose gave me in Perl was a bit of a band-aid over the fact that it's such a malleable open-ended dynamic language. So as a C++/Java programmer this aspect might not be so enlightening to you, except to see how Moose achieves it in a pretty painless way that I think is very nice and idiomatic for a dynamic language (with the caveats that brings). To put it another way: it gives Perl some of the great benefits of properly declaring things up-front, without the boilerplate/inflexibility pain that I perceive the Java ecosystem's bureaucracy to be (I haven't touched Java for 10 years, so take that with a grain of salt).
If you want to explore some Moose-ish kinds of things within Python, check out [4] (there's another Moose clone in Python that's similarly inactive, sadly) and [5] (Enthought's stuff is perhaps a bit too heavy and incomplete to be the "Moose of the python world", but it gives you a good idea of some of the nice patterns possible when you think outside of the core Python OO featureset).
[1] http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod [2] http://radar.oreilly.com/2014/01/horizontal-reuse-an-alterna... [3] http://modernperlbooks.com/mt/2009/05/perl-roles-versus-inte... [4] https://github.com/frasertweedale/elk [5] http://code.enthought.com/projects/traits/
I definitely have a preference for a more declarative approach, and not in the J2EE giant piles of XML way. Will give these a look for inspiration - thanks again!
As an ardent Perl lover, I asked this question myself. Shameless self-promotion yada yada :
http://www.infoq.com/news/2014/08/python-type-annotation-pro...
https://mail.python.org/pipermail/python-ideas/2014-August/0...
https://docs.python.org/3/tutorial/controlflow.html#function...
I think it's a matter of what you're comparing it to.
Compared to using Perl for a general-purpose problem, Perl for scanning/parsing is fast.
Compared to scanning/parsing with C, Perl is not fast.
$ ruby -e '1.upto(1000000) { |n| puts "This is line number #{n}" }' > file
$ time perl -ne 'print if /number 12345/' < file
[...]
real 0m0.193s
user 0m0.189s
sys 0m0.004s
$ time grep "number 12345" file
[...]
real 0m0.023s
user 0m0.019s
sys 0m0.005s
Note: these test runs are from Linux. On OS X the Perl results were almost the same, but "grep" was unexplainably way slower. It seems to hang after it's already dumped all of its output. Basically grep on OS X appears to be badly broken somehow.
And these one-time/rare/short jobs are much more frequent than intense, high throughput C code like the nginix web server or the node javascript interpreter.
I might have some bias though from speeding up a crusty old Perl CGI web apps with multi-second request times down to less than 100ms simply by keeping the perl processes persistent with mod_fcgid or whatever.
I increased the iteration count by 10x and observed exactly the same pattern:
$ time perl -ne 'print if /number 12345/' < file
[...]
real 0m1.661s
user 0m1.586s
sys 0m0.076s
$ time grep "number 12345" file
[...]
real 0m0.188s
user 0m0.132s
sys 0m0.056sI see very similar results between Perl and grep, and you can see this by also including egrep, which allows slightly more complex expressions:
[root@stats ~]# time perl -ne 'print if /number 123456/' < /tmp/file
[...]
real 0m1.990s
user 0m1.937s
sys 0m0.049s
[root@stats ~]# time grep "number 123456" /tmp/file
[...]
real 0m0.158s
user 0m0.115s
sys 0m0.035s
[root@stats ~]# time egrep "number 123456" /tmp/file
[...]
real 0m0.150s
user 0m0.127s
sys 0m0.023s
[root@stats ~]# time perl -ne 'print if /number [1]23456/' < /tmp/file
[...]
real 0m1.989s
user 0m1.925s
sys 0m0.047s
[root@stats ~]# time grep "number [1]23456" /tmp/file
[...]
real 0m1.402s
user 0m1.366s
sys 0m0.022s
[root@stats ~]# time egrep "number [1]23456" /tmp/file
[...]
real 0m1.414s
user 0m1.382s
sys 0m0.031s
[root@stats ~]# time perl -ne 'print if /number [1]23456[0-9]*/' < /tmp/file
[...]
real 0m1.950s
user 0m1.910s
sys 0m0.039s
[root@stats ~]# time grep "number [1]23456[0-9]*" /tmp/file
[...]
real 0m9.353s
user 0m9.307s
sys 0m0.037s
[root@stats ~]# time egrep "number [1]23456[0-9]*" /tmp/file
[...]
real 0m9.539s
user 0m9.483s
sys 0m0.045s
Anecdata: I needed to process a large amount of XML a while back, to the point where a week spent testing and optimizing XML parsing libraries in Perl was worth it, because it could shave weeks or months off the processing time. The winner? A regex that captured attributes and content and assigned name/value pairs directly out to a hash. This was only possible because the XML was highly normalized, but it was actually over 10 times faster than the closest competitor for XML parsing I could fine, and I checked all the libXML libXML2, and SAX libraries I could get my hands on.
In the end, it was something as simple as the following approximation:
while (my ($doc) = $xml =~ /$get_record_xml_re/) {
my %hash = $get_record_xml =~ /$record_begin_re$capture_name_and_value_pairs_re$record_end_re/;
process_record( \%hash );
}But the original benchmark was ridiculously biased in favor of Perl by not actually doing anything in Perl.
If Perl is actually being competitive in the unfair benchmark, the benchmark should be made more fair by actually putting some logic in Perl, and writing the equivalent logic in C. At that point, you would start to see C win again (modulo any inherent inefficiencies in grep's regex engine).
> This was only possible because the XML was highly normalized
Another way of putting this is: your regex wasn't actually an XML parser. Things that are actually XML parsers were slower. This is not too surprising.
A 10x slowdown does surprise me somewhat. It doesn't surprise me that you beat libXML or any library that builds the XML structure into a complete DOM before you can process the first record. It does surprise me that you beat SAX by 10x. SAX does have some inefficiency built in, like how it turns attributes into a dictionary internally before giving them to the application. That would probably mean that SAX bindings for Perl to a C parser would have to take a full SAX attribute hash and turn it into a Perl attribute hash. Still, 10x is pretty bad.
I really do think it has to do with grep swapping out regex implementations based on features needed. The last regex matches a variable length string, so it may trigger a much more complex and/or cpu-intensive regex engine to be used.
> If Perl is actually being competitive in the unfair benchmark, the benchmark should be made more fair by actually putting some logic in Perl, and writing the equivalent logic in C. At that point, you would start to see C win again (modulo any inherent inefficiencies in grep's regex engine).
I see your point, but I think it's less relevant than you suppose. Regular expressions are first class citizens in Perl, just as much as Arrays and Hashes. This doesn't just mean that the syntax has some niceties, but you can actually call Perl code within the regex itself[1], and even use this feature to build a more complex regular expression as you parse[2]. Complaining that Perl uses a regex and it isn't Perl is sort of like complaining Perl is using hashes, and any fair benchmark between C and Perl should just stick to Arrays.
> Another way of putting this is: your regex wasn't actually an XML parser. Things that are actually XML parsers were slower. This is not too surprising.
Yes. I didn't want to give the impression a wrote a general purpose XML parser that beat all the C implementations I could find. I still think it's interesting that well formed regular expressions are performant enough in this circumstance to make them a preferred alternative of the many options. I could have written a simple parser in C that would have been faster, but the solution I ended up with is quite fast, robust, and very, very easy to debug.
> That would probably mean that SAX bindings for Perl to a C parser would have to take a full SAX attribute hash and turn it into a Perl attribute hash. Still, 10x is pretty bad.
I think it's more related to the fact that the actions of the regex parsing implementation when optimized sufficiently is very close in implementation to C code that steps through a char array looking for the record beginning and ending indicators, and for the content between them, and then steps through the record looking for data items and saving the key and value for each. The main benefit of using a regex in Perl is that I get what is probably a fairly close approximation (all things considered) of a C implementation of that without having to write any C, and without having to marshal data back and forth to a library to accomplish it, with very simple and concise code.
There are other tasks which obviously aren't going to be nearly as efficient in Perl, but this exchange was spurred by someone talking about Perl being very fast for a Perl-type problem, which this definitely is.
That wouldn't explain why one regex engine is 5x faster than another. Only looking at the regex engines themselves would tell you that.
> Complaining that Perl uses a regex and it isn't Perl
I'm not complaining that it uses a regex, I'm complaining that it doesn't do anything else.
A representative Perl program would use regexes and contain some logic that processes the results of those regexes.
> I think it's more related to the fact that the actions of the regex parsing implementation when optimized sufficiently is very close in implementation to C code that steps through a char array
I used to think that, but it is really not true unless your regex engine contains a JIT compiler.
Specialized machine code for a text parser (which is what you would get from writing C) is significantly faster than generic NFA/DFA code. In these tests, an average of 65% of runtime was saved when the regex engine included a JIT (ie. the specialized code was over twice as fast): http://sljit.sourceforge.net/pcre.html
It could definitely explain it, but it may not be the best explanation given the facts. I'll definitely concede that it's pure conjecture.
> A representative Perl program would use regexes and contain some logic that processes the results of those regexes.
Sure, depending on what you want to show. Nobody is trying to say Perl is as fast or faster than C, just that relatively, it's fast for the development cost it requires.
>> I think it's more related to the fact that the actions of the regex parsing implementation when optimized sufficiently is very close in implementation to C code that steps through a char array > I used to think that, but it is really not true unless your regex engine contains a JIT compiler.
I think we're referring to different things, which is mostly my fault for being loose with my terminology. I really only meant close to C in a conceptual manner, which yields some performance benefit by keeping a large chunk of the looping and work storing specific chunks of text low level and in the interpreter. I wasn't trying to imply the regex engine's cost was negligible or the actual machine operations we comparable in a large way.
> I used to think that, but it is really not true unless your regex engine contains a JIT compiler.
The P6 Rules engine is written in NQP so it gets JIT'd on the JVM and MoarVM backends.
Of course it'll be many years before the engine is seriously optimized but it's a good start.
It'll be interesting to see if the code gen of this next gen regexen engine gets good enough in 2015 to make its advantages (most notably the grapheme-by-default design) actually pay dividends.
When I write in python, this always triggers my mental slogan "python, the language which makes 'nothing' important".
This is said with a trace of irony, as my most fluent language is bash scripting :)
Easy answer: it's not. On most benchmarks it's on par with Python, PHP, Ruby, etc, some are faster on one, others on some other test.
>once I got over the "oh my god it's full of whitespace" thing
What full of whitespace? Python has as much (or as little) whitespace as normally intended Perl, Ruby, C, etc.
What it has that they don't have is significant whitespace.
Some things perl does under the hood to be fast are that integers are (mostly) actually integers under the hood. Arrays are actually arrays under the hood (a fact that makes perl's DBI very fast). And more importantly it has had decades of people trying to make it faster without changing the (sometimes crazy) semantics of the language.
But of course languages with JITs a have massively overtaken it in the performance stakes (PyPy, LuaJIT, and JavaScript). Mostly I think this is a result of lack of funding and huge company spending. Just look at what Facebook have managed to do with PHP.
Is not. We tested our own code in Perl for doing some text processing in our company.
The result was 89 times slower than our c code, which is not so slow compared with other options, but is slow.
We use a lot of c++ and python, but always for managing encapsulated low level code.
With anything that has to compute intensely, like audio, video or 3d work, the differences are way over 3000 times slower. That is: the computer working for a second or for an hour.
Java is not fast, it has never been. It is not its "forte". You could decide to use java or any high level languages based on its merits, but being fast is not one of them.
It is a good idea to learn assembly and disassembly with the debugger before using high level languages. It gives you the knowledge of what computers are really doing under the hood.
Don't think it has been mentioned in the other comments, but this could also be a performance problem with your C++ code - possibly in combination with doing something Perl is good at
The seminal paper about efficient dynamic interpreters is Ertl's "The Structure and Performance of Efficient Interpreters" http://www.complang.tuwien.ac.at/papers/ertl%26gregg03jilp.p...
The abstract is: "Interpreters designed for high general-purpose performance typically perform a large number of indirect branches (3.2%–13% of all executed instructions in our benchmarks). These branches consume more than half of the run-time in a number of configurations we simulated. We evaluate how accurate various existing and proposed branch prediction schemes are on a number of interpreters, how the mispredictions affect the performance of the interpreters and how two different interpreter implementation techniques perform with various branch predictors. We also suggest various ways in which hardware designers, C compiler writers, and interpreter writers can improve the performance of interpreters."
My own input to this is that the GC, the JIT, the calling convention and esp. the size of the datastructures and ops do matter more, than eliminating the type checks.
Better learn about the JavaScript framework of the day.
The paper fails to define the concept of what to call an Interpreter. A bytecode interpreter is entirely different from a Lisp interpreter, which actually runs from source structures. Mixing VMs into the picture makes it only worse.
Part of the reason may be that they don't understand what an Interpreter actually provides and why it is used.
Consider a C extension which takes an object and appends it to a list. If small integers did not have a refcount then that extension would have to have special code, like "if object is not a small integer, then increment the reference count".
"Objects with IDs between 0 and 2055, inclusive, are considered unreleasable. The Python runtime shall initialize the refcount of these objects to 1 when they are first used, and shall make no guarantee that the refcount on such objects accurately reflects the true number of references to that object. Native extensions may increase and decrease the refcount on these objects as if they were normal objects; if those extensions are well-behaved, then the refcount should never decrease below 1. However, native extensions that can statically reason about whether an object is likely to be unreleasable, may benefit in performance by checking for whether objects passed to their functions are indeed unreleasable, and refraining from modifying or checking their refcount in such cases."
Nor is there much advantage. We know that more advanced implementations can look at program flow and determine that, say, certain operations are only integer based, and therefore unboxable. Or tracing systems can assume that certain types are constant over multiple calls to the same code, and write optimized versions for those types.
These gives much better (eg, >5x according PyPy) optimizations over the error prone change that you believe might be faster.
> If small integers did not have a refcount then that extension would have to have special code, like "if object is not a small integer, then increment the reference count".
Easily implemented in one place in the "increment_refcount(obj)" inline function:
// roughly speaking
if (is_heap_pointer(obj))
obj->refcount++;
(((unsigned int) obj) & TAG_MASK) == TAG_PTR)
In a garbage collection implementation, you don't have refcounts, but the garbage collector's "mark object" function does the same check:
if (!is_heap_pointer(obj))
return; // don't try to mark non-heap things
switch (type(obj)) {
case TYPE_CONS_CELL
mark_obj(obj->cons.car);
mark_obj(obj->cons.cdr);
break;
// ...
}
value n = number(42);
value z = number(INT_MAX);
So in the first case you get an object with no refcount, whereas in the second you get an object with a refcount of 1. The extension code is written such that it doesn't care.
See https://mail.python.org/pipermail/python-dev/2004-July/04614... .
I just realized though that since the patch to support tagged integers is small, a closed system like the CCP Games distribution of Python, which has no extensions they don't control, might be able to use this idea.
This isn't so bad on memory either, since Python keeps a static cache of integers that are reused on every int constructor call. Also allowing for slack, I wouldn't be surprised if the machine word came for free.
This is essentially why a JIT can be almost as fast as compiled code even when including the necessary guards. It's only when the branches become unpredictable that the costs become real. The trick with fast interpreted code is threading the execution so that the hardware is able to predict the branches accurately, but this is largely independent of the number of conditional branches.
if (number < -5 || number > 256) {
decrement_refcount(number);
}1. everything's a hash (object data, variable lookup, etc). jmoiron wrote a great article on the topic http://jmoiron.net/blog/whats-going-on/
2. refcounting introduces overhead for every variable access
3. loops are making all kinds of function calls to __iter__, next(), and catching StopIteration, which makes it hard to have a tight loop.
4. There's the GIL, builtin locking isn't great.
5. lots of indirection (lack of value types)
(do a little research...you might be pleasantly surprised)
If I'm doing something like counting from 1 to 10 and summing the count, why can't this be compiled to run the same speed as C?
Obviously since it's interpreted, but when I'm done with development, why can't I just run it through a compiler to get fast assembly code?
Way back when, you could get a BASIC compiler to turn your interpreted BASIC code into assembly.
What fundamental am I missing?
It provides facilities for all of python abilities regardless of what the program is going to do.
Now, there are subsets of python people have developed that can be compiled and all sorts of other stuff.
Beyond that, I'd just say "all this stuff sounds easy but gets much harder when you actually have to program it".
"Why can't it just know!" is the programmer's lament.
Consider how many people end up implement their own introspectable C object models.
I believe that some code paths critical for performance in Rails use metaprogramming, for example.
I did an experiment in this paper http://dl.acm.org/citation.cfm?id=2647517&dl=ACM&coll=DL&CFI... where I showed that just be rearranging some code you can confuse the Rubinius object allocator into using a slow path for instance variables. That gives you both slow performance, and worse than that, unpredictable performance - the programmer doesn't understand what they've done wrong to trigger that fallback performance.
But things get much more complex very fast, and then the compiler requires the programmer to tell it what types things are.
Then there is the approach taken by JavaScript engines like V8. Run the code for a while, see what the types of variables are, then compile a customized, much more efficient version of the code to speed things up. Still need a fallback, though, in case a totally different kind of value gets stuck in a variable than the type at the time the optimized code was generated. Nothing in JavaScript (or Python) prevents a programmer from assigning any kind of value into a variable, though, so the engine must be prepared for the types of variables to change in unexpected ways.
(The reason the state of the art for these techniques is in the JavaScript engines is because the organizations behind the major browsers pour so many resources into making them fast.)
Now, if you can figure out a way to always predict the types of every variable in a JavaScript or Python program without actually running it, pretty much any CS program would be willing to give you a tenured position on their faculty on the spot. :)
If you declare a virtual function inline, if it is invoked from a well defined object (ie, not through a reference or pointer) you also get a similar effect while still being able to override, except the code is not a static call but is just inlined with that one implementation of the function.
You just need to use profile guided optimisation.
You certainly can compile languages this dynamic, the problem is that the "simple" way of compiling it doesn't result in very fast code, because you essentially end up mimicking what the interpreters/vms do very closely, and a lot of what ends up being executed will be things like method lookups which are reasonably well optimized in the interpreters.
The problem boils down to the ability to "change the world" at almost any point.
E.g. in Ruby (don't know about Python), you can come back from an eval() call (or load or require) and find that the expression 1 + 1.0 results in the string "two", or will send you an insulting e-mail, because you can even override Fixnum#+.
Now, there's a lot that can be done to infer typing for these types of languages well enough that you can get away with slow-path fallbacks for the rare cases where users does something stupid (like override Fixnum#+) and run faster most of the time, but it's a lot of extra effort.
The short version is "no, it shouldn't".
The longer version is that, viewing Python's runtime class memberships as "types", the type system it would represent is not one for which inference without explicit declarations is generally decidable, so an AOT compiler for unmodified, unrestricted Python that is expected to infer types at runtime simply would not be possible.
You could AOT compile it into C code with a lot of runtime metadata and indirections -- but that would probably have worse performance than the existing interpreter.
> Way back when, you could get a BASIC compiler to turn your interpreted BASIC code into assembly.
Well, yeah, BASIC is actually structurally quite close to assembly. Its not a dynamically-typed multiparadigm language like Python.
Its actually quite easy to be worse than an interpreter that is actually a combination of a bytecode compiler and a VM built around the execution model of the language it is for, which is what the main Python interpreter is.
Read input from a file or stdin. Eval that input. What type does it return?
Etc.
http://blog.reverberate.org/2014/10/the-overhead-of-abstract...
I like the tricky one they're kicking around that would make `lens` faster. Pretty intriguing. I'm hopeful they'll be able to make it work in STG.
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
Sort of.
The article talks about why CPython, an implementation of the Python language, is slow. You're right that a naive implementation of Javascript would have many of the same problems, and indeed many of the first implementations of JS did have these problems. But due to heated competition, Mozilla, Google, Apple, and Microsoft have invested a huge amount of top-quality engineer-years into optimizing their implementations of JS.
Implementations of Python, in contrast -- and CPython in particular -- have not received the same sort of love.
I largely agree with the notion that the speed of modern JS engines serves as an existence proof that Python could be similarly fast.
What's easy to lose track of under the steady stream of headlines about this microbenchmark going 5x faster and that microbenchmark going 10x faster and this one microbenchmark being "faster than C" is that Javascript is still a fairly slow language, though. Flick that to compare Javascript vs. C: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
It has come a long way. It is, of course, still usable for many things. But it is still an interpreted language, and my guess is that we've basically plateaued on performance for Javascript, and it's important to remember that it isn't as "fast as C" in any useful sense of the term. And for that matter, to get even that performance out of JS seems to require you to write a very specialized subset of JS that will tickle the optimizers correctly. In practice I suspect you will get even worse deltas over C, which, for all of its many failure modes, does make it often easier to do the fast thing than the slow thing, usually regardless of the correctness of either of them.
(That's why we have asm.js, after all. You can't have both of "Javascript is as fast as C" and "asm.js is several times faster than Javascript", because the composition of both statements is absurd.)
This is at least 6 months old.
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. <grumble, grumble>
Nowadays it's the norm for interpreted languages to be JIT-compiled. They still universally call themselves interpreted languages because the jitter is an implementation detail, and the use of one does nothing to negate the characteristics they're trying to advertise when describing themselves as interpreted languages.
Think of it this way: Can I take a text file containing source code in the language and execute it anywhere that has a special program for executing files written in that language (commonly known as an interpreter)? Or do I have to manually perform an intermediate step of converting the program to some binary representation using a special program for doing that (commonly known as a compiler), and then execute the output that program produces?
The incremental nature of a compiler, then does not make it that we would call it an Interpreter. We would call it an incremental compiler. That's a compiler, which can compile all expression, regardless of the size of the expression, not just 'whole programs'.
Why not? I would.
> Nobody there would call them interpreter because of that.
The following is Clozure Common Lisp. Every single input is compiled directly to machine code. Feed it source text and everything is compiled. Each and every expression.
Why should I call a direct native code compiler an 'Interpreter'? Makes no sense.
? (let ((f (lambda (a)
(+ 1 a))))
(disassemble f)
(funcall f 2))
;;; (lambda (a) (+ 1 a))
L0
(leaq (@ (:^ L0) (% rip)) (% fn)) ; [0]
(cmpl ($ 8) (% nargs)) ; [7]
(jne L57) ; [10]
(pushq (% rbp)) ; [12]
(movq (% rsp) (% rbp)) ; [13]
(pushq (% arg_z)) ; [16]
;;; (+ 1 a)
(leaveq) ; [17]
(testb ($ 7) (% arg_z.b)) ; [18]
(jne L39) ; [22]
(addq ($ 8) (% arg_z)) ; [24]
(jo L32) ; [28]
(repz)
(retq) ; [30]
L32
(jmpq (@ .SPFIX-OVERFLOW)) ; [32]
L39
(movl ($ 8) (% arg_y.l)) ; [39]
(jmpq (@ .SPBUILTIN-PLUS)) ; [44]
;;; #<no source text>
L57
(uuo-error-wrong-number-of-args) ; [57]
3 ; resultTraditionally, the twain ne'er did meet. However, many (most?) modern interpreters include a compiler as part of their implementation. Using a compiler in this manner is "Just in Time" (JIT) compilation.
So a box that takes Clozure Common Lisp and converts it to machine code is a compiler.
A box that takes Clozure Common Lisp, feeds it into this compiler to obtain machine code, and executes this machine code immediately, is an interpreter, using JIT compilation to do its interpretation.
The interpreter executes that language, not another.
> A box that takes Clozure Common Lisp, feeds it into this compiler to obtain machine code, and executes this machine code immediately, is an interpreter, using JIT compilation to do its interpretation.
It's neither an interpreter not using JIT compilation. It's an AOT compiler. It's just an incremental compiler.
The reason human language is so expressive is because we can leave out a lot of context and formalism that is required in mathematics and programming languages because the listener/reader will be able to infer it. It's pedantic to expect a writer to hedge against every possible interpretation, when their focus should be on communicating clearly in the first place.
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!";Perl is crazy, but I don't think it's that crazy.
From perlcompile(http://perldoc.perl.org/5.8.9/perlcompile.html)
Perl has always had a compiler: your source is compiled
into an internal form (a parse tree) which is then optimized
before being run.
I could not get your code sample to die based on the type/value of "whatever" -- can you?
Basically, you can't always parse a Perl program without running it. There is a subset that you can, not not everything.
That is true, but what the grandparent said is not: https://news.ycombinator.com/item?id=8626454
To expand on this, I think a succinct way of summarizing the issue is: you might have to run BEGIN blocks in Perl to parse the non-BEGIN-block part of the program. The canonical example of this is:
BEGIN {
if(arbitrary_function()) {
eval "sub whatever() { }; 1" or die $@;
} else {
eval "sub whatever { }; 1" or die $@;
}
}
# The parsing of this line depends on the result of arbitrary_function()
whatever / 25 ; # / ; die "this dies!";
Because CPython implements its virtual machine with an interpreter, without the option of, say, a JIT compiler.
[13:06:36] ~$perl -e 'whatever / 25 ; die "this dies!";'
this dies! at -e line 1.
[13:06:36] ~$
[13:06:38] ~$perl -e "use strict; use warnings; whatever / 25 ; die "this dies!";"
Useless use of division (/) in void context at -e line 1.
Bareword "whatever" not allowed while "strict subs" in use at -e line 1.
Execution of -e aborted due to compilation errors.
[13:06:38] ~$
Our discipline (computer programming) is, perhaps more than any other, one in which precision of meaning is of paramount importance. I expect people to hedge. Especially when it's easy: "Python is not usually compiled to native code."
In any case, since Python is virtually always compiled, saying it's not is simply false. That's hardly clear communication, I think.
> Obviously python is interpreted by any meaningful definition of interpretation ....
Now, here I'm not sure what you mean. You've already distinguished interpretation from Just-In-Time compilation to Virtual Machine code. Since the latter is pretty much always what happens with Python, would you then say that Python is not interepreted? (Serious question!)
Me, I don't have a problem with these concepts overlapping (and I don't see why many people do). Python is interpreted. The usual mechanism for this is JIT compilation to virtual-machine code, which is then -- in the case of CPython -- interpreted as-is. In contrast, something like "C" is traditionally Ahead-Of-Time (AOT) compiled to native code. Interpreted: no. Compiled: yes. And then there are languages whose interpreters do not involve a compilation step -- although they are becoming rare.
"just write a C extension"
"but then why use Python?"
Squeezing performance out of Python often involves dropping down to C. This isn't the case with the competition.
"it's slow"
"just write a C extension"
"but then why use Python?"
This is the same kind of network effect that drove Perl usage for some many years. CPAN had it. Even if I didn't want to use Perl, CPAN was overwhelmingly compelling.
Python has since taken on that mantle.
Dynamic typing can often be optimized at the compilation stage - and yes, Python has a compilation stage - this particular example is basic type inference, for example. Even more complex examples can be optimized by emitting specialized versions for the types that the compiler can see it will be called with. Effectively emitting specialized versions of specific nodes in the control flow graph.
There are a number of design decision in python language that makes it inherently hard to write a fast python implementation.
There are lots of languages where variables are dynamically typed that can be compiled and optimized with a JIT compiler. In Python, though, any code can mess with any data, using "setattr". You can find all the variables in another module and mess with them at run time, using their names as strings. At compile time, the compiler can't detect that's going to happen.
This is sometimes called the Guido von Rossum Memorial Boat Anchor.
So Python implementations usually have to assume the worst case. Google's attempt at a faster, compatible Python, "Unladen Swallow", was an embarrassing failure. PyPy manages to get past that, but at a huge cost in JIT compiler complexity. After 12 years of work, PyPy is finally shipping stable versions and starting to get some use. It's been all uphill for the PyPy developers, though.
It's kind of sad. Python never achieved its full potential because of the speed problem. Google ended up developing Go because Python was too slow.
Python provides significantly more hooks into the behaviour of arbitrary objects, and arguably provides more flexibility than JS.
Here are a few notes from Mike Pall (LuaJIT) on Python features making a straight interpreter slower, and the language harder to optimise (JIT tightly): http://lua-users.org/lists/lua-l/2004-11/msg00083.html
Animats is full of shit, the ability to add arbitrary "static" attributes to existing objects is really not the main problem.
However certain language features can be inherently difficult to optimize. Most of it's over my head, but headius has written some great articles as part of his experience of implementing ruby on the jvm. http://blog.headius.com/2012/09/avoiding-hash-lookups-in-rub...
[(1 to: 100000000) sum] timeToRun 0:00:00:07.335
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
http://clementbera.wordpress.com/2013/06/19/optimizing-pharo...
You can't interface with the existing SciPy ecosystem which expects the CPython API, which is the reason why pypy doesn't matter in scientific computing.
[0] inspired by LuaJIT and usable from both CPython and PyPy: https://cffi.readthedocs.org/en/release-0.8/
Does anyone else have some good bits or blog entries on these sorts of inner workings and optimizations?
I can't see why anyone would go and mess with CPython's internals like that in production code. Other than for nefarious purposes, I guess.
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
I think these questions are more to the point: Were the Python programmers as skilled as the Lua programmers? Do the programs do anything like the things your programs do?
So, with element of answer 1) ruled out as Lua is also dynamic, and 2) ruled out by your evidence, remains
3. Python's object model can lead to inefficient memory access
2. And in that context (and most others), the difference between Perl, PHP and CPython is basically non-existent, you might get 2x on one bench, half on the other
I vastly prefer to use tools which don't come misshapen out of the box, personally.