> 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
h
[EMAIL PROTECTED] wrote:
It's a substantial patch, but from what I understand it's a huge
performance improvement and completely compatible, both at the C API and
Python source levels.
I have not seen any Windows test yet. The direct threading is
gcc-specific, so there might be degradation
[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. Replacing the ceval loop wit
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, why not just call it
"Pyt
> 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 actual
> testing yet.
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).
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
On Wed, Oct 22, 2008 at 5:16 AM, J. Sievers <[EMAIL PROTECTED]> wrote:
> I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made
> it fairly straightforward to add direct threaded code and superinstructions
> for
> the various permutations of LOAD_CONST, LOAD_FAST, and most o
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 most of its time doing expensive things li
On Thu, Oct 23, 2008 at 8:13 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Is this kind of optimization that useful on modern CPUs? It helps remove a
> memory access to the switch/case lookup table, which should shave off the 3
> CPU
> cycles of latency of a modern L1 data cache, but it won't re
Antoine Pitrou wrote:
> 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 back
>> onto the stack.
Jakob> David Gregg (and friends) recently published a paper comparing
Jakob> stack based and register based VMs for Java and found that
Jakob> register based VMs were substantially faster. The main reason for
Jakob> this appears to be the absence of the various LOAD_ instructions
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 back
> onto the stack.
> Turning this into a superi
On 2008-10-23 15:19, David Ripton wrote:
> On 2008.10.23 12:02:12 +0200, M.-A. Lemburg wrote:
>> 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
On 2008.10.23 12:02:12 +0200, M.-A. Lemburg wrote:
> 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.
I was wondering about Pybench-specifi
A.M. Kuchling amk.ca> writes:
>
> threaded code: A technique for implementing virtual machine
> interpreters, introduced by J.R. Bell in 1973, where each op-code in
> the virtual machine instruction set is the address of some (lower
> level) code to perform the required operation.
On Thu, Oct 23, 2008 at 01:31:48AM -0600, Adam Olsen wrote:
> To clarify: This is *NOT* actually a form of threading, is it? It
> "merely" breaks the giant dispatch table into a series of small ones,
> while also grouping instructions into larger superinstructions? OS
> threads are not touched at
Adam Olsen wrote:
To clarify: This is *NOT* actually a form of threading, is it?
I think the term "threaded code" is being used here in
the sense of Forth, i.e. instead of a sequence of small
integers that are dispatched using a switch statement,
you use the actual machine addresses of the swi
On 2008-10-23 09:08, J. Sievers wrote:
> a) It's fairly easy to implement different types of dispatch, simply by
> changing a few macros (and while I haven't done this, it shouldn't be a
> problem to add some switch dispatch #ifdefs for non-GCC platforms).
>
> In particular, direct threaded code l
On Thu, Oct 23, 2008 at 1:08 AM, J. Sievers <[EMAIL PROTECTED]> wrote:
> In particular, direct threaded code leads to less horrible branch
> prediction than switch dispatch on many machines (exactly how
> pronounced this effect is depends heavily on the specific
> architecture).
To clarify: This i
Hey,
I hope you don't mind my replying in digest form.
First off, I guess I should be a little clearer as to what VPthon is
and what it does.
VPython is essentially a set of patches for CPython (in touches only
three files, diff -b is about 800 lines IIRC plus the switch statement
in ceval.c's E
20 matches
Mail list logo
