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 Mark.Shannon
Recipients Mark.Shannon, carljm, corona10, dino.viehland, eelizondo, gregory.p.smith, nascheme, pablogsal, pitrou, remi.lapeyre, shihai1991, steve.dower, tim.peters, vstinner
Date 2020-04-20.16:17:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 20/04/2020 2:33 pm, Steve Dower wrote:
> Steve Dower <> added the comment:
>> I would expect that the negative impact on branch predictability would easily outweigh the cost of the memory write (A guaranteed L1 hit)
> If that were true then Spectre and Meltdown wouldn't have been so interesting :)

I really don't follow your logic here.

> Pipelining processors are going to speculatively execute both paths, and will skip the write much more quickly than by doing it, and meanwhile nobody should have tried to read the value so it hasn't had to block for that path. I'm not aware of any that detect no-op writes and skip synchronising across cores - the dirty bit of the cache line is just set unconditionally.

Processors only execute the one path, speculatively or otherwise, that's 
why branch prediction is so important.
(And is important for the Spectre attack. If what you said were true, 
the Spectre attack wouldn't need to pre-bias the branch predictor.)
I'm assuming a modern Intel processor.

> Benchmarking already showed that the branching version is faster. It's possible that "refcount += (refcount & IMMORTAL) ? 0 : 1" could generate different code (should be mov,test,lea,cmovz rather than mov,and,add,mov or mov,and,jz,add,mov), but it's totally reasonable for a branch to be faster than unconditionally modifying memory.

It hasn't been shown that it is faster. I'm not claiming that it isn't, 
just that I haven't seen the evidence.

> ----------
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2020-04-20 16:17:43Mark.Shannonsetrecipients: + Mark.Shannon, tim.peters, nascheme, gregory.p.smith, pitrou, vstinner, carljm, dino.viehland, steve.dower, corona10, pablogsal, eelizondo, remi.lapeyre, shihai1991
2020-04-20 16:17:43Mark.Shannonlinkissue40255 messages
2020-04-20 16:17:43Mark.Shannoncreate