Message 361138 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	vstinner
Recipients	eric.snow, jkloth, nanjekyejoannah, ncoghlan, vstinner
Date	2020-02-01.00:30:57
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1580517057.49.0.13192433757.issue39511@roundup.psfhosted.org>
In-reply-to

Content
> Would it not suffice to just make the singletons "immortal"? The problem is to make Py_INCREF/Py_DECREF efficient. Last time someone tried to use an atomic variable for ob_refcnt, it was 20% slower if I recall correctly. If many threads start to update such atomic variable, the CPU cacheline of common singletons like None, True and False can quickly become a performance bottleneck. On the other side, if each interpreter has its own objects, there is no need to protect ob_refcnt, the interpreter lock protects it.

> Would it not suffice to just make the singletons "immortal"?

The problem is to make Py_INCREF/Py_DECREF efficient. Last time someone tried to use an atomic variable for ob_refcnt, it was 20% slower if I recall correctly. If many threads start to update such atomic variable, the CPU cacheline of common singletons like None, True and False can quickly become a performance bottleneck.

On the other side, if each interpreter has its own objects, there is no need to protect ob_refcnt, the interpreter lock protects it.

History
Date	User	Action	Args
2020-02-01 00:30:57	vstinner	set	recipients: + vstinner, ncoghlan, jkloth, eric.snow, nanjekyejoannah
2020-02-01 00:30:57	vstinner	set	messageid: <1580517057.49.0.13192433757.issue39511@roundup.psfhosted.org>
2020-02-01 00:30:57	vstinner	link	issue39511 messages
2020-02-01 00:30:57	vstinner	create