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

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

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.