Mailing List Archive

On Tue, 20 Oct 2020 16:10:27 +0100
Mark Shannon <mark@hotpy.org> wrote:
> Hi Antoine,
>
> On 20/10/2020 2:32 pm, Antoine Pitrou wrote:
> > On Tue, 20 Oct 2020 13:53:34 +0100
> > Mark Shannon <mark@hotpy.org> 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-leave@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/

On 21/10/2020 09.35, Paul Moore wrote:
> On Wed, 21 Oct 2020 at 08:14, Christian Heimes <christian@python.org> 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-leave@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/

On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano steve@pearwood.info
<mailto:steve@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-leave@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/

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-leave@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/

On Wed, Oct 21, 2020 at 8:23 PM Matti Picus <matti.picus@gmail.com> 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-leave@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/

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-leave@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/

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.
>
> 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-leave@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-leave@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/

On Wed, 21 Oct 2020 12:49:54 +0200
Petr Viktorin <encukou@gmail.com> 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-leave@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/

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 :)

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.

>
> 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.

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.

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.
>>
>> 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-leave@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-leave@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 mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/G3VXADDJ5OYEQHMHXG3GDEWCU733JMOT/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Oct 21, 2020 at 4:28 AM Terry Reedy <tjreedy@udel.edu> 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-leave@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/

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.

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.

+1

>> 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-leave@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/

On Wed, Oct 21, 2020 at 8:37 AM Paul Moore <p.f.moore@gmail.com> wrote:

> On Wed, 21 Oct 2020 at 08:14, Christian Heimes <christian@python.org>
> 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."

> On 21 Oct 2020, at 14:39, Larry Hastings <larry@hastings.org> 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-leave@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/

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/

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-leave@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/

A concern I have about this is what effect it will have on the
complexity of CPython's implementation.

CPython is currently very simple and straightforward. Some parts
are not quite as simple as they used to be, but on the whole it's
fairly easy to understand, and I consider this to be one of its
strengths.

I worry that adding four layers of clever speedup tricks will
completely destroy this simplicity, leaving us with something
that can no longer be maintained or contributed to by
ordinary mortals.

--
Greg
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/6XBJ2OA46KNMJ6FFI3B6RFYRTTD4HYOI/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Oct 21, 2020 at 4:04 PM Greg Ewing <greg.ewing@canterbury.ac.nz>
wrote:

> A concern I have about this is what effect it will have on the
> complexity of CPython's implementation.
>
> CPython is currently very simple and straightforward. Some parts
> are not quite as simple as they used to be, but on the whole it's
> fairly easy to understand, and I consider this to be one of its
> strengths.
>
> I worry that adding four layers of clever speedup tricks will
> completely destroy this simplicity, leaving us with something
> that can no longer be maintained or contributed to by
> ordinary mortals.
>

I have never considered ceval.c to be simple and straightforward. Nor our
parser(s). Or our optimizers. Or the regular expression implementation.
Or the subprocess internals. (we may differ on lists of what isn't simple
and straightforward, but i guarantee you we've all got something in mind)

Making this not a major concern for me.

We'd decide if there is something we find to be dark magic that seems
challenging to maintain during the review phases and decide what if
anything needs to be done about that to ameliorate such issues.

-gps


> --
> Greg
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/6XBJ2OA46KNMJ6FFI3B6RFYRTTD4HYOI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Hi Mark,

This sounds really cool. Can you give us more details? Some questions that
occurred to me while reading:

- You're suggesting that the contractor would only be paid if the desired
50% speedup is achieved, so I guess we'd need some objective Python
benchmark that boils down to a single speedup number. Did you have
something in mind for this?

- How much of the work has already been completed?

- Do you have any preliminary results of applying that work to that
benchmark? Even if it's preliminary, it would still help a lot in making
the case for this being a realistic plan.

-n

On Tue, Oct 20, 2020 at 6:00 AM Mark Shannon <mark@hotpy.org> 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-leave@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/
>


--
Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>

> On 20 Oct 2020, at 14:53, Mark Shannon <mark@hotpy.org> 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.

I don’t have anything useful to add to the discussion, other than to say that I’m happing to see that
someone is willing to spent a significant amount of effort on making CPython faster. Especially
when that someone has worked on faster Python implementation before (look for a HotPy talk at EuroPython).

I’m not too worried about the technical part and have no expertise at funding at all. I am worried that
merging this work will take a significant amount of effort. This is likely to result in fairly significant changes
to the core interpreter, and it might be hard to find enough core devs that willing and able to review
changes in a timely manner.

Ronald
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/6KXRTAH7FGF2SIS7ZJ3SG54LT4ELBWGI/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi Greg,

On 21/10/2020 11:57 pm, Greg Ewing wrote:
> A concern I have about this is what effect it will have on the
> complexity of CPython's implementation.
>
> CPython is currently very simple and straightforward. Some parts
> are not quite as simple as they used to be, but on the whole it's
> fairly easy to understand, and I consider this to be one of its
> strengths.

I'm not sure that it is "very simple and straightforward".

>
> I worry that adding four layers of clever speedup tricks will
> completely destroy this simplicity, leaving us with something
> that can no longer be maintained or contributed to by
> ordinary mortals.
>

The plan is that everything will be accessible to someone with a CS
degree. Any code base takes time and work to get familiar with it.
There is no reason why this code should be any easier or harder to
understand than any other domain-specific code.

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/UGLRZ2OC2YYTFXWQLNVGELVV7TC36WBX/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi Nathaniel,

On 22/10/2020 7:36 am, Nathaniel Smith wrote:
> Hi Mark,
>
> This sounds really cool. Can you give us more details? Some questions
> that occurred to me while reading:
>
> - You're suggesting that the contractor would only be paid if the
> desired 50% speedup is achieved, so I guess we'd need some objective
> Python benchmark that boils down to a single speedup number. Did you
> have something in mind for this?
>
> - How much of the work has already been completed?

A fair bit of stage 1, and much research and design for the later stages.

>
> - Do you have any preliminary results of applying that work to that
> benchmark? Even if it's preliminary, it would still help a lot in making
> the case for this being a realistic plan.

Getting a PGO/LTO comparison against 3.10 is tricky.
Mainly because I'm relying on merging a bunch of patches and expecting
it to work :)

However, on a few simple benchmarks I'm seeing about a 70% speedup vs
master for both default and LTO configures.

I would expect a lower speedup on a wider range of benchmarks with a
PGO/LTO build. But 50% is definitely achievable.

Cheers,
Mark.

>
> -n
>
> On Tue, Oct 20, 2020 at 6:00 AM Mark Shannon <mark@hotpy.org
> <mailto:mark@hotpy.org>> 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
> <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-leave@python.org
> <mailto:python-dev-leave@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/
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/TZ2YNUJPOBX4R6LEUESCP6WVTGPT5KQL/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 22 Oct 2020 at 12:52, Mark Shannon <mark@hotpy.org> wrote:
> Getting a PGO/LTO comparison against 3.10 is tricky.
> Mainly because I'm relying on merging a bunch of patches and expecting
> it to work :)
>
> However, on a few simple benchmarks I'm seeing about a 70% speedup vs
> master for both default and LTO configures.
>
> I would expect a lower speedup on a wider range of benchmarks with a
> PGO/LTO build. But 50% is definitely achievable.

Apologies if this is already mentioned somewhere, but is this across
all supported platforms (I'm specifically interested in Windows) or is
it limited to only some? I assume the long-term expectation would be
to get the speedup on all supported platforms, I'm mainly curious as
to whether your current results are platform-specific or general.

Paul
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/HHSC5CCMRZ7UWOGSLVFD5GER3BD3SU7J/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi Paul,

On 22/10/2020 1:18 pm, Paul Moore wrote:
> On Thu, 22 Oct 2020 at 12:52, Mark Shannon <mark@hotpy.org> wrote:
>> Getting a PGO/LTO comparison against 3.10 is tricky.
>> Mainly because I'm relying on merging a bunch of patches and expecting
>> it to work :)
>>
>> However, on a few simple benchmarks I'm seeing about a 70% speedup vs
>> master for both default and LTO configures.
>>
>> I would expect a lower speedup on a wider range of benchmarks with a
>> PGO/LTO build. But 50% is definitely achievable.
>
> Apologies if this is already mentioned somewhere, but is this across
> all supported platforms (I'm specifically interested in Windows) or is
> it limited to only some? I assume the long-term expectation would be
> to get the speedup on all supported platforms, I'm mainly curious as
> to whether your current results are platform-specific or general.

There is nothing platform specific.
I've only tested on Linux. I hope that the speedup on Windows should be
a bit more, as MSVC seems to do better jump fusion than GCC.
(Not tested clang).

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/M2F2NL3YSNOYKW2AELBIHYTCNC2SOCSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 22 Oct 2020 at 14:25, Mark Shannon <mark@hotpy.org> wrote:

> MSVC seems to do better jump fusion than GCC.
>

Maybe I'm wrong, since I only take a look at dict, tuple and set C code,
but it does not seems to me that there's more than 1-2 GOTOs in every
CPython function, and they can't be merged.