Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127664
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 15 Jun 2025 17:21:04 +0200
To: PHP Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Add num_available_processors
In-Reply-To: <fa495912-6669-449d-b573-fea7b29075cd@app.fastmail.com>
References: <bc1ec15125844c78a6aa23dce6148af9@danielkesselberg.de>
 <a1509633-ad50-4779-bc46-0f782cd8b7c5@app.fastmail.com>
 <60B4033B-2E6A-4157-A698-6C58454B07C9@garsi.de>
 <fa495912-6669-449d-b573-fea7b29075cd@app.fastmail.com>
Message-ID: <41838a7899af66f89692b9c041bbe2c6@danielkesselberg.de>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: mail@danielkesselberg.de (Daniel Kesselberg)

Hi Rob,

Thanks for your feedback. I've added a note, to the proposal section, 
that the cpu affinity mask is currently not considered.

The current patch is rather small. Taking the CPU affinity mask into 
account will require a more work and introduces different code paths for 
linux, bsd and win.

I agree, it's more correct to take into account and wonder if it's 
probably enough to just document for now. What do you think, is that 
something that should go into the voting part (take cpu affinity mask 
into account)?

RFC: https://wiki.php.net/rfc/num_available_processors

On 2025-05-25 15:28, Rob Landers wrote:

> On Sun, May 25, 2025, at 12:07, Alwin Garside wrote:
> 
>> On 24 May 2025, at 20:48, Rob Landers <rob@bottled.codes> wrote:
>>> 
>>> On Sat, May 24, 2025, at 19:37, Daniel Kesselberg wrote:
>>>> 
>>>> 
>>>> Hi everyone,
>>>> 
>>>> I'm happy to share my first RFC :) It proposes adding a small 
>>>> function
>>>> to retrieve the number of available processors; a feature that's
>>>> commonly found in other programming languages and one that I believe
>>>> would be a useful addition to PHP.
>>>> 
>>>> The related PR has already received a bit of early traction, and now
>>>> that the RFC is complete, I'm looking forward to your feedback!
>>>> 
>>>> RFC: https://wiki.php.net/RFC/num_available_processors
>>>> Patch: https://github.com/php/php-src/pull/11137
>>>> 
>>>> Best
>>>> Daniel
>>>> 
>>> 
>>> Looks good!
>>> 
>>> My main question is: what is this actually counting? In the RFC it 
>>> mentions "available processing units" ... which means, what? What 
>>> counts as a "processing unit"? Are we talking about CPU 
>>> Threads/cores; NPU cores; TPM cores; clocks? GPS? GPU? ... a modern 
>>> computer has many "processing units" for different purposes and 
>>> workloads. I'm assuming this is CPU Threads, not physical cores? I 
>>> will refer to CPU Threads as "Logical Cores" so we all don't get 
>>> confused since most of us here are programmers and saying "thread" 
>>> has a different meaning.
>>> 
>>> Secondly, how is it counting "available"? If I assign PHP to a 
>>> specific CPU affinity mask (say one logical core), will it return 1, 
>>> or the total number of logical cores available on my machine? I would 
>>> expect it to be 1, since PHP only has access to 1, but I can also see 
>>> the logic in returning the total number.
>>> 
>>> -- Rob
>> 
>> Hi Daniel,
>> 
>> I agree with Rob that "processor" is a bit too ambiguous. I'd use the 
>> phrase "cpu_core" instead. Yes, technically that's not entirely 
>> accurate when hyper-threading is used, but in most cases it's not 
>> trivial to distinguish physical cores from logical cores anyway, and 
>> "cpu_cores" provides the most understandable abstraction for the vast 
>> majority of use cases: deciding how many parallel processes one should 
>> use for optimal use of the CPU.
> 
> Yes, that is why I was curious as to the method it was using to return 
> the number. Using the sysconf method will just return the total number 
> of available cores. However, in Linux there is also the 
> sched_getaffinity method which returns the total number of cores 
> allocated to the current process (which may be lower). For example, 
> when sharing a webserver and a worker queue on a single system, I may 
> only allocate 1/3 of my cores (via `taskset`) to the worker queue, and 
> 1/3 cores to the webserver and the last 1/3 for other tasks (such as a 
> database). This prevents the worker queue from taking over the entire 
> system and slowing down my web requests and database.
> 
> If we have 12 cores and I've only allocated 4 cores for PHP, I would 
> want this function to tell my worker queue that it only has 4 cores, 
> using the system above -- not 12. This probably doesn't matter too much 
> when this is the only process on the machine. However, in any serious 
> production environment, you want to be able to prevent a run-away 
> process/job from harming other unrelated aspects of the system.
> 
> You can also see this behaviour with nproc:
> 
> ❯ taskset -c 0 nproc
> 1
> 
> ❯ nproc
> 16
> 
> -- Rob