I don't see a downside and can see how it would help with private
assemblies.
[I've also added a comment to this effect to the bug]
Thanks! I'll go ahead and accept this, then.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Antoine Pitrou [EMAIL PROTECTED] writes:
Hi,
J. Sievers cadr4u at gmail.com writes:
A sequence of code such as LOAD_CONST LOAD_FAST BINARY_ADD will, in
CPython, push some constant onto the stack, push some local onto the
stack, then pop both off the stack, add them and push the result
M.-A. Lemburg [EMAIL PROTECTED] writes:
[snip]
BTW: I hope you did not use pybench to get profiles of the opcodes.
That would most certainly result in good results for pybench, but
less good ones for general applications such as Django or Zope/Plone.
Algorithm used for superinstruction
Daniel Stutzbach [EMAIL PROTECTED] writes:
[snip]
I searched around for information on how threaded code interacts with
branch prediction, and here's what I found. The short answer is that
threaded code significantly improves branch prediction.
See ``Optimizing indirect branch
On Fri, Oct 24, 2008 at 7:18 AM, Terry Reedy [EMAIL PROTECTED] wrote:
I have not seen any Windows test yet. The direct threading is gcc-specific,
so there might be degradation with MSVC.
erlang uses gcc to compile a single source file on windows and uses MS
VC++ to compile all others. They
Greg Ewing [EMAIL PROTECTED] writes:
Daniel Stutzbach wrote:
With threaded code, every handler ends with its own dispatcher, so
the processor can make fine-grained predictions.
I'm still wondering whether all this stuff makes a
noticeable difference in real-life Python code, which
spends
On 2008-10-24 09:53, J. Sievers wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
[snip]
BTW: I hope you did not use pybench to get profiles of the opcodes.
That would most certainly result in good results for pybench, but
less good ones for general applications such as Django or Zope/Plone.
[EMAIL PROTECTED] writes:
On 23 Oct, 10:42 pm, [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
there already is something else called VPython
Perhaps it could be called Fython (Python with a Forth-like VM)
or Thython (threaded-code Python).
I feel like I've missed something important, but,
Steve Holden steve at holdenweb.com writes:
Though it would seem redundant to create multiple copies of constant
structures. Wouldn't there be some way to optimize this to allow each
call to access the data from the same place?
It's just copying a table of pointers, so a bare memcpy() or its
Greg Ewing wrote:
[EMAIL PROTECTED] wrote:
Is there any reason this should be a separate project rather than just
be rolled in to the core?
Always keep in mind that one of the important characteristics
of CPython is that its implementation is very straightforward
and easy to follow.
Guido This is very interesting (at this point I'm just lurking), but
Guido has anyone pointed out yet that there already is something else
Guido called VPython, which has a long standing right to the name?
I believe Jakob has already been notified about this. How about TPython? A
Terry I have not seen any Windows test yet. The direct threading is
Terry gcc-specific, so there might be degradation with MSVC.
Not if a compiler #ifdef selects between two independent choices:
#ifdef __GCC__ /* or whatever the right incantation is */
#include
Mark Hammond schrieb:
In http://bugs.python.org/issue4120, the author suggests that it might
be possible to completely stop using the manifest mechanism, for VS
2008. Given the many problems that this SxS stuff has caused, this
sounds like a very desirable route, although I haven't done any
At 10:47 AM 10/24/2008 +0200, J. Sievers wrote:
- Right now, CPython's bytecode is translated to direct threaded code
lazily (when a code object is first evaluated). This would have to
be merged into compile.c in some way plus some assorted minor changes.
Don't you mean codeobject.c? I
ACTIVITY SUMMARY (10/17/08 - 10/24/08)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2124 open (+32) / 13891 closed (+20) / 16015 total (+52)
Open issues with patches: 700
[EMAIL PROTECTED] writes:
BTW, as to the implementation of individual VM instructions I don't believe
the Vmgen stuff affects that. It's just the way the instructions are
assembled.
Vmgen handles the pushing and popping as well. E.g. ROT_THREE becomes:
rot_three ( a1 a2 a3 -- a3 a1 a2 )
[EMAIL PROTECTED] writes:
Guido This is very interesting (at this point I'm just lurking), but
Guido has anyone pointed out yet that there already is something else
Guido called VPython, which has a long standing right to the name?
I believe Jakob has already been notified about
Mark Hammond schrieb:
In http://bugs.python.org/issue4120, the author suggests that it
might
be possible to completely stop using the manifest mechanism, for VS
2008. Given the many problems that this SxS stuff has caused, this
sounds like a very desirable route, although I haven't done
Stefan Behnel wrote:
Funny to hear that from the author of a well-known code generator. ;-)
I've never claimed that anything about the implementation
of Pyrex is easy to follow. :-)
Having two switch statements and a couple of separate
special cases for a single eval loop might look pretty
19 matches
Mail list logo
