6 ms·
Optimizing Python – A Case Study
- mangeletti 11y agoIsn't Jython not a JIT compiler, and isn't Jython much slower than cPython?
- makmanalp 11y agoIf you run Jython on the hotspot JVM, that'd count as JIT. As for the speed, I'm not sure.
- coldtea 11y agoNope and Nope. Jython is made to run on the HotSpot which is a JIT compiler, and Jython should be comparable to speed to cPython and faster in some cases (used to be slower, but that was 3-4 years ago, the optimized it a lot, and added stuff in Java 7/8 helped too). JRuby is faster than standard C Ruby too.
- DasIch 11y agoThere is a huge difference between an interpreter with a JIT compiler and an interpreter running on another interpreter that has one. These are not equivalent at all.
- coldtea 11y agoJython is not running on an interpreter. It IS an interpret itself, and it runs on a virtual machine that takes care of JIT compilation.
- DasIch 11y agoThe difference between a virtual machine and an interpreter being?
- coldtea 11y agoMostly orthogonal. You can have an interpreter without a virtual machine (Basic or Python doesn't have one, just a runtime), and similarly a virtual machine without an interpreter. An interpreter executes scripting instructions directly. A virtual machine implements a faux (virtualized) cpu, with its instruction set etc, and executes its "assembly code" (with or without JITing). (Things get complicated in that you can also have combinations of those concepts).
- ihm 11y agoPython in CPython is executed after being compiled to the lower-level Python bytecode. Is this not sufficient to consider CPython to involve a virtual machine?
- DasIch 11y agoAlmost all interpreters compile an ast to an "assembly code" that gets executed. CPython even executes that assembly code without seeing the source at all just like Java.
- paulfurtado 11y agoIn the JRuby case, JRuby compiles Ruby to JVM bytecode. Jython may do the same: rather than create cpython bytecode it may produce JVM bytecode which may be optimized by the JVM. However, I do not know anything about Jython performance and they could not be employing the same tactics as JRuby. With modern Java features like lambdas coming into java 7 and 8 and other interesting languages like Scala, Groovy, etc being written for the JVM I'm sure things have come a long way since the time jython 2.4 was being developed on Java 5/6 and I'm sure the JVM has many more optimizations that dynamic languages may benefit from.
- vorg 11y ago> other interesting languages like Scala, Groovy, etc being written for the JVM I think Clojure is one of the most interesting so I'm keen you include it in your minimal list of examples. I don't think Clojure actually uses the Java 7 "invoke dynamic" bytecode though.
- ehaliewicz2 11y agoJython compiles to JVM bytecode actually. That bytecode consists of a lot of calls to methods implemented in java though.
- fnord123 11y agoDo you have a source on the benchmark results suggesting that Jython is comparable to CPython speeds?
- wtetzner 11y agoWell, it runs on the JVM, so depending on which JVM you use, it might use a JIT compiler.
- deleted 11y ago[deleted]
- vosper 11y agoHe's missing Cython, which is another good option when you're looking for speed. My personal favourite optimisation, from needing to shave a few milliseconds off our API response times, was discovering that it's measurably slower to use * args and * *kwargs, and switching to explicitly declaring and passing arguments in the relevant parts of the code. We also did a few other neat things: - Rolled our own UUID-like generator in pure Python (I was surprised this helped, but the profiler doesn't lie) - Switched to working directly with WebOb Request and Response objects rather than using a framework - Used a background thread with a single slot queue to make sure our response was returned to the user before we emitted the event log message, but always emit the message before moving to the next request - Heavy optimisation of memcache / redis reads and writes Edit: Fixed formatting
- jMyles 11y ago- Used a background thread with a single slot queue to make sure our response was returned to the user before we emitted the event log message, but always emit the message before moving to the next request The crosstown_traffic API in hendrix does exactly this. https://github.com/hangarunderground/hendrix https://github.com/hangarunderground/hendrix
- clickok 11y agoSerious question: if you have some code that really has to be fast, is it viable to keep it in Python, or should you ultimately end up rewriting it in a compiled language? For example, I am writing code that implements networks that evolve over time for AI research. Prototyping it in Python makes it easy to test things out, but I expect that I will have to rewrite it in C++ or maybe something more fun, like Haskell[1]. 1. Mostly for the sheer joy of trolling my colleagues with a learning agent monad.
- p1esk 11y agoSame question to you: if you have some code that really has to be fast, is it viable to keep it in C++, or should you ultimately end up rewriting it for GPU?
- wallstop 11y agoIs this really a suitable counter-question? GPUs lend themselvse towards specific kinds of programming problems + added latency of GPU communication. On the contrary, the cost between switching from any on-CPU language is programmer time that may result in significant runtime advantages.
- vetinari 11y agoAlso disadvantages: increased programmer time for implementing new features. Risks: you might optimize the wrong part (i.e. you invest into rewrite, but it will not solve performance problems). That's why you must quantify advantages and disadvantages, including risks minimization and only then you'll see, whether given course of action is viable.
- jermy 11y agoYou should probably first consider seeing if there are critical bits of code that can be rewritten to use MMX/SSE instructions, since your data is in the right cache already, without needing to move it anywhere else.
- thezilch 11y ago
- aburan28 11y agoPythran is also missing
- accounthere 11y agoAs is Nuitka, but who keeps track of these things?
- sitkack 11y agoThe order of tactics to take is wrong. In terms of energy expended, one should use PyPy first! It is amazingly compatible with CPython and can now be embedded directly in CPython programs, https://github.com/fijal/jitpy https://github.com/fijal/jitpy (supports numpy arrays) Dump your virtualenv, create a new one with pypy, reinstall libraries and test your app. Takes less than 20 minutes, even for complex applications.
- ma2rten 11y agoExcept if you are using python 3 or numpy or any other library written in C.
- Veratyr 11y agoA lot (but definitely not all) of Numpy is actually Pypy compatible: http://buildbot.pypy.org/numpy-status/latest.html http://buildbot.pypy.org/numpy-status/latest.html
- riquito 11y agoIf you know that you can't us PyPy you can remove it from the list, otherwise sitkack has a point.
- sitkack 11y agoI have never used it, but PyPy3 is CPython3.2.5 compatible.
- lqdc13 11y agoFirst thing you should do is optimize data structures IMO. This is the advantage Python has over lower level languages - easy way to implement complicated things. Kind of like Linus's quote: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
- sitkack 11y agoI would say it is a close second thing. If I have a slow system, I will move to faster runtime before modifying any code. Going from CPython to PyPy, if possible will almost always gain you enough perf increase while you refactor the slow parts.
- pepijndevos 11y ago> Think for a second: time is only ever going to increase Well, most of the time at least. Think about DST and leap seconds.
- ryan_sb 11y agoTrue, but in this particular case, the cost to time going (temporarily) backwards would only be connecting to a potentially-suboptimal disque node, and that would be remedied after the subjective-machine-time caught up with the previous subjective time.