Re: [Python-Dev] Python 3 optimizations, continued, continued again...

> I really don't think that is a problem. The core contributors can deal > well with complexity in my experience. :-) > No no, I wasn't trying to insinuate anything like that at all. No, I just figured that having the code generator being able to generate 4 optimizations where only one is supported

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

On Wed, Feb 1, 2012 at 20:08, stefan brunthaler wrote: > I understand all of these issues. Currently, it's not really a mess, > but much more complicated as it needs to be for only supporting the > inca optimization. I really don't think that is a problem. The core contributors can deal well with

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

On Wed, Feb 1, 2012 at 11:08 AM, stefan brunthaler wrote: > On Wed, Feb 1, 2012 at 09:46, Guido van Rossum wrote: >> Let's make one thing clear. The Python core developers need to be able >> to reproduce your results from scratch, and that means access to the >> templates, code generators, inputs

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

On Feb 1, 2012, at 12:46 PM, Guido van Rossum wrote: > I understand that you're hesitant to just dump your current mess, and > you want to clean it up before you show it to us. That's fine. (...) And > remember, it doesn't need to be > perfect (in fact perfectionism is probably a bad idea here).

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

On Wed, Feb 1, 2012 at 09:46, Guido van Rossum wrote: > Let's make one thing clear. The Python core developers need to be able > to reproduce your results from scratch, and that means access to the > templates, code generators, inputs, and everything else you used. (Of > course for stuff you didn'

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

Let's make one thing clear. The Python core developers need to be able to reproduce your results from scratch, and that means access to the templates, code generators, inputs, and everything else you used. (Of course for stuff you didn't write that's already open source, all we need is a pointer to

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

> But let me put this straight: as an open-source project, we are hesitant to > accept changes which depend on closed software. Even if your optimization > techniques would result in performance a hundred times better than what is > currently achieved, we would still be wary to accept them. > > Ple

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

Wiadomość napisana przez stefan brunthaler w dniu 1 lut 2012, o godz. 16:55: >> And how do you know that you really got it so right that it was the last >> time ever >> that you needed your generator for it? > > I am positive that I am going to need my code generator in the future, > as I have s

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

> How many times did you regenerate this code until you got it right? Well, honestly, I changed the code generator to "pack" the new optimized instruction derivatives densly into the available opcodes, so that I can make optimal use of what's there. Thus I only generated the code twice for this pa

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

stefan brunthaler, 31.01.2012 22:17: >> Well, nobody wants to review generated code. >> > I agree. The code generator basically uses templates that contain the > information and a dump of the C-structure of several types to traverse > and see which one of them implements which functions. There is r

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

> There is also the issue of the two test modules removed from the > test suite. > Oh, I'm sorry, seems like the patch did contain too much of my development stuff. (I did remove them before, because they were always failing due to the instruction opcodes being changed because of quickening; they p

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

Am 31.01.2012 16:46, schrieb stefan brunthaler: >> If I read the patch correctly, most of it is auto-generated (and there >> is probably a few spurious changes that blow it up, such as the >> python-gdb.py file). > > Hm, honestly I don't know where the python-gdb.py file comes from, I > thought it

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

> If I read the patch correctly, most of it is auto-generated (and there > is probably a few spurious changes that blow it up, such as the > python-gdb.py file). Hm, honestly I don't know where the python-gdb.py file comes from, I thought it came with the switch from 3.1 to the tip version I was u

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

> I assume "yes" here means "yes, I'm aware" and not "yes, I'm using Python > 2", right? And you're building on top of the existing support for threaded > code in order to improve it? > Your assumption is correct, I'm sorry for the sloppiness (I was heading out for lunch.) None of the code is 2.x c

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

Am 30.01.2012 20:06, schrieb stefan brunthaler: >> Do you have a public repository for the code, so we can take a look? >> > I have created a patch (as Benjamin wanted) and put all of the > resources (i.e., benchmark results and the patch itself) on my home > page: > http://www.ics.uci.edu/~sbrunt

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

stefan brunthaler, 30.01.2012 20:18: >> Well, you're aware that Python already uses threaded code where >> available? Or are you testing against Python 2? >> > Yes, and I am building on that. I assume "yes" here means "yes, I'm aware" and not "yes, I'm using Python 2", right? And you're building o

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

> Well, you're aware that Python already uses threaded code where > available? Or are you testing against Python 2? > Yes, and I am building on that. --stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pytho

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

Hello, > Well, you can implement threaded code on any machine that support > indirect branch instructions. Fortunately, GCC supports the > "label-as-values" feature, which makes it available on any machine > that supports GCC. My optimizations themselves are portable, and I > tested them on a Pow

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

Hello, > Could you try benchmarking with the "standard" benchmarks: > http://hg.python.org/benchmarks/ > and see what sort of performance gains you get? > Yeah, of course. I already did. Refere to the page listed below for details. I did not look into the results yet, though. > How portable is t

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

stefan brunthaler wrote: Hi, On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson wrote: 2011/11/8 stefan brunthaler : How does that sound? I think I can hear real patches and benchmarks most clearly. I spent the better part of my -20% time on implementing the work as "suggested". Please find t

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

2012/1/27 stefan brunthaler : > Hi, > > On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson wrote: >> 2011/11/8 stefan brunthaler : >>> How does that sound? >> >> I think I can hear real patches and benchmarks most clearly. >> > I spent the better part of my -20% time on implementing the work as > "su

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

Hi, On Tue, Nov 8, 2011 at 10:36, Benjamin Peterson wrote: > 2011/11/8 stefan brunthaler : >> How does that sound? > > I think I can hear real patches and benchmarks most clearly. > I spent the better part of my -20% time on implementing the work as "suggested". Please find the benchmarks attache

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

2011/11/8 stefan brunthaler : > How does that sound? I think I can hear real patches and benchmarks most clearly. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

[Python-Dev] Python 3 optimizations, continued, continued again...

Hi guys, while there is at least some interest in incorporating my optimizations, response has still been low. I figure that the changes are probably too much for a single big incorporation step. On a recent flight, I thought about cutting it down to make it more easily digestible. The basic idea

Re: [Python-Dev] Python 3 optimizations continued...

On Fri, Sep 2, 2011 at 9:20 PM, Stefan Behnel wrote: > Maciej Fijalkowski, 02.09.2011 20:42: >>> >>> For a comparative real world benchmark I tested Martin von Loewis' >>> django port (there are not that many meaningful Python 3 real world >>> benchmarks) and got a speedup of 1.3 (without IIS). Th

Re: [Python-Dev] Python 3 optimizations continued...

Maciej Fijalkowski, 02.09.2011 20:42: For a comparative real world benchmark I tested Martin von Loewis' django port (there are not that many meaningful Python 3 real world benchmarks) and got a speedup of 1.3 (without IIS). This is reasonably well, US got a speedup of 1.35 on this benchmark. I j

Re: [Python-Dev] Python 3 optimizations continued...

> > For a comparative real world benchmark I tested Martin von Loewis' > django port (there are not that many meaningful Python 3 real world > benchmarks) and got a speedup of 1.3 (without IIS). This is reasonably > well, US got a speedup of 1.35 on this benchmark. I just checked that > pypy-c-late

Re: [Python-Dev] Python 3 optimizations continued...

stefan brunthaler, 02.09.2011 17:55: 4) Regarding inlined object references, I would expect that it's much more worthwhile to speed up LOAD_GLOBAL and LOAD_NAME than LOAD_CONST. I guess that this would be best helped by watching the module dict and the builtin dict internally and invalidating the

Re: [Python-Dev] Python 3 optimizations continued...

> 1) The SFC optimisation is purely based on static code analysis, right? I > assume it takes loops into account (and just multiplies scores for inner > loops)? Is that what you mean with "nesting level"? Obviously, static > analysis can sometimes be misleading, e.g. when there's a rare special cas

Re: [Python-Dev] Python 3 optimizations continued...

> as promised, I created a publicly available preview of an > implementation with my optimizations, which is available under the > following location: > https://bitbucket.org/py3_pio/preview/wiki/Home > One very important thing that I forgot was to indicate that you have to use computed gotos (i.e.

Re: [Python-Dev] Python 3 optimizations continued...

stefan brunthaler, 02.09.2011 06:37: as promised, I created a publicly available preview of an implementation with my optimizations, which is available under the following location: https://bitbucket.org/py3_pio/preview/wiki/Home I followed Nick's advice and added some valuable advice and overvi

Re: [Python-Dev] Python 3 optimizations continued...

On Fri, Sep 2, 2011 at 2:37 PM, stefan brunthaler wrote: > I hope this clarifies a *lot* and makes it easier to see what parts > are involved and how all the pieces fit together. It does, thanks. There are likely to be some fun corner cases relating to trace functions and use of the "locals()" bu

Re: [Python-Dev] Python 3 optimizations continued...

Hi, as promised, I created a publicly available preview of an implementation with my optimizations, which is available under the following location: https://bitbucket.org/py3_pio/preview/wiki/Home I followed Nick's advice and added some valuable advice and overview/introduction at the wiki page t

Re: [Python-Dev] Python 3 optimizations continued...

On Thu, Sep 1, 2011 at 10:15 AM, Glyph Lefkowitz wrote: > > On Sep 1, 2011, at 5:23 AM, Cesare Di Mauro wrote: > > A simple solution: when tracing is enabled, the new instruction format will > never be executed (and information tracking disabled as well). > > Correct me if I'm wrong: doesn't this

Re: [Python-Dev] Python 3 optimizations continued...

On Sep 1, 2011, at 5:23 AM, Cesare Di Mauro wrote: > A simple solution: when tracing is enabled, the new instruction format will > never be executed (and information tracking disabled as well). Correct me if I'm wrong: doesn't this mean that no profiler will accurately be able to measure the p

Re: [Python-Dev] Python 3 optimizations continued...

2011/9/1 Mark Shannon > Cesare Di Mauro wrote: > >> 2011/9/1 Ned Batchelder > n...@nedbatchelder.com>> >> >> >>When the switchover to the new instruction format happens, what >>happens to sys.settrace() tracing? Will it report the same sequence >>of line numbers? For a small but imp

Re: [Python-Dev] Python 3 optimizations continued...

Cesare Di Mauro wrote: 2011/9/1 Ned Batchelder > When the switchover to the new instruction format happens, what happens to sys.settrace() tracing? Will it report the same sequence of line numbers? For a small but important class of program execut

Re: [Python-Dev] Python 3 optimizations continued...

2011/9/1 Ned Batchelder > When the switchover to the new instruction format happens, what happens to > sys.settrace() tracing? Will it report the same sequence of line numbers? > For a small but important class of program executions, this is more > important than speed. > > --Ned > A simple s

Re: [Python-Dev] Python 3 optimizations continued...

On 8/30/2011 4:41 PM, stefan brunthaler wrote: Ok, there there's something else you haven't told us. Are you saying that the original (old) bytecode is still used (and hence written to and read from .pyc files)? Short answer: yes. Long answer: I added an invocation counter to the code object an

Re: [Python-Dev] Python 3 optimizations continued...

On Thu, Sep 1, 2011 at 3:28 AM, Guido van Rossum wrote: > On Tue, Aug 30, 2011 at 10:04 PM, Cesare Di Mauro > Cesare, I'm really sorry that you became so disillusioned that you > abandoned wordcode. I agree that we were too optimistic about Unladen > Swallow. Also that the existence of PyPy and it

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/31 Guido van Rossum > On Tue, Aug 30, 2011 at 10:04 PM, Cesare Di Mauro > wrote: > > It isn't, because motivation to do something new with CPython vanishes, > at > > least on some areas (virtual machine / ceval.c), even having some ideas > to > > experiment with. That's why in my last tal

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/31 stefan brunthaler > > I think that you must deal with big endianess because some RISC can't > handle > > at all data in little endian format. > > > > In WPython I have wrote some macros which handle both endianess, but > lacking > > big endian machines I never had the opportunity to ver

Re: [Python-Dev] Python 3 optimizations continued...

On Wed, Aug 31, 2011 at 10:08 AM, stefan brunthaler wrote: > Well, my code has primarily been a vehicle for my research in that > area and thus is not immediately suited to adoption [...]. But if you want to be taken seriously as a researcher, you should publish your code! Without publication of

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 10:04 PM, Cesare Di Mauro wrote: > It isn't, because motivation to do something new with CPython vanishes, at > least on some areas (virtual machine / ceval.c), even having some ideas to > experiment with. That's why in my last talk on EuroPython I decided to move > on othe

Re: [Python-Dev] Python 3 optimizations continued...

> So, basically, you built a JIT compiler but don't want to call it that, > right? Just because it compiles byte code to other byte code rather than to > native CPU instructions does not mean it doesn't compile Just In Time. > For me, a definition of a JIT compiler or any dynamic compilation subsys

Re: [Python-Dev] Python 3 optimizations continued...

> I think that you must deal with big endianess because some RISC can't handle > at all data in little endian format. > > In WPython I have wrote some macros which handle both endianess, but lacking > big endian machines I never had the opportunity to verify if something was > wrong. > I am sorry f

Re: [Python-Dev] Python 3 optimizations continued...

stefan brunthaler, 30.08.2011 22:41: Ok, there there's something else you haven't told us. Are you saying that the original (old) bytecode is still used (and hence written to and read from .pyc files)? Short answer: yes. Long answer: I added an invocation counter to the code object and keep int

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/31 Terry Reedy > I find myself more comfortable with the Cesare Di Mauro's idea of expanding > to 16 bits as the code unit. His basic idea was using 2, 4, or 6 bytes > instead of 1, 3, or 6. > It can be expanded to longer than 6 bytes opcodes, if needed. The format is designed to be flexi

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/30 stefan brunthaler > > Do I sense that the bytecode format is no longer platform-independent? > > That will need a bit of discussion. I bet there are some things around > > that depend on that. > > > Hm, I haven't really thought about that in detail and for longer, I > ran it on PowerPC

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/30 stefan brunthaler > Yes, indeed I have a more straightforward instruction format to allow > for more efficient decoding. Just going from bytecode size to > word-code size without changing the instruction format is going to > require 8 (or word-size) times more memory on a 64bit system.

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/30 Nick Coghlan > > Yeah, it's definitely a trade-off - the point I was trying to make is > that there *is* a trade-off being made between complexity and speed. > > I think the computed-gotos stuff struck a nice balance - the macro-fu > involved means that you can still understand what the

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/30 Antoine Pitrou > Changing the bytecode width wouldn't make the interpreter more complex. It depends on the kind of changes. :) WPython introduced a very different "intermediate code" representation that required a big change on the peepholer optimizer on 1.0 alpha version. On 1.1 fi

Re: [Python-Dev] Python 3 optimizations continued...

On 8/30/2011 2:12 PM, Guido van Rossum wrote: On Tue, Aug 30, 2011 at 10:50 AM, stefan brunthaler wrote: Do you really need it to match a machine word? Or is, say, a 16-bit format sufficient. Hm, technically no, but practically it makes more sense, as (at least for x86 architectures) having

Re: [Python-Dev] Python 3 optimizations continued...

On Wed, Aug 31, 2011 at 9:21 AM, Jesse Noller wrote: > Discussion of speed.python.org should happen on the mailing list for that > project if possible. Hah, that's how out of the loop I am on that front - I didn't even know there *was* a mailing list for it :) Subscribed! Cheers, Nick. P.S. F

Re: [Python-Dev] Python 3 optimizations continued...

On Wed, Aug 31, 2011 at 3:23 AM, stefan brunthaler wrote: > On Tue, Aug 30, 2011 at 09:42, Guido van Rossum wrote: >> Stefan, have you shared a pointer to your code yet? Is it open source? >> > I have no shared code repository, but could create one (is there any > pydev preferred provider?). I ha

Re: [Python-Dev] Python 3 optimizations continued...

On Aug 30, 2011, at 9:05 AM, Nick Coghlan wrote: > On Tue, Aug 30, 2011 at 9:38 PM, Antoine Pitrou wrote: >> On Tue, 30 Aug 2011 13:29:59 +1000 >> Nick Coghlan wrote: >>> >>> Anecdotal, non-reproducible performance figures are *not* the way to >>> go about serious optimisation efforts. >> >

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 1:54 PM, Benjamin Peterson wrote: > 2011/8/30 stefan brunthaler : > > On Tue, Aug 30, 2011 at 13:42, Benjamin Peterson > wrote: > >> 2011/8/30 stefan brunthaler : > >>> I will remove my development commentaries and create a private > >>> repository at bitbucket for you* to

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/30 stefan brunthaler : > On Tue, Aug 30, 2011 at 13:42, Benjamin Peterson wrote: >> 2011/8/30 stefan brunthaler : >>> I will remove my development commentaries and create a private >>> repository at bitbucket for you* to take an early look like Georg (and >>> more or less Terry, too) sugges

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 13:42, Benjamin Peterson wrote: > 2011/8/30 stefan brunthaler : >> I will remove my development commentaries and create a private >> repository at bitbucket for you* to take an early look like Georg (and >> more or less Terry, too) suggested. Is that a good way for most of

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/30 stefan brunthaler : > I will remove my development commentaries and create a private > repository at bitbucket for you* to take an early look like Georg (and > more or less Terry, too) suggested. Is that a good way for most of > you? (I would then give access to whomever wants to take a l

Re: [Python-Dev] Python 3 optimizations continued...

> Ok, there there's something else you haven't told us. Are you saying > that the original (old) bytecode is still used (and hence written to > and read from .pyc files)? > Short answer: yes. Long answer: I added an invocation counter to the code object and keep interpreting in the usual Python int

Re: [Python-Dev] Python 3 optimizations continued...

Am 30.08.2011 20:34, schrieb stefan brunthaler: >> Um, I'm sorry, but that reply sounds incredibly naive, like you're not >> really sure what the on-disk format for .pyc files is or why it would >> matter. You're not even answering the question, except indirectly -- >> it seems that you've never ev

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 11:34 AM, stefan brunthaler wrote: >> Um, I'm sorry, but that reply sounds incredibly naive, like you're not >> really sure what the on-disk format for .pyc files is or why it would >> matter. You're not even answering the question, except indirectly -- >> it seems that you

Re: [Python-Dev] Python 3 optimizations continued...

On 8/30/2011 1:23 PM, stefan brunthaler wrote: (I just wanted to know if there is substantial interest so that > it eventually pays off to find and fix the remaining bugs) It is the nature of our development process that there usually can be no guarantee of acceptance of future code. The rath

Re: [Python-Dev] Python 3 optimizations continued...

> Um, I'm sorry, but that reply sounds incredibly naive, like you're not > really sure what the on-disk format for .pyc files is or why it would > matter. You're not even answering the question, except indirectly -- > it seems that you've never even thought about the possibility of > generating a .

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 11:23 AM, stefan brunthaler wrote: >> Do I sense that the bytecode format is no longer platform-independent? >> That will need a bit of discussion. I bet there are some things around >> that depend on that. >> > Hm, I haven't really thought about that in detail and for long

Re: [Python-Dev] Python 3 optimizations continued...

> Do I sense that the bytecode format is no longer platform-independent? > That will need a bit of discussion. I bet there are some things around > that depend on that. > Hm, I haven't really thought about that in detail and for longer, I ran it on PowerPC 970 and Intel Atom & i7 without problems (

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 10:50 AM, stefan brunthaler wrote: >> Do you really need it to match a machine word? Or is, say, a 16-bit >> format sufficient. >> > Hm, technically no, but practically it makes more sense, as (at least > for x86 architectures) having opargs and opcodes in half-words can be

Re: [Python-Dev] Python 3 optimizations continued...

> Do you really need it to match a machine word? Or is, say, a 16-bit > format sufficient. > Hm, technically no, but practically it makes more sense, as (at least for x86 architectures) having opargs and opcodes in half-words can be efficiently expressed in assembly. On 64bit architectures, I could

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, 30 Aug 2011 08:27:13 -0700 stefan brunthaler wrote: > >> Changing the bytecode width wouldn't make the interpreter more complex. > > > > No, but I think Stefan is proposing to add a *second* byte code format, > > in addition to the one that remains there. That would certainly be an > > inc

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 09:42, Guido van Rossum wrote: > Stefan, have you shared a pointer to your code yet? Is it open source? > I have no shared code repository, but could create one (is there any pydev preferred provider?). I have all the copyrights on the code, and I would like to open-source

Re: [Python-Dev] Python 3 optimizations continued...

Stefan, have you shared a pointer to your code yet? Is it open source? It sounds like people are definitely interested and it would make sense to let them experiment with your code and review it. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev

Re: [Python-Dev] Python 3 optimizations continued...

>> Changing the bytecode width wouldn't make the interpreter more complex. > > No, but I think Stefan is proposing to add a *second* byte code format, > in addition to the one that remains there. That would certainly be an > increase in complexity. > Yes, indeed I have a more straightforward instru

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 9:38 PM, Antoine Pitrou wrote: > On Tue, 30 Aug 2011 13:29:59 +1000 > Nick Coghlan wrote: >> >> Anecdotal, non-reproducible performance figures are *not* the way to >> go about serious optimisation efforts. > > What about anecdotal *and* reproducible performance figures? :

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, 30 Aug 2011 13:29:59 +1000 Nick Coghlan wrote: > > Anecdotal, non-reproducible performance figures are *not* the way to > go about serious optimisation efforts. What about anecdotal *and* reproducible performance figures? :) I may be half-joking, but we already have a set of py3k-compati

Re: [Python-Dev] Python 3 optimizations continued...

>> Although any such patch should discuss how it compares with Cesare's >> work on wpython. >> Personally, I *like* CPython fitting into the "simple-and-portable" >> niche in the Python interpreter space. > > Changing the bytecode width wouldn't make the interpreter more complex. No, but I think

Re: [Python-Dev] Python 3 optimizations continued...

Martin v. Löwis wrote: So, the two big issues aside, is there any interest in incorporating these optimizations in Python 3? The question really is whether this is an all-or-nothing deal. If you could identify smaller parts that can be applied independently, interest would be higher. Also, I'd

Re: [Python-Dev] Python 3 optimizations continued...

Nick Coghlan wrote: On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou wrote: On Mon, 29 Aug 2011 11:33:14 -0700 stefan brunthaler wrote: * The optimized dispatch routine has a changed instruction format (word-sized instead of bytecodes) that allows for regular instruction decoding (without the

Re: [Python-Dev] Python 3 optimizations continued...

Nick Coghlan, 30.08.2011 02:00: On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou wrote: On Mon, 29 Aug 2011 11:33:14 -0700 stefan brunthaler wrote: * The optimized dispatch routine has a changed instruction format (word-sized instead of bytecodes) that allows for regular instruction decoding (wi

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 4:22 PM, Eli Bendersky wrote: > On Tue, Aug 30, 2011 at 08:57, Greg Ewing > wrote: > Following this argument to the extreme, the bytecode evaluation code of > CPython can be simplified quite a bit. Lose 2x performance but gain a lot of > readability. Does that sound like a

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 08:57, Greg Ewing wrote: > Nick Coghlan wrote: > > Personally, I *like* CPython fitting into the "simple-and-portable" >> niche in the Python interpreter space. >> > > Me, too! I like that I can read the CPython source and > understand what it's doing most of the time. Ple

Re: [Python-Dev] Python 3 optimizations continued...

Nick Coghlan wrote: Personally, I *like* CPython fitting into the "simple-and-portable" niche in the Python interpreter space. Me, too! I like that I can read the CPython source and understand what it's doing most of the time. Please don't screw that up by attempting to perform heroic optimisa

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 12:38 PM, Gregory P. Smith wrote: > Some in this thread seemed to give the impression that CPython performance > is not something to care about. I disagree. I see CPython being the main > implementation of Python used in most places for a long time. Improving its > performa

Re: [Python-Dev] Python 3 optimizations continued...

On Mon, Aug 29, 2011 at 2:05 PM, stefan brunthaler wrote: > > The question really is whether this is an all-or-nothing deal. If you > > could identify smaller parts that can be applied independently, interest > > would be higher. > > > Well, it's not an all-or-nothing deal. In my current architect

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, 30 Aug 2011 10:00:28 +1000 Nick Coghlan wrote: > > > > Having a word-sized "bytecode" format would probably be acceptable in > > itself, so if you want to submit a patch for that, go ahead. > > Although any such patch should discuss how it compares with Cesare's > work on wpython. > Perso

Re: [Python-Dev] Python 3 optimizations continued...

> Personally, I *like* CPython fitting into the "simple-and-portable" > niche in the Python interpreter space. Armin Rigo made the judgment > years ago that CPython was a poor platform for serious optimisation > when he stopped working on Psyco and started PyPy instead, and I think > the contrastin

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou wrote: > On Mon, 29 Aug 2011 11:33:14 -0700 > stefan brunthaler wrote: >> * The optimized dispatch routine has a changed instruction format >> (word-sized instead of bytecodes) that allows for regular instruction >> decoding (without the HAS_ARG-che

Re: [Python-Dev] Python 3 optimizations continued...

> Does it speed up Python? :-) Could you provide numbers (benchmarks)? > Yes, it does ;) The maximum overall speedup I achieved was by a factor of 2.42 on my i7-920 for the spectralnorm benchmark of the computer language benchmark game. Others from the same set are: binarytrees: 1.9257 (1.9891)

Re: [Python-Dev] Python 3 optimizations continued...

Le lundi 29 août 2011 19:35:14, stefan brunthaler a écrit : > pretty much a year ago I wrote about the optimizations I did for my > PhD thesis that target the Python 3 series interpreters Does it speed up Python? :-) Could you provide numbers (benchmarks)? Victor

Re: [Python-Dev] Python 3 optimizations continued...

On Mon, 29 Aug 2011 11:33:14 -0700 stefan brunthaler wrote: > * The optimized dispatch routine has a changed instruction format > (word-sized instead of bytecodes) that allows for regular instruction > decoding (without the HAS_ARG-check) and inlinind of some objects in > the instruction format on

Re: [Python-Dev] Python 3 optimizations continued...

> The question really is whether this is an all-or-nothing deal. If you > could identify smaller parts that can be applied independently, interest > would be higher. > Well, it's not an all-or-nothing deal. In my current architecture, I can selectively enable most of the optimizations as I see fit.

Re: [Python-Dev] Python 3 optimizations continued...

> So, the two big issues aside, is there any interest in incorporating > these optimizations in Python 3? The question really is whether this is an all-or-nothing deal. If you could identify smaller parts that can be applied independently, interest would be higher. Also, I'd be curious whether yo

Re: [Python-Dev] Python 3 optimizations continued...

> Perhaps there would be something to say given patches/overviews/specifics. > Currently I don't have patches, but for an overview and specifics, I can provide the following: * My optimizations basically rely on quickening to incorporate run-time information. * I use two separate instruction dispat

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/29 stefan brunthaler : > So, the two big issues aside, is there any interest in incorporating > these optimizations in Python 3? Perhaps there would be something to say given patches/overviews/specifics. -- Regards, Benjamin ___ Python-Dev mail

[Python-Dev] Python 3 optimizations continued...

Hi, pretty much a year ago I wrote about the optimizations I did for my PhD thesis that target the Python 3 series interpreters. While I got some replies, the discussion never really picked up and no final explicit conclusion was reached. AFAICT, because of the following two factors, my optimizati

Re: [Python-Dev] Python 3 optimizations...

> I think I was wrong, but now I understand.  The inlining you want is > to get the nb_add body, not the opcode body. > Exactly. This would increase performace by quite a bit -- I will start experimentation with that stuff a.s.a.p. > The example you've given brings up a correctness issue.  It see

Re: [Python-Dev] Python 3 optimizations...

On Fri, Jul 23, 2010 at 11:26 AM, stefan brunthaler wrote: >> I'm guessing from your comments below about cross-module inlining that >> you generate a separate .c file with the specialized opcode bodies and >> then call through to them via a table of function pointers indexed by >> opcode, but I c

Re: [Python-Dev] Python 3 optimizations...

> wpython has reached 1.1 final version. If you are interested, you can find > it here: http://code.google.com/p/wpython2/ and you can download the new > slides that cover the improvements over 1.0 alpha. > Thanks for the hint, I will definitely check your new slides. > Did you used wpython wordc

Re: [Python-Dev] Python 3 optimizations...

> How do you generate the specialized opcode implementations? > I have a small code generator written in Python that uses Mako templates to generate C files that can be included in the main interpreter. It is a data driven approach that uses type information gathered by gdb and check whether given

Re: [Python-Dev] Python 3 optimizations...

2010/7/23 stefan brunthaler > > This sounds like wpython (a CPython derivative with a wider set of byte > code > > commands) could benefit from it. > > > I am aware of the wpython project of Cesare di Mauro. wpython has reached 1.1 final version. If you are interested, you can find it here: htt

  1   2   >