Re: [PATCH] support for accessing CPU/core count (processor-count)

[Arthur Miller <arthur.miller@live.com>]

Campbell Barton <ideasman42@gmail.com> writes:

> On 10/11/21 06:50, Arthur Miller wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>>>> We seem to be talking past each other. I don't see why would want this as a C
>>>> primitive.
>>>
>>> There are typically 2 reasons to use C:
>>> - For speed
>>> - To use someone else's code which is easily available from C but not
>>>    from ELisp.
>> Of course, but I don't see any of those apply to this case :).
>
> The Elisp version of this function posted was incomplete by comparison in that
> it didn't support OpenBSD's ncpuonline feature or HPUX.
But then complete it :). I don't have openbsd installed.

> Also, this is not simply a call to an external process (executable-find "nproc")
> has some additional overhead.
You can skip that search if you want; it was just to be on the safe side. That
overhead is not importnat. As I wrote to Omar, you will probably ask for number
of cpu's in some eval-after-load or similar, not in some performance critical
code.

> I don't see this so much a case of ELisp vs C, more a case of OS-level API's
> being more appropriate than searching around for commands and parsing their
> output.
nproc.c has already sorted all that for you; so you can just call the process
instead of doing it all over.

>> As I see nproc from core-utils is already doing suggested, and more than so, so
>> it is just to call it :).
>> https://github.com/coreutils/gnulib/blob/master/lib/nproc.c
>> PS: it is not directly "a couple of lines" either as someone suggested :).
>
> Right, it's quite involved, as mentioned in a previous reply, this seems more
> appropriate for detecting OS-level threads (not spawning new processes).

Why does os threads matter if you can't access them. Or you mean "logical cores"
a.k.a "hyperthreading"?