Re: Standardizing RPython - it's time.

2010-10-13 Thread Carl Friedrich Bolz
Hi John, John Nagle animats.com> writes: > All attempts to make the dialect defined by CPython significantly > faster have failed. PyPy did not achieve much of a speed > improvement over CPython, and is sometimes slower. This is not true. While PyPy is indeed sometimes slower than CPython

Re: Standardizing RPython - it's time.

2010-10-12 Thread Stefan Behnel
Stefan Behnel, 12.10.2010 09:18: If you implemented an RPython to CPython extension compiler, [...] BTW, if anyone wanted to do that, it might be a good idea to start with Cython, adapt its type inference layer and add the few missing Python language features (or pay the core developers to d

Re: Standardizing RPython - it's time.

2010-10-12 Thread Nils Ruettershoff
On 10/12/2010 05:18 PM, Nils Ruettershoff wrote: Hi, On 10/12/2010 07:41 AM, John Nagle wrote: [...] With Unladen Swallow looking like a failed IT project, a year behind schedule and not delivering anything like the promised performance, Google management may pull the plug on funding. Since

Re: Standardizing RPython - it's time.

2010-10-12 Thread Nils Ruettershoff
Hi, On 10/12/2010 07:41 AM, John Nagle wrote: [...] With Unladen Swallow looking like a failed IT project, a year behind schedule and not delivering anything like the promised performance, Google management may pull the plug on funding. Since there hasn't been a "quarterly release" in a year

Re: Standardizing RPython - it's time.

2010-10-12 Thread Stefan Behnel
John Nagle, 11.10.2010 22:01: It may be time to standardize "RPython". There are at least three implementations of "RPython" variants - PyPy, Shed Skin, and RPython for LLVM. The first two are up and running. The thing is, while RPython can be seen as a general purpose programming language,

Re: Standardizing RPython - it's time.

2010-10-11 Thread alex23
John Nagle wrote: >      All the schemes to speed up Python as defined by CPython seem to hit > a wall on speed improvement.  Some of the numeric benchmarks go faster > on implementations that don't box all numbers, but 2x seems to be about > as good as it gets, even with a JIT compiler. That has

Re: Standardizing RPython - it's time.

2010-10-11 Thread John Nagle
On 10/11/2010 1:47 PM, Ryan Kelly wrote: On Mon, 2010-10-11 at 13:01 -0700, John Nagle wrote: It may be time to standardize "RPython". There are at least three implementations of "RPython" variants - PyPy, Shed Skin, and RPython for LLVM. The first two are up and running. There's a theory

Re: Standardizing RPython - it's time.

2010-10-11 Thread Ryan Kelly
On Mon, 2010-10-11 at 13:01 -0700, John Nagle wrote: > It may be time to standardize "RPython". > >There are at least three implementations of "RPython" variants - PyPy, > Shed Skin, and RPython for LLVM. The first two are up and running. > There's a theory paper on the subject: > > http://c

Re: Standardizing RPython - it's time.

2010-10-11 Thread John Nagle
On 10/11/2010 1:01 PM, John Nagle wrote: (Correct Shed Skin tutorial link) > Shed Skin: > http://shedskin.googlecode.com/files/shedskin-tutorial-0.3.html -- http://mail.python.org/mailman/listinfo/python-list

Re: Standardizing RPython - it's time.

2010-10-11 Thread Jed Smith
On Mon, Oct 11, 2010 at 4:01 PM, John Nagle wrote: > file:///C:/Users/nagle/AppData/Local/Temp/shedskin-tutorial-0.3.html This gives me a 404. Your Web server is broken! Fix it! ;) Temporarily mirrored: http://jedsmith.org/tmp/shedskin-tutorial-0.5.html -- Jed Smith j...@jedsmith.org -- http

Standardizing RPython - it's time.

2010-10-11 Thread John Nagle
It may be time to standardize "RPython". There are at least three implementations of "RPython" variants - PyPy, Shed Skin, and RPython for LLVM. The first two are up and running. There's a theory paper on the subject: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.1457&rep=rep