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
