RetroSearch Browse

Mon Feb 1 13:21:13 EST 2016 · https://mail.python.org/pipermail/python-dev/2016-February/143021.html

On 01.02.2016 18:18, Brett Cannon wrote:
>
>
> On Mon, 1 Feb 2016 at 09:08 Yury Selivanov <yselivanov.ml at gmail.com 
> <mailto:yselivanov.ml at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160201/71b76cb4/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-February/143021.html below:

[Python-Dev] Speeding up CPython 5-10%