Re: [Python-ideas] Optimizing builtins
On Sat, Jan 1, 2011 at 5:11 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
Right. That's a much saner solution than trying to generate bulky bytecode as Cesare proposed. The advantage of a JIT is also that it allows doing these optimizations only in those places where it matters. In general I am not much in favor of trying to optimize Python's bytecode. I prefer the bytecode to be dead simple. This probably makes it an easy target for CS majors interested in code generation, and it probably is a great exercise trying to do something like that, but let's please not confuse that with actual speed improvements to Python -- those come from careful observation (& instrumentation) of real programs, not from looking at toy bytecode samples. (Most of the bytecode improvements that actually made a difference were done in the first 5 years of Python's existence.)
Great observation! -- --Guido van Rossum (python.org/~guido)
On 1/1/2011 11:41 AM, Guido van Rossum wrote:
In general I am not much in favor of trying to optimize Python's bytecode. I prefer the bytecode to be dead simple.
I think people constantly underestimate the virtue of Python and CPython simplicity. Projects that depend on a couple of genius ubergeeks die when the ubergeeks leave. The executable-pseudocode simplicity of the language makes it a favorite for scientific programming, spilling over into financial programming. The simplicity of the code allows competent students (and non-CS major adults) become developers. -- Terry Jan Reedy
On Sat, Jan 1, 2011 at 12:30 PM, Terry Reedy <tjreedy@udel.edu> wrote:
And, of course, the (relative) simplicity of the implementation will always draw CS students looking for compiler optimization projects (just as the simplicity of the language draws CS students looking to write a complete compiler). But it's one thing to get a degree out of some clever optimization; it's another thing to actually make it stick in the context of CPython, with the concerns you mention (and others I only have in my guts :-). -- --Guido van Rossum (python.org/~guido)
On 1/1/2011 3:37 PM, Guido van Rossum wrote:
And, of course, the (relative) simplicity of the implementation will always draw CS students looking for compiler optimization projects
And, ironically, slightly reduce the simplicity that attracted them. No one thinks that their straw will break the camel's back (or cause him to drop to his knees), and they are usually right. But when the camel sags, all added straws are equally responsible.
For one thing, you have your eye on the camel ;-). And your current job keep you grounded in the needs of real code. (In a current python-list discussion, someone demonstrated with timeit that in late 2.x, each iteration of 'while 1: pass' takes about a microsecond less than for 'while True: pass'. The reason for that, and the disappearance of the difference in 3.x is mildly interesting, but the practical import for any real code that does anything inside the loop is essentially 0.) -- Terry Jan Reedy
2011/1/1 Guido van Rossum <guido@python.org>
If Python direction is to embrace some JIT technology, I fully agree with you: it is best to make VM & compiler simpler. Anyway, and as I already said before, mine were just examples of possible things that can happen with optimizations.
--Guido van Rossum (python.org/~guido)
But research never stops. SETUP_WITH is just a recent example. Also, sometimes completely different ideas can bring some innovation. ;) Cesare
On 1/1/2011 11:41 AM, Guido van Rossum wrote:
In general I am not much in favor of trying to optimize Python's bytecode. I prefer the bytecode to be dead simple.
I think people constantly underestimate the virtue of Python and CPython simplicity. Projects that depend on a couple of genius ubergeeks die when the ubergeeks leave. The executable-pseudocode simplicity of the language makes it a favorite for scientific programming, spilling over into financial programming. The simplicity of the code allows competent students (and non-CS major adults) become developers. -- Terry Jan Reedy
On Sat, Jan 1, 2011 at 12:30 PM, Terry Reedy <tjreedy@udel.edu> wrote:
And, of course, the (relative) simplicity of the implementation will always draw CS students looking for compiler optimization projects (just as the simplicity of the language draws CS students looking to write a complete compiler). But it's one thing to get a degree out of some clever optimization; it's another thing to actually make it stick in the context of CPython, with the concerns you mention (and others I only have in my guts :-). -- --Guido van Rossum (python.org/~guido)
On 1/1/2011 3:37 PM, Guido van Rossum wrote:
And, of course, the (relative) simplicity of the implementation will always draw CS students looking for compiler optimization projects
And, ironically, slightly reduce the simplicity that attracted them. No one thinks that their straw will break the camel's back (or cause him to drop to his knees), and they are usually right. But when the camel sags, all added straws are equally responsible.
For one thing, you have your eye on the camel ;-). And your current job keep you grounded in the needs of real code. (In a current python-list discussion, someone demonstrated with timeit that in late 2.x, each iteration of 'while 1: pass' takes about a microsecond less than for 'while True: pass'. The reason for that, and the disappearance of the difference in 3.x is mildly interesting, but the practical import for any real code that does anything inside the loop is essentially 0.) -- Terry Jan Reedy
2011/1/1 Guido van Rossum <guido@python.org>
If Python direction is to embrace some JIT technology, I fully agree with you: it is best to make VM & compiler simpler. Anyway, and as I already said before, mine were just examples of possible things that can happen with optimizations.
--Guido van Rossum (python.org/~guido)
But research never stops. SETUP_WITH is just a recent example. Also, sometimes completely different ideas can bring some innovation. ;) Cesare
participants (3)
-
Cesare Di Mauro -
Guido van Rossum -
Terry Reedy