Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126205
Message-ID: <8c53b0fe-cafe-406c-8bab-1cedf2271c2f@gmail.com>
Date: Tue, 7 Jan 2025 20:21:33 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Static property asymmetric visibility
To: internals@lists.php.net
References: <0addc1b4-1e4d-45a9-a289-5f9a8e1da692@app.fastmail.com>
 <fdea1691-d1b6-44bb-88a7-71d0c0deb7bb@app.fastmail.com>
 <ba402e4d-51b4-4a4c-ae57-380563eb2e3e@gmail.com>
 <CAPyj-LBv=AV-pcLv1vSsohY-HM4zrWmB6j4ZP5TnVhj_VfYznw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAPyj-LBv=AV-pcLv1vSsohY-HM4zrWmB6j4ZP5TnVhj_VfYznw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
From: dossche.niels@gmail.com (Niels Dossche)

On 07/01/2025 19:49, Ilija Tovilo wrote:
> I wouldn't necessarily call this a workaround, but more of a missed
> optimization (one branch for each static property write that is
> unlikely to mispredict). If you wish, I can have a look at separating
> cache slots. This may lead to a slowdown due to cache priming (as only
> R/IS and RW/W/UNSET will be shared). To be honest, I doubt either of
> those will lead to a measurable difference in real code. I can confirm
> this by running some benchmarks. The benefit of separate cache slots
> is that it can be entirely handled in
> zend_fetch_static_property_address(), which would reduce VM/ future
> JIT changes, although the separation of the cache slots themselves
> might be more complex (given how it's currently implemented).
> 

I think splitting cache slots will indeed be worse than what it is now.
However, that argument in itself just doesn't really convince me honestly.
You are likely right about the branch prediction, but the CPU still has to do some extra work; and it's also just more things to think about as a maintainer.
I'll think about it more, maybe I'll just abstain from voting.

Kind regards
Niels