[Python-Dev] Opcode cache in ceval loop
Sven R. Kunze
srkunze at mail.de
Mon Feb 1 16:49:14 EST 2016
On 01.02.2016 22:43, Yury Selivanov wrote:
> Sven,
>
> On 2016-02-01 4:32 PM, Sven R. Kunze wrote:
>> On 01.02.2016 22:27, Yury Selivanov wrote:
>>> Right now they are private constants in ceval.c.
>>>
>>> I will (maybe) expose a private API via the _testcapi module to
>>> re-define them (set them to 1 or 0), only to write better
>>> unittests. I have no plans to make those constants public or have a
>>> public API to tackle them. IMHO, this is something that almost
>>> nobody will ever use.
>>
>> Alright. I agree with you on that.
>>
>> What I actually meant was: how can we find the optimal values? I
>> understand that 1000 and 20 are some hand-figured/subjective values
>> for now.
>>
>> Is there standardized/objective way to find out the best values? What
>> does best even mean here?
>
> Running lots of benchmarks and micro-benchmarks hundreds of times ;)
> I've done a lot of that, and I noticed that the numbers don't matter
> too much.
That's actually pretty interesting. :)
Do you consider writing a blog post about this at some time?
> What matters is that we don't want to optimize the code that runs 0 or
> 1 times. To save some memory we don't want to optimize the code that
> runs 10 times. So 1000 seems to be about right.
>
> We also need to deoptimize the code to avoid having too many cache
> misses/pointless cache updates. I found that, for instance, LOAD_ATTR
> is either super stable (hits 100% of times), or really unstable, so 20
> misses is, again, seems to be alright.
>
> I'm flexible about tweaking those values, I encourage you and everyone
> to experiment, if you have time ;)
> https://github.com/1st1/cpython/blob/opcache5/Python/ceval.c#L100
Right now, I am busy with the heap implementation but I think I can look
into it later.
Best,
Sven
More information about the Python-Dev
mailing list