[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