(original) (raw)
On Mon, 1 Feb 2016 at 10:21 Sven R. Kunze <srkunze@mail.de> wrote:
On 01.02.2016 18:18, Brett Cannon wrote:
On 2016-01-29 11:28 PM, Steven D'Aprano wrote:
\> On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote:
\>> Hi,
\>>
\>>
\>> tl;dr The summary is that I have a patch that improves CPython
\>> performance up to 5-10% on macro benchmarks. Benchmarks results on
\>> Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available
\>> at \[1\]. There are no slowdowns that I could reproduce consistently.
\> Have you looked at Cesare Di Mauro's wpython? As far as I know, it's now
\> unmaintained, and the project repo on Google Code appears to be dead (I
\> get a 404), but I understand that it was significantly faster than
\> CPython back in the 2.6 days.
\>
\> https://wpython.googlecode.com/files/Beyond%20Bytecode%20-%20A%20Wordcode-based%20Python.pdf
\>
\>
Thanks for bringing this up!
IIRC wpython was about using "fat" bytecodes, i.e. using 64bits per
bytecode instead of 8\. That allows to minimize the number of bytecodes,
thus having some performance increase. TBH, I don't think it was
"significantly faster".
If I were to do some big refactoring of the ceval loop, I'd probably
consider implementing a register VM. While register VMs are a bit
faster than stack VMs (up to 20-30%), they would also allow us to apply
more optimizations, and even bolt on a simple JIT compiler.
If you did tackle the register VM approach that would also settle a long-standing question of whether a certain optimization works for Python.Are there some resources on why register machines are considered faster than stack machines?
A search for \[stack vs register based virtual machine\] will get you some information.
As for bolting on a JIT, the whole point of Pyjion is to see if that's worth it for CPython, so that's already being taken care of (and is actually easier with a stack-based VM since the JIT engine we're using is stack-based itself).
Interesting. Haven't noticed these projects, yet.
You aren't really supposed to yet. :) In Pyjion's case we are still working on compatibility, let alone trying to show a speed improvement so we have not said much beyond this mailing list (we have a talk proposal in for PyCon US that we hope gets accepted). We just happened to get picked up on Reddit and HN recently and so interest has spiked in the project.
So, it could be that we will see a jitted CPython when Pyjion appears to be successful?
The ability to plug in a JIT, but yes, that's the hope.