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 a
> 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
[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 notifi
[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 )
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
Average
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 don'
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
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 "ceval
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?
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 fol
Steve Holden 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 hand-
[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 impo
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 Z
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, whic
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. The
"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 branc
"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
Antoine Pitrou <[EMAIL PROTECTED]> writes:
> Hi,
>
> J. Sievers 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
18 matches
Mail list logo
