5 ms·

So is the goal to gain resources by becoming part of CPython? It seems like the small performance increases they got are completely overshadowed by the addition

So is the goal to gain resources by becoming part of CPython? It seems like the small performance increases they got are completely overshadowed by the additional memory requirements. I don't pretend to understand the mainline Python development cycle, but this surely doesn't seem mature enough to justify declaring it as "the way forward".

jmatt 17y ago
Ya I noticed that too. I'd love to have some performance benefits from JIT too but not at those costs. 2.43x - 2.76x increase in memory to Django[1]. Ugh. That's a large enough change that I'd have to upgrade hardware. Come on now. [1] http://www.python.org/dev/peps/pep-3146/#memory-usage http://www.python.org/dev/peps/pep-3146/#memory-usage
- alecthomas 17y ago
  From TFA "We view reducing memory usage as a blocking issue for final merger into the py3k branch. "
  - algorias 17y ago
    So, you'd accept unladen as the official JIT based on the vague promise of improving its glaring issues sometime in the future? Does that give it the right to be in a "blessed" repo? I propose my own python implementation for acceptance into the source tree. Right now, it's a single empty file (but I've got lots of ideas!). I'll even consider it a blocking issue if it achieves less than 10x speedup using half as much memory.
  - IgorPartola 17y ago
    Down further they say something about how they'll ask the community what the acceptable memory usage increase will be. In other words, they might reduce it by say 15%, but not anywhere near the JIT-less levels, and call it a day. I suppose you always have the option to compile python as --without-jit...
- wisty 17y ago
  Extra memory means a longer start-up time (for small apps) ala JVM, and makes hosting much more expensive. Lots of web hosts are memory / IO bound, not CPU bound. And you are sacrificing memcache size for python speed if you increase python's footprint - not always a winner.
- ubernostrum 17y ago
  Well, they've still got at least a year or so to work on it, since it's unlikely Django will be running on Python 3 before then...

jmatt 17y ago

Ya I noticed that too. I'd love to have some performance benefits from JIT too but not at those costs. 2.43x - 2.76x increase in memory to Django[1]. Ugh. That's a large enough change that I'd have to upgrade hardware. Come on now. [1] http://www.python.org/dev/peps/pep-3146/#memory-usage http://www.python.org/dev/peps/pep-3146/#memory-usage

alecthomas 17y ago
From TFA "We view reducing memory usage as a blocking issue for final merger into the py3k branch. "
- algorias 17y ago
  So, you'd accept unladen as the official JIT based on the vague promise of improving its glaring issues sometime in the future? Does that give it the right to be in a "blessed" repo? I propose my own python implementation for acceptance into the source tree. Right now, it's a single empty file (but I've got lots of ideas!). I'll even consider it a blocking issue if it achieves less than 10x speedup using half as much memory.
- IgorPartola 17y ago
  Down further they say something about how they'll ask the community what the acceptable memory usage increase will be. In other words, they might reduce it by say 15%, but not anywhere near the JIT-less levels, and call it a day. I suppose you always have the option to compile python as --without-jit...
wisty 17y ago
Extra memory means a longer start-up time (for small apps) ala JVM, and makes hosting much more expensive. Lots of web hosts are memory / IO bound, not CPU bound. And you are sacrificing memcache size for python speed if you increase python's footprint - not always a winner.
ubernostrum 17y ago
Well, they've still got at least a year or so to work on it, since it's unlikely Django will be running on Python 3 before then...