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/
