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

[Arthur Miller]

Omar Polo <op@omarpolo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Omar Polo <op@omarpolo.com> writes:
>>[...]
>>>> What is wrong on just reading this from /cat/cpuinfo on GNU/Linux?
>>>>
>>>> Windows has "wmic cpu get NumberOfCores,NumberOfLogicalProcessors" which 
>>>> works
>>>> on cmd prompt, which means executable from elisp as a process. I dont know 
>>>> for
>>>> apple and *bsds.
>>>>
>>>> It is just text that can be parsed directly with elisp, so it is easier to
>>>> maintain does not need to be compiled etc. I don't see cpu queries as a
>>>> performance crucial query. Just a thought.
>>>
>>> You're right
>>>
>>>     syscstl -n hw.ncpuonline
>>>
>>> would do it.  I guess that a rationale for doing this in C would be to
>>> make it easier on the elisp side to use it.
There is no difference in usage on Lisp side if you implement a function as a C
built-in or a Lisp function.

However, difference in maintaining it is huge. For any change, entire Emacs has
to be recompiled, but if you do it in Lisp you can tweak it whenever, advice it,
etc.

I can't imagine number of CPUs change under the running Emacs process; at least
not on platforms I am aware off, so quering cpu number will probably be done in
some 'with-eval-after-load', i.e. not performance critical code.

>>> make it easier on the elisp side to use it.  We can try to support every
>>> OS here instead of leaving the burden on the elisp package authors.
Sorry for answering this as aftertought; I think there is a little bit of
missunderstanding going on. What I meant, is not that every user should do this
on their own. I just meant you should implement this in Lisp rather than in
C. An API to query number of physical cores is definitely a good thing to have.

>>> (the same thing applies to proced.  You could implement it by parsing ps
>> make it easier on the elisp side to use it.  We can try to support every
>>> output I guess, but there are elisp API that calls into C for that.)
>>>
>>> But I don't know, I don't really have strong opinions.  I've read a bit
>>> of code that didn't look right and tried to improve it :)
>>
>> By the way; I just realize also that native compiler does this, and there is
>> also a note about exporting already written c function to lisp:
>>
>> #begin_src emacs-lisp
>> (declare-function w32-get-nproc "w32.c")
>> (defvar comp-num-cpus nil)
>> (defun comp-effective-async-max-jobs ()
>>   "Compute the effective number of async jobs."
>>   (if (zerop native-comp-async-jobs-number)
>>       (or comp-num-cpus
>>           (setf comp-num-cpus
>>                 ;; FIXME: we already have a function to determine
>>                 ;; the number of processors, see get_native_system_info in 
>> w32.c.
>>                 ;; The result needs to be exported to Lisp.
>>                 (max 1 (/ (cond ((eq 'windows-nt system-type)
>>                                  (w32-get-nproc))
>>                                 ((executable-find "nproc")
>>                                  (string-to-number
>>                                   (shell-command-to-string "nproc")))
>>                                 ((eq 'berkeley-unix system-type)
>>                                  (string-to-number
>>                                   (shell-command-to-string "sysctl -n 
>> hw.ncpu")))
>>                                 (t 1))
>>                           2))))
>>     native-comp-async-jobs-number))
>> #end_src
>>
>> Maybe you can just extract the cpu number part from Andrea's function and 
>> rename
>> into some public API independent of native comp?
>
> Thanks for bringing up that bit, as is something that would need to be
> tweaked on OpenBSD (refer to my previous mail regarding ncpu vs
> ncpuonline.)
>
> Hope to remember to tweak this next time I'll try to get nativecomp on
> OpenBSD...
And that is the beauty of having it as a Lisp function. You can just tweak it,
don't need to recompile entire Emacs :).