subject:"\[Python\-Dev\] Re\: Speeding up CPython"

On 21/10/2020 20.55, Larry Hastings wrote:
> On 10/21/20 5:58 AM, Petr Viktorin wrote:
>> At the risk of going off topic: That's for GCC. As far as I know, MSVC
>> uses something like __declspec( thread ).
>> What are the options for generic C99 compilers, other than staying slow?
> 
> 
> As a practical matter: does CPython even support "generic C99
> compilers"?  AFAIK we support three specific compilers: GCC, Clang, and
> MSVC.
> 
> (Maybe we also support icc?  I think mostly because it supports GCC
> language extensions.)

We don't prohibit users to use exotic compilers. Some users maintain
Python on platforms like AIX and Solaris with closed source compilers.

In my opinion it would fine to focus on X86_64 and GCC first. That will
cover the majority of servers and consumer PCs. Clang and GCC have a
similar feature set and extensions, so clang should be doable with
manageable amount of effort, too. After X86_64 I'd consider AArch64
(ARM64) and MSVC next.

Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N4OKG5Y4TY2VMOJRTTVMLJ3U2LDK3DJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Larry Hastings


On 10/21/20 5:58 AM, Petr Viktorin wrote:
At the risk of going off topic: That's for GCC. As far as I know, MSVC 
uses something like __declspec( thread ).

What are the options for generic C99 compilers, other than staying slow?



As a practical matter: does CPython even support "generic C99 
compilers"?  AFAIK we support three specific compilers: GCC, Clang, and 
MSVC.


(Maybe we also support icc?  I think mostly because it supports GCC 
language extensions.)



//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FLFDFSZCNVRKRFYBJ72NAN2YOHFD2GD6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Ronald Oussoren via Python-Dev



> On 21 Oct 2020, at 14:39, Larry Hastings  wrote:
> 
> On 10/21/20 4:04 AM, Antoine Pitrou wrote:
>> (apart from small fixes relating to borrowed references, and
>> that's mostly to make PyPy's life easier).
> 
> Speaking as the Gilectomy guy: borrowed references are evil.  The definition 
> of the valid lifetime of a borrowed reference doesn't exist, because they are 
> a hack (baked into the API!) that we mostly "get away with" just because of 
> the GIL.  If I still had wishes left on my monkey's paw I'd wish them away*.
> 
> 
Even with the GIL borrowed references are problematic. There are a lot of cases 
where using a borrowed reference after calling an API that might run Python 
code might invalidate the borrowed reference. In general the only safe thing to 
do with a borrowed reference is to turn it into a strong reference as soon as 
possible.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
> 
> /arry
> 
> * Unfortunately, I used my last wish back in February, wishing I could spend 
> more time at home.
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/PRIVTI2RFGEGVNQRGUCHRRY5WBJNZKJS/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PV3DSRZVS4JLYTGU5Z6JPBKDZT4X4QY5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Steve Holden

On Wed, Oct 21, 2020 at 8:37 AM Paul Moore  wrote:

> On Wed, 21 Oct 2020 at 08:14, Christian Heimes 
> wrote:
> >
> > On 21/10/2020 00.14, Steven D'Aprano wrote:
> > > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> > >
> > >> What I don't see is where the money's coming from. It's fine to ask,
> > >> but will anyone come up with that sort of funding?
> > >
> > > I don't think Mark is asking for you or I to fund the exercise. He's
> > > asking for the PSF to fund it.
> >
> > No, he is not. Mark is asking the PSF to organize a fund raiser and keep
> > half the money.
>
> Right. I'd misinterpreted the fact that the PSF was to get half the
> money as meaning they weren't doing the fundraising. My
> misunderstanding, thanks for the clarification.
>
> Paul
>

In 2004 a single company paid me to organise the "Need for Speed" sprint,
held in Iceland. A lot was achieved, particularly in string searching and
the re module, though I can't honestly say how much impact it had on
"overall performance". The work we did with pybench that week definitely
moved Python benchmarking along some.

Sixteen years later, the PSF's income may be down due to external factors,
but its connectivity at a high level with Python users has improved
immeasurably. Need for Speed cost ~$300,000 in inflation-adjusted dollars.
If one relatively small trading house could fund at that level it seems
likely the PSF could fund this suggested a project quite separately from
its existing revenues as long as the development community was behind it
and prepared to help with materials for the "sell."
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/36A6PRABPZPI6OSNNC2ZACJVHNBT7DUD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Petr Viktorin

On 10/21/20 1:40 PM, Mark Shannon wrote:

Hi Petr,

On 21/10/2020 11:49 am, Petr Viktorin wrote:
Let me explain an impression I'm getting. It is *just one aspect* of
my opinion, one that doesn't make sense to me. Please tell me where it
is wrong.

In the C API, there's a somewhat controversial refactoring going on,
which involves passing around tstate arguments. I'm not saying [the
first discussion] was perfect, and there are still issues, but,
however flawed the "do-ocracy" process is, it is the best way we found
to move forward. No one who can/wants to do the work has a better
solution.

Later, Mark says there is an even better way – or at least, a less
intrusive one! In [the second discussion], he hints at it vaguely
(from that limited info I have, it involves switching to C11 and/or
using compiler-specific extensions -- not an easy change to do). But
frustratingly, Mark doesn't reveal any actual details, and a lot of
the complaints are about churn and merge conflicts.
And now, there's news -- the better solution won't be revealed unless
the PSF pays for it!

There's no secret. C thread locals are well documented.
I even provided a code example last time we discussed it.

You reminded me of it yesterday ;)
https://godbolt.org/z/dpSo-Q

At the risk of going off topic: That's for GCC. As far as I know, MSVC
uses something like __declspec( thread ).

What are the options for generic C99 compilers, other than staying slow?

The "even faster" solution I mentioned yesterday, is as I stated
yesterday to use an aligned stack.

If you wanted more info, you could have asked :)

First, you ensure that the stack is in a 2**N aligned block.
Assuming that the C stack grows down from the top, then the threadstate
struct goes at the bottom. It's probably a good idea to put a guard page
between the C stack and the threadstate struct.

The struct's address can then be found by masking off the bottom N bits
from the stack pointer.
This approach uses 0 registers and cost 1 ALU instruction. Can't get
cheaper than that :)

It's not portable and probably a pain to implement, but it is fast.

But it doesn't matter how it's implemented. The implementation is hidden
behind `PyThreadState_GET()`, it can be changed to use a thread local,

or to some fancy aligned stack, without the rest of the codebase changing.

Not portable and hard to implement is a pain for maintenance –
especially porting CPython to new compilers/platforms/situations.

The alternative is changing the codebase, which (it seems from the
discussions) would give us comparable performance, everywhere, and the
result can be maintained by many more people.

That's a very bad situation to be in for having discussions:
basically, either we disregard Mark and go with the not-ideal
solution, or virtually all work on changing the C API and internal
structures is blocked.

The existence of multiple interpreters should be orthogonal to speeding
up those interpreters, provided the separation is clean and well designed.

But it should be clean and well designed anyway, IMO.

I sense a similar thing happening here:
https://github.com/ericsnowcurrently/multi-core-python/issues/69 --

The title of that issue is 'Clarify what is a "sub-interpreter" and what
is an "interpreter"'?

there's a vague proposal to do things very differently, but I find it

This?
https://github.com/ericsnowcurrently/multi-core-python/issues/69#issuecomment-712837899

I'll continue there.

hard to find anything actionable. I would like to change my plans to
align with Mark's fork, or to better explain some of the
non-performance reasons for recent/planned changes. But I can't,
because details are behind a paywall.

Let's make this very clear.
My objections to the way multiple interpreters is being implemented has
very little to do speeding up the interpreter and entirely to do with
long term maintenance and ultimate success of the project.

Obviously, I would like it if multiple interpreters didn't slowdown
CPython.

But that has always been the case.

Thank you for clearing my doubts!

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/W5JF77HVMIJ3Q5RSL3R2TOJGZ4JEWJRS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Larry Hastings


On 10/21/20 4:04 AM, Antoine Pitrou wrote:

(apart from small fixes relating to borrowed references, and
that's mostly to make PyPy's life easier).



Speaking as the Gilectomy guy: borrowed references are evil.  The 
definition of the valid lifetime of a borrowed reference doesn't exist, 
because they are a hack (baked into the API!) that we mostly "get away 
with" just because of the GIL.  If I still had wishes left on my 
monkey's paw I'd wish them away*.



//arry/

* Unfortunately, I used my last wish back in February, wishing I could 
spend more time at home.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PRIVTI2RFGEGVNQRGUCHRRY5WBJNZKJS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Simon Cross

On Wed, Oct 21, 2020 at 4:28 AM Terry Reedy  wrote:
> I don't think the two projects are mutually exclusive.

100% agreed. I would even go as far as to say that HPy and other
proposals to improve Python are mutually beneficial. HPy aims to
remove dependencies between C extensions and Python internals, so that
Python internals can evolve more easily. Someone else still needs to
do the evolving.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LRNDTBSPIM26ITQPQJER3UPQPLKSO5SS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Mark Shannon

Hi Petr,

On 21/10/2020 11:49 am, Petr Viktorin wrote:
Let me explain an impression I'm getting. It is *just one aspect* of my
opinion, one that doesn't make sense to me. Please tell me where it is
wrong.

In the C API, there's a somewhat controversial refactoring going on,
which involves passing around tstate arguments. I'm not saying [the
first discussion] was perfect, and there are still issues, but, however
flawed the "do-ocracy" process is, it is the best way we found to move
forward. No one who can/wants to do the work has a better solution.

Later, Mark says there is an even better way – or at least, a less
intrusive one! In [the second discussion], he hints at it vaguely (from
that limited info I have, it involves switching to C11 and/or using
compiler-specific extensions -- not an easy change to do). But
frustratingly, Mark doesn't reveal any actual details, and a lot of the
complaints are about churn and merge conflicts.
And now, there's news -- the better solution won't be revealed unless
the PSF pays for it!

There's no secret. C thread locals are well documented.
I even provided a code example last time we discussed it.

You reminded me of it yesterday ;)
https://godbolt.org/z/dpSo-Q

The "even faster" solution I mentioned yesterday, is as I stated
yesterday to use an aligned stack.

If you wanted more info, you could have asked :)

The struct's address can then be found by masking off the bottom N bits
from the stack pointer.
This approach uses 0 registers and cost 1 ALU instruction. Can't get
cheaper than that :)

It's not portable and probably a pain to implement, but it is fast.

But it doesn't matter how it's implemented. The implementation is hidden
behind `PyThreadState_GET()`, it can be changed to use a thread local,

or to some fancy aligned stack, without the rest of the codebase changing.

That's a very bad situation to be in for having discussions: basically,
either we disregard Mark and go with the not-ideal solution, or
virtually all work on changing the C API and internal structures is
blocked.

The existence of multiple interpreters should be orthogonal to speeding
up those interpreters, provided the separation is clean and well designed.

But it should be clean and well designed anyway, IMO.

I sense a similar thing happening here:
https://github.com/ericsnowcurrently/multi-core-python/issues/69 --

The title of that issue is 'Clarify what is a "sub-interpreter" and what
is an "interpreter"'?

there's a vague proposal to do things very differently, but I find it

This?
https://github.com/ericsnowcurrently/multi-core-python/issues/69#issuecomment-712837899

hard to find anything actionable. I would like to change my plans to
align with Mark's fork, or to better explain some of the non-performance
reasons for recent/planned changes. But I can't, because details are
behind a paywall.

Obviously, I would like it if multiple interpreters didn't slowdown CPython.
But that has always been the case.

Cheers,
Mark.

[the first discussion]:
https://mail.python.org/archives/list/python-dev@python.org/thread/PQBGECVGVYFTVDLBYURLCXA3T7IPEHHO/#Q4IPXMQIM5YRLZLHADUGSUT4ZLXQ6MYY

[the second discussion]:
https://mail.python.org/archives/list/python-dev@python.org/thread/KGBXVVJQZJEEZD7KDS5G3GLBGZ6XNJJX/#WOKAUQYDJDVRA7SJRJDEAHXTRXSVPNMO

On 10/20/20 2:53 PM, Mark Shannon wrote:

Hi everyone,

CPython is slow. We all know that, yet little is done to fix it.

I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next
few years. But it needs funding.

I am aware that there have been several promised speed ups in the past
that have failed. You might wonder why this is different.

My ideas for possible funding, as well as the actual plan of
development, can be found here:

https://github.com/markshannon/faster-cpython

I'd love to hear your thoughts on this.

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Antoine Pitrou

On Wed, 21 Oct 2020 12:49:54 +0200
Petr Viktorin  wrote:
> 
> Later, Mark says there is an even better way – or at least, a less 
> intrusive one! In [the second discussion], he hints at it vaguely (from 
> that limited info I have, it involves switching to C11 and/or using 
> compiler-specific extensions -- not an easy change to do). But 
> frustratingly, Mark doesn't reveal any actual details, and a lot of the 
> complaints are about churn and merge conflicts.
> And now, there's news -- the better solution won't be revealed unless 
> the PSF pays for it!
> 
> That's a very bad situation to be in for having discussions: basically, 
> either we disregard Mark and go with the not-ideal solution, or 
> virtually all work on changing the C API and internal structures is blocked.

The disagreement is basically on the promises of the "not-ideal
solution".  Victor claims it will help improve performance.  People
like Mark and I are skeptical that the C API is really an important
concern (apart from small fixes relating to borrowed references, and
that's mostly to make PyPy's life easier).

Personally, I trust that Mark's proposed plan is workable.  That
doesn't mean it *will* work (that depends a lot on being able to
maintain motivation and integrate changes at a good pace - which may
be a challenge given the technical conservativeness in the CPython
community), but it's technically sound.

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SDGDVGCRGJOMXTQLXXJQ5IHM3L3WPYAU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Petr Viktorin

Let me explain an impression I'm getting. It is *just one aspect* of my
opinion, one that doesn't make sense to me. Please tell me where it is
wrong.

In the C API, there's a somewhat controversial refactoring going on,
which involves passing around tstate arguments. I'm not saying [the
first discussion] was perfect, and there are still issues, but, however
flawed the "do-ocracy" process is, it is the best way we found to move
forward. No one who can/wants to do the work has a better solution.

Later, Mark says there is an even better way – or at least, a less
intrusive one! In [the second discussion], he hints at it vaguely (from
that limited info I have, it involves switching to C11 and/or using
compiler-specific extensions -- not an easy change to do). But
frustratingly, Mark doesn't reveal any actual details, and a lot of the
complaints are about churn and merge conflicts.
And now, there's news -- the better solution won't be revealed unless
the PSF pays for it!

That's a very bad situation to be in for having discussions: basically,
either we disregard Mark and go with the not-ideal solution, or
virtually all work on changing the C API and internal structures is blocked.

I sense a similar thing happening here:
https://github.com/ericsnowcurrently/multi-core-python/issues/69 --
there's a vague proposal to do things very differently, but I find it
hard to find anything actionable. I would like to change my plans to
align with Mark's fork, or to better explain some of the non-performance
reasons for recent/planned changes. But I can't, because details are
behind a paywall.

[the first discussion]:
https://mail.python.org/archives/list/python-dev@python.org/thread/PQBGECVGVYFTVDLBYURLCXA3T7IPEHHO/#Q4IPXMQIM5YRLZLHADUGSUT4ZLXQ6MYY

[the second discussion]:
https://mail.python.org/archives/list/python-dev@python.org/thread/KGBXVVJQZJEEZD7KDS5G3GLBGZ6XNJJX/#WOKAUQYDJDVRA7SJRJDEAHXTRXSVPNMO

On 10/20/20 2:53 PM, Mark Shannon wrote:

Hi everyone,

CPython is slow. We all know that, yet little is done to fix it.

I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.

I am aware that there have been several promised speed ups in the past
that have failed. You might wonder why this is different.

My ideas for possible funding, as well as the actual plan of
development, can be found here:

https://github.com/markshannon/faster-cpython

I'd love to hear your thoughts on this.

Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RDXLCH22T2EZDRCBM6ZYYIUTBWQVVVWH/

Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7DKURFZ3JEZTKCUAUDCPR527FUBYMY7N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 11.37, Steven D'Aprano wrote:
> On Wed, Oct 21, 2020 at 09:06:58AM +0200, Christian Heimes wrote:
>> On 21/10/2020 00.14, Steven D'Aprano wrote:
>>> On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
>>>
 What I don't see is where the money's coming from. It's fine to ask,
 but will anyone come up with that sort of funding?
>>>
>>> I don't think Mark is asking for you or I to fund the exercise. He's 
>>> asking for the PSF to fund it.
>>
>> No, he is not. Mark is asking the PSF to organize a fund raiser and keep
>> half the money.
> 
> I think that's inaccurate. The funding.md document doesn't mention "fund 
> raiser", it doesn't specify how the PSF is to collect the funds, and I 
> wouldn't expect it to.

You are spreading FUD. Stop speculating and give Mark the benefit of a
doubt. This kind of negative attitude is a main cause of contributor
burnout.

If you are unsure about Mark's intentions and goals then please open an
issue on his repository.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NKJN6BPR737NENM4F4AGV6DZ7FTPPMBF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Chris Angelico

On Wed, Oct 21, 2020 at 8:23 PM Matti Picus  wrote:
> Just to set the record straight, PyPy has been available on conda-forge
> [0] since March, and has seen close to 70,000 downloads [1] from that
> channel alone, in addition to the downloads from
> https://downloads.python.org/pypy and the other channels where it is
> available. This is far from CPython's wild popularity, but people are
> successfully using it with the scientific python stack. It is true there
> is more work to be done, that does not mean it is useless.
>

When I go looking for PyPy performance stats, everything seems to be
Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or
whichever specific version)? Or maybe it's right there on
https://speed.pypy.org/ and I just can't see it - that's definitely
possible :)

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/V2P5LDQWLMRYP24Q7O7QE3S4YDLUQ224/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Steven D'Aprano

On Wed, Oct 21, 2020 at 09:06:58AM +0200, Christian Heimes wrote:
> On 21/10/2020 00.14, Steven D'Aprano wrote:
> > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> > 
> >> What I don't see is where the money's coming from. It's fine to ask,
> >> but will anyone come up with that sort of funding?
> > 
> > I don't think Mark is asking for you or I to fund the exercise. He's 
> > asking for the PSF to fund it.
> 
> No, he is not. Mark is asking the PSF to organize a fund raiser and keep
> half the money.

I think that's inaccurate. The funding.md document doesn't mention "fund 
raiser", it doesn't specify how the PSF is to collect the funds, and I 
wouldn't expect it to.

The PSF has various income streams, one of which is donations, and how 
they collect the money for this proposal is up to them, not Mark. If the 
PSF decide that the best way to make the money is to have a bake sale, 
that's their prerogative. The *how* is not really relevant or up to us 
(except to the degree that some of us may be members of the PSF).

And they won't be *keeping* half the money, they will be spending it on 
on-going maintenance. (Or at least that is Mark's expectation.) So the 
intent is for the money to be spent at some point, and not for general 
expenses, but specifically on this project.

-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U4S7JVWAD2FM4ZYPCJ774GODM2OGOSB2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Matti Picus

On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano st...@pearwood.info 
 wrote:


> some insulting FUD that is not worth repeating, and an apology


Just to set the record straight, PyPy has been available on conda-forge 
[0] since March, and has seen close to 70,000 downloads [1] from that 
channel alone, in addition to the downloads from 
https://downloads.python.org/pypy and the other channels where it is 
available. This is far from CPython's wild popularity, but people are 
successfully using it with the scientific python stack. It is true there 
is more work to be done, that does not mean it is useless.



It is in CPython's interest to have a viable alternative interpreter for 
many reasons. The code of conduct [3] should guide discourse when 
relating to all people and projects in the Python ecosystem, not just 
internally to CPython.


Matti


[0] https://conda-forge.org/blog/posts/2020-03-10-pypy/

[1] https://anaconda.org/conda-forge/pypy3.6

[2] https://www.python.org/psf/conduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MPU2RYONWC4KHXEJ5D4VHHNSICIDY6LD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 09.35, Paul Moore wrote:
> On Wed, 21 Oct 2020 at 08:14, Christian Heimes  wrote:
>>
>> On 21/10/2020 00.14, Steven D'Aprano wrote:
>>> On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
>>>
 What I don't see is where the money's coming from. It's fine to ask,
 but will anyone come up with that sort of funding?
>>>
>>> I don't think Mark is asking for you or I to fund the exercise. He's
>>> asking for the PSF to fund it.
>>
>> No, he is not. Mark is asking the PSF to organize a fund raiser and keep
>> half the money.
> 
> Right. I'd misinterpreted the fact that the PSF was to get half the
> money as meaning they weren't doing the fundraising. My
> misunderstanding, thanks for the clarification.

You are welcome! IMHO you got it right in your initial posting.

I'm irritated that Steven is spreading FUD although Mark's documents
clearly states his intention [1]:

The PSF seems to be the obvious organization to coordinate funding.

Mark is asking the PSF to organize a fund raiser and to act as a
trustee. This is the most logical and reasonable approach. We don't want
to have another requests incident, do we? For stage 2-4 Mark is also
willing to put his reputation and financial security in jeopardy *and*
give the PSF half of the income in exchange for little risk.

Christian

[1] https://github.com/markshannon/faster-cpython/blob/master/funding.md
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5JEPPD4ZFHSPLMBOFF4F444HG72M3E2M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Antoine Pitrou

On Tue, 20 Oct 2020 16:10:27 +0100
Mark Shannon  wrote:
> Hi Antoine,
> 
> On 20/10/2020 2:32 pm, Antoine Pitrou wrote:
> > On Tue, 20 Oct 2020 13:53:34 +0100
> > Mark Shannon  wrote:  
> >> Hi everyone,
> >>
> >> CPython is slow. We all know that, yet little is done to fix it.
> >>
> >> I'd like to change that.
> >> I have a plan to speed up CPython by a factor of five over the next few
> >> years. But it needs funding.
> >>
> >> I am aware that there have been several promised speed ups in the past
> >> that have failed. You might wonder why this is different.
> >>
> >> Here are three reasons:
> >> 1. I already have working code for the first stage.
> >> 2. I'm not promising a silver bullet. I recognize that this is a
> >> substantial amount of work and needs funding.
> >> 3. I have extensive experience in VM implementation, not to mention a
> >> PhD in the subject.
> >>
> >> My ideas for possible funding, as well as the actual plan of
> >> development, can be found here:
> >>
> >> https://github.com/markshannon/faster-cpython  
> > 
> > Do you plan to do all this in C, or would you switch to C++ (or
> > something else)?  
> 
> All C, no C++. I promise :)

Interesting, I was mostly expecting/suggesting the opposite.  Once you
pass a certain level of complexity, C is really a burden.

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/H7665MH2KQ7W5NEZW2BMS3AD4EP2NFGK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Paul Moore

On Wed, 21 Oct 2020 at 08:14, Christian Heimes  wrote:
>
> On 21/10/2020 00.14, Steven D'Aprano wrote:
> > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> >
> >> What I don't see is where the money's coming from. It's fine to ask,
> >> but will anyone come up with that sort of funding?
> >
> > I don't think Mark is asking for you or I to fund the exercise. He's
> > asking for the PSF to fund it.
>
> No, he is not. Mark is asking the PSF to organize a fund raiser and keep
> half the money.

Right. I'd misinterpreted the fact that the PSF was to get half the
money as meaning they weren't doing the fundraising. My
misunderstanding, thanks for the clarification.

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N6PBKMDETBSZURV6KOKCARHRJBZCMVDW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 00.14, Steven D'Aprano wrote:
> On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> 
>> What I don't see is where the money's coming from. It's fine to ask,
>> but will anyone come up with that sort of funding?
> 
> I don't think Mark is asking for you or I to fund the exercise. He's 
> asking for the PSF to fund it.

No, he is not. Mark is asking the PSF to organize a fund raiser and keep
half the money.

Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TOKFADEIOASTU3KMAIMYA226TIJ6IM3T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-21 Thread Stefan Ring

On Wed, Oct 21, 2020 at 3:51 AM Gregory P. Smith  wrote:
>
> meta: i've written too many words and edited so often i can't see my own 
> typos and misedits anymore.  i'll stop now. :)

Haha! Very interesting background, thank you for writing down all of this!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CFC4XSS5AR2MBEDSQTNTL4GKH63RKVRZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread Terry Reedy


On 10/20/2020 2:49 PM, Dan Stromberg wrote:

I suspect what it needs most is HPY work, which could benefit a lot of 
Python language implementations in the long term:

https://github.com/hpyproject/hpy

$2e6 spent on HPY could be pretty amazing.


I don't think the two projects are mutually exclusive. I would like to 
see the PSF raise and spend a few million a year on improvements.



--
Terry Jan Reedy
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QXYIROIWMSZ4ZHF23C5TCHO2DFLQVZAZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread Gregory P. Smith

On Tue, Oct 20, 2020 at 5:59 AM Mark Shannon  wrote:

> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> I am aware that there have been several promised speed ups in the past
> that have failed. You might wonder why this is different.
>
> Here are three reasons:
> 1. I already have working code for the first stage.
> 2. I'm not promising a silver bullet. I recognize that this is a
> substantial amount of work and needs funding.
> 3. I have extensive experience in VM implementation, not to mention a
> PhD in the subject.
>
> My ideas for possible funding, as well as the actual plan of
> development, can be found here:
>
> https://github.com/markshannon/faster-cpython
>
> I'd love to hear your thoughts on this.
>
> Cheers,
> Mark.
>

+1

Overall I think you are making quite a reasonable proposal.  It sounds
like effectively bringing your hotpy2 concepts into the CPython interpreter
with an intent to help maintain them over the long term.

People worried that you are doing this out of self interest may not know
who you are.  Sure, you want to be paid to do work that you appear to love
and have been mulling over for a decade+.  There is nothing wrong with
that.  Payment is proposed as on delivery per phase.  I like the sound of
that, nice!

Challenges I expect we'll face, that seem tractable to me, are mostly
around what potential roadblocks we, us existing python-committers and our
ultimate decider steering council might introduce intentionally or not that
prevents landing such work.  Payment on delivery helps that a lot, if we
opt out of some work, it is both our losses.  One potential outcome is that
you'd burn out and go away if we didn't accept something meaning payment
wasn't going to happen.  That already happens amongst all core devs today
so I don't have a problem with this even though it isn't what we'd
rightfully want to happen.  Middle grounds are quite reasonable
renegotiations.  The deciders on this would be the PSF (because money) and
the PSF would presumably involve the Steering Council in decisions of terms
and judgements.

Some background materials for those who don't already know Mark's past work
along these lines that is where this proposal comes from:
  https://sites.google.com/site/makingcpythonfast/ (hotpy)
  and the associated presentation in 2012:
https://www.youtube.com/watch?v=c6PYnZUMF7o

The amount of money seems entirely reasonable to me. Were it to be taken
on, part of the PSF's job is to drum up the money. This would be a contract
with outcomes that could effectively be sold to funders in order to do so.
There are many companies who use CPython a lot that we could solicit
funding from, many of whom have employees among our core devs already. Will
they bite? It doesn't even have to be from a single source or be all
proposed phases up front, that is what the PSF exists to decide and
coordinate on.

We've been discussing on and off in the past many years how to pay people
for focused work on CPython and the ecosystem and balance that with being
an open source community project.  We've got some people employed along
these lines already, this would become more of that and in many ways just
makes sense to me.

Summarizing some responses to points others have brought up:

Performance estimates:
 * Don't fret about claimed speedups of each phase.  We're all going to
doubt different things or expect others to be better.  The proof is
ultimately in the future pudding.

JIT topics:
 * JITs rarely stand alone. The phase 1+2 improved interpreter will always
exist. It is normal to start with an interpreter for fast startup and
initial tracing before performing JIT compilations, and as a fallback
mechanism when the JIT isn't appropriate or available. (my background:
Transmeta. We had an Interpreter and at least two levels of Translators
behind our x86 compatible CPUs, all were necessary)
 * Sometimes you simply want to turn tracing and jit stuff off to save
memory. That knob always winds up existing. If nothing else it is normal to
run our test suite with such a knob in multiple positions for proper
coverage.
 * It is safe to assume any later phase actual JIT would target at least
one important platform (ex: amd64 or aarch64) and if successful should
easily elicit contributions supporting others either as work or as funding
to create it.

"*Why this, why not fund XyZ?*" whataboutism:
 * This conversation is separate from other projects. The way attracting
funding for a project works can involve spelling out what it is for. It
isn't my decision, but I'd be amazed if anything beyond maybe phase 1 came
solely out of a PSF general no obligation fund. CPython is the most used
Python VM in the world. A small amount of funding is not going to get
maintainers and users to switch to PyPy.  There is unlikely to be a major
this or

[Python-Dev] Re: Speeding up CPython

On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:

> What I don't see is where the money's coming from. It's fine to ask,
> but will anyone come up with that sort of funding?

I don't think Mark is asking for you or I to fund the exercise. He's 
asking for the PSF to fund it.

I think that Mark's asking price is perhaps a bit optimistic. With the 
Covid-19 pandemic, lock downs and shutting down of international travel, 
I expect that PSF conference income will be way down. And income in the 
previous financial year was not exactly at Facebook levels:

Revenue: $3.1 million
Expences: $2.6 million

Nett income: $52

https://www.python.org/psf/annual-report/2019/

Mark is asking for half of that, justified that this is the going rate 
for a full-time developer at one of the top tier tech firms.

-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IZGFSDJMVO7UWWPD2WEHUPIVN6SATEJB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread Simon Cross

Since HPy was mentioned, hello from the HPy team!

If anyone is thinking about Python performance or new Python VMs, we'd
love them to take a look at HPy and come and talk to us. HPy is meant
to provide a new C API layer that any Python VM could implement in
order to efficiently support Python extensions written on top of HPy.
Amazingly, such extensions would also be backwards compatible (i.e.
they would also run on CPython as it exists today).

If you'd like to talk to us (and we would like to talk to you) you can
find us at:

* Mailing list: hpy-...@python.org
* IRC: hpy-...@python.org

If you would like to contribute as a developer (or any other way),
we're here to help (and at the moment I am prioritising landing other
people's contributions pretty much full-time).

If someone has money to donate, they can donate to the project at
https://opencollective.com/hpy/contribute. We have quite a few
contributors who could contribute more time than they do in exchange
for money.

HPy is currently in quite an early stage of development (we can
already run some simple Python C extensions without any performance
penalties on CPython). The upside is that right now we can consider
almost any suggestion for improving HPy because none of the design is
set in stone. In a few months it might be helpful to have people try
porting some (many) C extensions to HPy to see how that goes.

Yours happily,
Simon Cross (random person working on HPy)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ARSII7KMZZ5W6UMKR7LIQDIWFSWWYQLZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread Kevin Modzelewski

I'd love to hear more about what workloads you're targeting and how you
came up with the anticipated numbers for the improvements.  For comparison,
our new jit provides a single-digit-percentage speedup on our django and
flask benchmarks.

On Tue, Oct 20, 2020 at 9:03 AM Mark Shannon  wrote:

> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> I am aware that there have been several promised speed ups in the past
> that have failed. You might wonder why this is different.
>
> Here are three reasons:
> 1. I already have working code for the first stage.
> 2. I'm not promising a silver bullet. I recognize that this is a
> substantial amount of work and needs funding.
> 3. I have extensive experience in VM implementation, not to mention a
> PhD in the subject.
>
> My ideas for possible funding, as well as the actual plan of
> development, can be found here:
>
> https://github.com/markshannon/faster-cpython
>
> I'd love to hear your thoughts on this.
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RDXLCH22T2EZDRCBM6ZYYIUTBWQVVVWH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QPQSR5UNTGLEL3GFQXQW4LA2OQX76YOG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread Dan Stromberg

On Tue, Oct 20, 2020 at 9:33 AM Steven D'Aprano  wrote:

> > What would happen if $2M were spent on improving PyPy3 instead?
>
> Then both of the PyPy3 users will be very happy *wink*
>

Wow, I didn't know I was 50% of Pypy3 users :)

Anyway, Pypy3 is already pretty great.  I'm sure it can be improved, but I
suspect what it needs most is HPY work, which could benefit a lot of Python
language implementations in the long term:
https://github.com/hpyproject/hpy

$2e6 spent on HPY could be pretty amazing.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OJCDOMSSK2DICZARJZMZ2SOQAKIDPZ4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On 20/10/2020 5:48 pm, Chris Angelico wrote:

On Wed, Oct 21, 2020 at 3:31 AM Mark Shannon wrote:

Hi Chris,

On 20/10/2020 4:37 pm, Chris Angelico wrote:

On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:

Hi everyone,

CPython is slow. We all know that, yet little is done to fix it.

I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.

The overall aim is to speed up CPython by a factor of (approximately) five. We
aim to do this in four distinct stages, each stage increasing the speed of
CPython by (approximately) 50%.

This is a very bold estimate. Particularly, you're proposing a number
of small tweaks in stage 2 and expecting that (combined) they can give
a 50% improvement in overall performance?

20 tweaks each providing a 2% is a 49% speedup.
Stage 1 will open up optimizations that are currently worthwhile.

Yes, I understand mathematics. Do you have evidence that shows that
each of the twenty tweaks can give a two percent speedup though?

My point was that small changes can easily add up to a large change.
And yes, I have a long list of possible small optimizations.

Do you have any details to back this up? You're not just asking for a
proposal to be accepted, you're actually asking for (quite a bit of)
money, and then hoping to find a contractor to do the actual work.

I am offering to do the work.

Sure, that takes away some of the uncertainty, but you're still asking
for a considerable amount of money sight-unseen.

I'm not asking for money up front. I'm asking for some promise of
payment, once the work is done. If I fail, only I suffer a loss.

BIG BIG concern: You're basically assuming that all this definition of
performance is measured for repeated executions of code. That's how
PyPy already works, and it most often suffers quite badly in startup
performance to make this happen. Will your proposed changes mean that
CPython has to pay the same startup costs that PyPy does?

Could you clarify what you think I'm assuming?

When you say start up, do you mean this?

$ time python3 -S -c ""

real0m0.010s

$ time pypy -S -c ""

real0m0.017s

No, there would be no slower startup. In fact the tier 0 interpreter
should start a fraction faster than 3.9.

That's a microbenchmark, but yes, that's the kind of thing I'm talking
about. For short scripts, will "python3.13 script.py" be slower than
"python3.9 script.py"?

Tiered execution means that 3.10+ should be no slower than 3.9 for any
program, and faster for all but really short ones. Tier 0 would be a bit
slower than 3.9, but will start faster. Tier 1 should kick in before 3.9
would catch up.

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread Paul Moore

On Tue, 20 Oct 2020 at 14:01, Mark Shannon  wrote:
>
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> I am aware that there have been several promised speed ups in the past
> that have failed. You might wonder why this is different.
>
> Here are three reasons:
> 1. I already have working code for the first stage.
> 2. I'm not promising a silver bullet. I recognize that this is a
> substantial amount of work and needs funding.
> 3. I have extensive experience in VM implementation, not to mention a
> PhD in the subject.
>
> My ideas for possible funding, as well as the actual plan of
> development, can be found here:
>
> https://github.com/markshannon/faster-cpython
>
> I'd love to hear your thoughts on this.

A very blunt (apologies if it's too blunt) restatement of this
proposal (at least stage 1) seems to me to be

"Give me $250k, and donate $250k to the PSF for ongoing support, and
I'll let you have code that I've already written that gives CPython a
50% speedup. If my code doesn't deliver a 50% speedup, I'll give the
money back. No money, no code. We can also discuss 3 more incremental
steps of the same sort of magnitude, but I don't have code already
written for them".

Honestly, if someone's able to get together $500k, that sounds like a
fairly good deal (no risk). If you're asking for a commitment to the
full $2M, even if stages 2-4 are contingent on delivery, that's a bit
of a harder ask (because the cashflow implication of committing that
sort of money becomes relevant). But maybe someone can do it.

I'm fine with this, I guess. I don't have $500k to offer myself, so
all my agreement is worth is that I don't have a problem with this
much work being funded/provided via one big donation. I assume that
part of "delivery" would involve code review, etc. - we wouldn't be
bypassing normal development workflow. So there's still work to be
done in putting the code through review, responding to review
comments, etc, and ensuring that the code is delivered in a form that
the core devs are happy to maintain (PSF donation for support
notwithstanding). Actually, a chunk of that support allocation to the
PSF might be needed to pay for reviewers, if (as I suspect) this is a
large and complex PR.

What I don't see is where the money's coming from. It's fine to ask,
but will anyone come up with that sort of funding?

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DNM27AX7Z3VULDY7XNJPVZYFX6Z5FTRZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano  wrote:
>
> On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote:
>
> > Do you have any details to back this up? You're not just asking for a
> > proposal to be accepted, you're actually asking for (quite a bit of)
> > money, and then hoping to find a contractor to do the actual work.
>
> Payment is on delivery. At each stage, if the contractor fails to
> deliver the promised gains, they get nothing.
>
> (I believe that Mark is being polite by referring to a generic
> contractor. I think he is referring to himself.)

It's a little unclear from the proposal, as there was something about
whether a suitable contractor could be found, but sure. TBH I'd be
happier with this proposal as a direct offer/request for money than as
"hey let's go look for potential coders", but it sounds like that's
the plan anyway?

> > That means you're expecting that anyone would be able to achieve this,
> > given sufficient development time.
>
> With sufficient time, maybe the horse will learn to sing.
>
> https://everything2.com/title/And+maybe+the+horse+will+learn+how+to+sing
>
> But I don't think Mark believes *anyone* will be able to improve
> performance. If it were that easy that anyone could do it, Python would
> already be blazingly fast.

Yeah. And the "anyone" part is the concern I had - that the proposal
was asking for funding and then for a search for a contractor. But if
it's "pay me and I'll write this", then it's a bit more concrete.

> > BIG BIG concern: You're basically assuming that all this definition of
> > performance is measured for repeated executions of code.
>
> That's not what the proposal says.
>
> "Performance should improve for all code, not just loop-heavy and
> numeric code."
>
> In fact Mark goes further: he says that he's willing to allow some
> performance degradation on loop heavy code, if the overall performance
> increases.

"Overall performance" is a myth, and there's no way that CPython will
magically be able to execute any code with the exact same performance
improvement. So my question is: what happens to startup performance,
what happens to short scripts, what happens to the interpreter's load
times, etc, etc, etc? It could be that all code becomes faster, but
only after it's been run a few times. That would be great for, say, a
web app - it handles a request, goes back and waits for another, and
then handles the next one a bit faster - but not for a command-line
script.

(And yes, I'm aware that it'd theoretically be possible to dump the
compiler state to disk, but that has its own risks.)

> > What would happen if $2M were spent on improving PyPy3 instead?
>
> Then both of the PyPy3 users will be very happy *wink*
>
> (I know, that's a terrible, horrible, inaccurate slight on the PyPy
> community, which is very probably thriving, and I would delete it if I
> hadn't already hit Send.)

Yes, you're being horribly insulting to the third user of PyPy3, who
is probably right now warming up his interpreter so he can send you an
angry response :)

I guess my biggest concern with this proposal is that it's heavy on
mathematically pure boasts and light on actual performance metrics,
and I'm talking here about the part where (so we're told) the code is
all done and it just takes a swipe of a credit card to unlock it. And
without the ability to run it myself, I can't be sure that it'd
actually give *any* performance improvement on my code or use-cases.
So there's a lot that has to be taken on faith, and I guess I'm just a
bit dubious of how well it'd fulfil that.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4N4SSXNDAP2GZQSL7F2JBC2RJVZ3WEL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 3:31 AM Mark Shannon  wrote:
>
> Hi Chris,
>
> On 20/10/2020 4:37 pm, Chris Angelico wrote:
> > On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon  wrote:
> >>
> >> Hi everyone,
> >>
> >> CPython is slow. We all know that, yet little is done to fix it.
> >>
> >> I'd like to change that.
> >> I have a plan to speed up CPython by a factor of five over the next few
> >> years. But it needs funding.
> >>
> >
> >> The overall aim is to speed up CPython by a factor of (approximately) 
> >> five. We aim to do this in four distinct stages, each stage increasing the 
> >> speed of CPython by (approximately) 50%.
> >>
> >
> > This is a very bold estimate. Particularly, you're proposing a number
> > of small tweaks in stage 2 and expecting that (combined) they can give
> > a 50% improvement in overall performance?
>
> 20 tweaks each providing a 2% is a 49% speedup.
> Stage 1 will open up optimizations that are currently worthwhile.

Yes, I understand mathematics. Do you have evidence that shows that
each of the twenty tweaks can give a two percent speedup though?

> > Do you have any details to back this up? You're not just asking for a
> > proposal to be accepted, you're actually asking for (quite a bit of)
> > money, and then hoping to find a contractor to do the actual work.
>
> I am offering to do the work.

Sure, that takes away some of the uncertainty, but you're still asking
for a considerable amount of money sight-unseen.

> > BIG BIG concern: You're basically assuming that all this definition of
> > performance is measured for repeated executions of code. That's how
> > PyPy already works, and it most often suffers quite badly in startup
> > performance to make this happen. Will your proposed changes mean that
> > CPython has to pay the same startup costs that PyPy does?
>
> Could you clarify what you think I'm assuming?
>
> When you say start up, do you mean this?
>
> $ time python3 -S -c ""
>
> real0m0.010s
>
> $ time pypy -S -c ""
>
> real0m0.017s
>
> No, there would be no slower startup. In fact the tier 0 interpreter
> should start a fraction faster than 3.9.

That's a microbenchmark, but yes, that's the kind of thing I'm talking
about. For short scripts, will "python3.13 script.py" be slower than
"python3.9 script.py"?

> > What would happen if $2M were spent on improving PyPy3 instead?
>
> The PSF loses $1M to spend on CPython maintenance, to start with.
>
> What would happen to PyPy? I have no idea.
>
> Partial success of speeding up CPython is very valuable.
> Partial success in getting PyPy to support C extensions well and perform
> well when it currently does, is much less valuable.
>
> CPython that is "only" 2 or 3 times faster is a major improvement, but a
> PyPy that supports 80% of the C extensions that it currently does not is
> still not a replacement for CPython.
>

True, but it does sound like you're pushing for the sorts of changes
that PyPy already has. Not sure whether your proposed changes would be
better done to PyPy or to CPython.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/I4XKZNAZBLPWCRS5EQ4UY6DMV3LDMJPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 02:38:25AM +1100, Chris Angelico wrote:
> On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano  wrote:
> > A minor point, and I realise that the costs are all in very round
> > figures, but they don't quite match up: $2 million split over five
> > stages is $400K per stage, not $500K.
> 
> The proposal is for four stages.

D'oh!

I mean, I knew that, I was just checking to see if others were paying 
attention. Well done, you pass!

-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UZFNJK636NJQOSURFW5ANZJS5F76LITU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote:

> Do you have any details to back this up? You're not just asking for a
> proposal to be accepted, you're actually asking for (quite a bit of)
> money, and then hoping to find a contractor to do the actual work.

Payment is on delivery. At each stage, if the contractor fails to 
deliver the promised gains, they get nothing.

(I believe that Mark is being polite by referring to a generic 
contractor. I think he is referring to himself.)

> That means you're expecting that anyone would be able to achieve this,
> given sufficient development time.

With sufficient time, maybe the horse will learn to sing.

https://everything2.com/title/And+maybe+the+horse+will+learn+how+to+sing

But I don't think Mark believes *anyone* will be able to improve 
performance. If it were that easy that anyone could do it, Python would 
already be blazingly fast.

> BIG BIG concern: You're basically assuming that all this definition of
> performance is measured for repeated executions of code. 

That's not what the proposal says.

"Performance should improve for all code, not just loop-heavy and 
numeric code."

In fact Mark goes further: he says that he's willing to allow some 
performance degradation on loop heavy code, if the overall performance 
increases.

But why are we nitpicking Stage Two? The beauty of Mark's proposal is:

1. there is no committment to any stage until the previous stage is 
complete;

2. there is no committment to pay for any stage unless the contractor 
actually delivers the goods.

If you don't think that Mark, or the contractor, will be able to deliver 
a 50% speed up in Stage 2, what have you got to lose? If he fails to 
deliver, you pay nothing and don't commit to Stage 3. If he does 
deliver, you get the desired result.

(The details allow for some slack: if the speed up is only 49%, the 
contractor still gets paid. Presumably it will be on some sort of 
sliding scale.)

> That's how
> PyPy already works, and it most often suffers quite badly in startup
> performance to make this happen. Will your proposed changes mean that
> CPython has to pay the same startup costs that PyPy does?

Good question.

> What would happen if $2M were spent on improving PyPy3 instead?

Then both of the PyPy3 users will be very happy *wink*

(I know, that's a terrible, horrible, inaccurate slight on the PyPy 
community, which is very probably thriving, and I would delete it if I 
hadn't already hit Send.)

I think this isn't a matter of just throwing money at a project. Mark 
knows the CPython architecture. I don't know if he knows the PyPy 
architecture, and unless a PyPy expert comes up with a counter proposal, 
we don't know that spending $2M on PyPy will see any sort of comparable 
gains.

-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WVVDCZ34LY5UD6LEZBH33GFP7BSMFTRL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

Hi Chris,

On 20/10/2020 4:37 pm, Chris Angelico wrote:

On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:

Hi everyone,

CPython is slow. We all know that, yet little is done to fix it.

I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.

The overall aim is to speed up CPython by a factor of (approximately) five. We
aim to do this in four distinct stages, each stage increasing the speed of
CPython by (approximately) 50%.

This is a very bold estimate. Particularly, you're proposing a number
of small tweaks in stage 2 and expecting that (combined) they can give
a 50% improvement in overall performance?

20 tweaks each providing a 2% is a 49% speedup.
Stage 1 will open up optimizations that are currently worthwhile.

I am offering to do the work.

That means you're expecting that anyone would be able to achieve this,
given sufficient development time.

No, I can (with paid help) achieve this.
What matters is that someone can, not that anyone can.

Could you clarify what you think I'm assuming?

When you say start up, do you mean this?

$ time python3 -S -c ""

real0m0.010s

$ time pypy -S -c ""

real0m0.017s

No, there would be no slower startup. In fact the tier 0 interpreter
should start a fraction faster than 3.9.

What would happen if $2M were spent on improving PyPy3 instead?

The PSF loses $1M to spend on CPython maintenance, to start with.

What would happen to PyPy? I have no idea.

Partial success of speeding up CPython is very valuable.
Partial success in getting PyPy to support C extensions well and perform
well when it currently does, is much less valuable.

CPython that is "only" 2 or 3 times faster is a major improvement, but a
PyPy that supports 80% of the C extensions that it currently does not is
still not a replacement for CPython.

Cheers,
Mark.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/3NBP3KLTMXNDJ2ME4QPSATW2ZIMKVICG/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/575BK2RBWDGXL4DNRJO5AM3GLXRCH45Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano  wrote:
> A minor point, and I realise that the costs are all in very round
> figures, but they don't quite match up: $2 million split over five
> stages is $400K per stage, not $500K.

The proposal is for four stages.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DFFCUKWRBR557SWJEQPUFV6WEKWLFKKR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon  wrote:
>
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>

> The overall aim is to speed up CPython by a factor of (approximately) five. 
> We aim to do this in four distinct stages, each stage increasing the speed of 
> CPython by (approximately) 50%.
>

This is a very bold estimate. Particularly, you're proposing a number
of small tweaks in stage 2 and expecting that (combined) they can give
a 50% improvement in overall performance?

Do you have any details to back this up? You're not just asking for a
proposal to be accepted, you're actually asking for (quite a bit of)
money, and then hoping to find a contractor to do the actual work.
That means you're expecting that anyone would be able to achieve this,
given sufficient development time.

BIG BIG concern: You're basically assuming that all this definition of
performance is measured for repeated executions of code. That's how
PyPy already works, and it most often suffers quite badly in startup
performance to make this happen. Will your proposed changes mean that
CPython has to pay the same startup costs that PyPy does?

What would happen if $2M were spent on improving PyPy3 instead?

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3NBP3KLTMXNDJ2ME4QPSATW2ZIMKVICG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

On 20/10/2020 2:47 pm, Steven D'Aprano wrote:

A very interesting proposal.

A couple of thoughts...

Can we have an executive summary of how your proposed approach differs
from those of PyPy, Unladen Swallow, and various other attempts?

https://github.com/markshannon/faster-cpython/blob/master/tiers.md
should cover it.

You suggest that payment should be on delivery, or meeting the target,
rather than up-front. That's good for the PSF, but it also means that
the contractor not only takes all the risk of failure, but also needs an
independent source of income, or at least substantial savings (enough
for, what, eighteen months development per stage?). Doesn't that limit
the available pool of potential contractors?

We only need one.
I don't think financial constraints are the main problem.
I think domain knowledge is probably more of a constraint.

I think there's always tension between community driven development and
paid work. If the PSF pays person A to develop something, might not
people B, C, D and E feel slighted that they didn't get paid?

The PSF already pays people to work on PyPI

On the other hand, I guess we already deal with that. There are devs who
are paid by their employers to work on Python for N hours a months, for
some value of N, or to develop something and then open source it. And
then there are devs who aren't.

You have suggested that the cost of each stage be split 50:50 between
development and maintenance. But development is a one-off cost;
maintenance is an forever cost, and unpredictable, and presumably some
of that maintenance will be done by people other than the contractor.

Any new feature will require ongoing maintenance. I'm just suggesting
that we budget for it.

Who is going to pay for the maintenance of PEP 634?

A minor point, and I realise that the costs are all in very round
figures, but they don't quite match up: $2 million split over five
stages is $400K per stage, not $500K.

I meant four stages. Did I write "five" somewhere?

1. I already have working code for the first stage.

I don't mean to be negative, or hostile, but this sounds like you are
saying "I have a patch for Python that will make it 1.5 times faster,
but you will never see it unless you pay me!"

I believe that's how business works ;)
I have this thing, e.g an iPhone, if you want it you must pay me.
I think that speeding CPython 50% is worth a few hundred iPhones.

I realise that is a very uncharitable way of looking at it, sorry about
that, it's nothing personal. But $500K is a lot of money.

Remember the contractor only gets roughly half of that. The rest stays
with the PSF to fund maintenance of CPython.

$250k only pays for one engineer for one year at one of the big tech firms.

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread Matthias Klose

On 10/20/20 2:53 PM, Mark Shannon wrote:
> I'd love to hear your thoughts on this.

a VM needs a separate backend for each architecture (maybe even OS)

 - which architectures do you include into your proposal?
   what's your estimate for a new port?

 - do you plan for a fall-back to a slow non-VM mode, e.g.
   the existing one?  Do you plan to support that in parallel
   such that Python still can be used on architectures with
   a working compiler (and a libffi port).

   E.g. OpenJDK has the zero port, which is slow (interpreted),
   but runs on practically all architectures.

Thanks, Matthias
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/H4O5TFWGL5SDG4NSESNGNKIZMK6W7L7V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython


Hi Antoine,

On 20/10/2020 2:32 pm, Antoine Pitrou wrote:

On Tue, 20 Oct 2020 13:53:34 +0100
Mark Shannon  wrote:

Hi everyone,

CPython is slow. We all know that, yet little is done to fix it.

I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.

I am aware that there have been several promised speed ups in the past
that have failed. You might wonder why this is different.

Here are three reasons:
1. I already have working code for the first stage.
2. I'm not promising a silver bullet. I recognize that this is a
substantial amount of work and needs funding.
3. I have extensive experience in VM implementation, not to mention a
PhD in the subject.

My ideas for possible funding, as well as the actual plan of
development, can be found here:

https://github.com/markshannon/faster-cpython


Do you plan to do all this in C, or would you switch to C++ (or
something else)?


All C, no C++. I promise :)

Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DZUH4PSWAD7MFVVXS3RBYFHVTCFLC4ZA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

2020-10-20 Thread edwin

Where is your working code for the first stage?

October 20, 2020 8:53 AM, "Mark Shannon"  wrote:

> Hi everyone,
> 
> CPython is slow. We all know that, yet little is done to fix it.
> 
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few 
> years. But it needs
> funding.
> 
> I am aware that there have been several promised speed ups in the past that 
> have failed. You might
> wonder why this is different.
> 
> Here are three reasons:
> 1. I already have working code for the first stage.
> 2. I'm not promising a silver bullet. I recognize that this is a substantial 
> amount of work and
> needs funding.
> 3. I have extensive experience in VM implementation, not to mention a PhD in 
> the subject.
> 
> My ideas for possible funding, as well as the actual plan of development, can 
> be found here:
> 
> https://github.com/markshannon/faster-cpython
> 
> I'd love to hear your thoughts on this.
> 
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RDXLCH22T2EZDRCBM6ZYYIUTBWQVVVWH
> Code of Conduct: http://python.org/psf/codeofconduct
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DXTPGPEKDJTVLEWWMD2JT7HAWD7P6K5E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython