On 01.02.2016 18:18, Brett Cannon wrote:


On Mon, 1 Feb 2016 at 09:08 Yury Selivanov <yselivanov.ml@gmail.com> 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?

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.

So, it could be that we will see a jitted CPython when Pyjion appears to be successful?

Best,
Sven