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
