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

[Omar Polo]

Arthur Miller <arthur.miller@live.com> writes:

> Omar Polo <op@omarpolo.com> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> [...]
>>> And that is the beauty of having it as a Lisp function. You can just tweak 
>>> it,
>>> don't need to recompile entire Emacs :).
>>
>> I know I'm getting off-topic, but I just don't understand your point.  I
>> don't see how spawning a bunch of commands, checking their return code
>> and parsing their output is better than a couple of lines of C that do
>> the right thing depending on the platform (decided at compile time!) and
>> get directly an int.
> I don't undestand what you don't udnerstand :-)
>
> I don't know my man; what do you mean with "bunch of commands" and how you 
> would
> achieve this for all platforms with "couple of lines of C".
>
> Here you have it; based on Andreas code from comp.el. I have just chagned part
> shell command on gnu/linux since it can fail dependning on flags. Of course 
> you
> get an int back, "directly" :).
>
> #+begin_src emacs-lisp
> (declare-function w32-get-nproc "w32.c")
>
> (defun processor-count ()
>   (cond ((executable-find "nproc")
>          (with-temp-buffer
>            (call-process (executable-find "nproc") nil t nil)
>            (string-to-number (buffer-string))))
>         ((eq 'windows-nt system-type)
>          (w32-get-nproc))
>         ((eq 'berkeley-unix system-type)
>          (string-to-number
>           (shell-command-to-string "sysctl -n hw.ncpu")))
>         (t 1)))
> #+end_src
>
>
> Compare to original patch in C, and tell me how is doing same in C better than
> doing it in Lisp? Your Lisp routine should 
> return an int directly. I don't see what is different there and what 
> advantage C
> will give you here; more than extra work to implement it and maintain it 
> later on.
>
> To note here is that 'shell-command-to-string' is not recommended since it can
> return "more", than what expected, depending on what flags are used to pass to
> bash. I am not sure if it can also differ if user uses some other
> shell. call-process should be fine. I don't have a bsd system to test though.
>
> I haven't used /proc/cpuinfo. It is a bit dependning on what is goal here: is 
> it
> to get number of "usable" cpus for spawning threads, or is it to get real
> hardware number of cpus. The reason is that Emacs can run in a "restricted"
> system such as a Docker environement where number of CPUs available can be
> limited. /proc/cpuinfo (on linux kernel) records hardware number of cores but
> nproc return "available" number. So you could have something like this:
>
> #+begin_src emacs-lisp
> (declare-function w32-get-nproc "w32.c")
>
> (defun processor-hardware-count ()
>   (cond ((eq 'gnu/linux system-type)
>          (with-current-buffer (find-file-noselect "/proc/cpuinfo")
>            (if (re-search-forward "cpu cores.*: " nil t)
>                (string-to-number (current-word))
>              1)))
>         ((eq 'windows-nt system-type)
>          (w32-get-nproc))
>         ((eq 'berkeley-unix system-type)
>          (string-to-number
>           (shell-command-to-string "sysctl -n hw.ncpu")))
>         (t 1)))
> #+end_src
>
> Could be done with "-all" flag to nproc too, but I think reading /proc/cpuinfo
> is faster.
>
>> I love lisp, don't get me wrong, and I actually prefer writing elisp
>> rather than following the GNU C coding style (I love C too but GNU style
>> hurts my eyes.)
>
> Trust me; if anyone I always vote for doing it in C; but this one is probably
> not worth doing in C. I have no idea how suggested posix sysconf deals with
> restricted environements either.
>
>> Sure, checking the number of cpus is not something that is done a lot,
>> and I can't imagine a situation where it would be a bottleneck, but on
>> the other hand, for the same argument, it's not something that needs to
>> be tweaked often
>
> Do you want hardware count; logical cores (think hyperthreading); should it 
> work
> in restricted environments? Quite a few things to take into consideration, 
> isn't
> it?
>
> Hope you understand what I mean better after examples. Something tells me you
> won't agree :-), but that is OK. I just present my opinion.

I don't really want to start a pointless thread, so I hope I didn't
sound annoying.  If that's the case, I'm sorry.

I kind of get your point, and as I sad before, I don't have opinions on
this particular case.

I'm still not sure how C can be more difficult to maintain than an
elisp, as to my eyes they're equal.  (yes, elisp has enormous advantages
in most cases, I won't be ever writing a major mode in C for example,
but this is not one of those IMHO).  But I've never really contributed
something significant to Emacs, and I spend almost all my free time
hacking in C, so I'm kinda biased ;-)

But I'd like to add a small correction to your example.  The sysctl is
not correct on OpenBSD (and maybe NetBSD too?  I can't check.)  It
should read

(shell-command-to-string "sysctl -n hw.ncpuonline || sysctl -n hw.ncp")

or something equivalent, please refer to my reply to the OP for the
HW_NCPUONLINE vs HW_NCPU on OpenBSD.

Cheers :)