From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] support for accessing CPU/core count (processor-count) Date: Sun, 10 Oct 2021 21:45:54 +0200 Message-ID: References: <87h7dpgues.fsf@omarpolo.com> <871r4tgp9o.fsf@omarpolo.com> <87o87xf5ag.fsf@omarpolo.com> <8735p8ensy.fsf@omarpolo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21162"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Campbell Barton , emacs-devel@gnu.org To: Omar Polo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 10 21:47:07 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZemn-0005HV-IW for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Oct 2021 21:47:07 +0200 Original-Received: from localhost ([::1]:47508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mZemm-0006je-2X for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Oct 2021 15:47:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZels-0005xk-5K for emacs-devel@gnu.org; Sun, 10 Oct 2021 15:46:09 -0400 Original-Received: from mail-oln040092073035.outbound.protection.outlook.com ([40.92.73.35]:51875 helo=EUR04-HE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZelk-0006Gw-15 for emacs-devel@gnu.org; Sun, 10 Oct 2021 15:46:07 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mlj94v79il+ZBPfczAj4hMfq+x1byTjabD1L97SzayriryNqyIaSFfBKGmNPQeVTMwOTlJVMevzoulQuOli3EsAa4/IHY2SAAZnvgPTyenTKRcqP1ReVheuJ6RKTXOhWkcuJB9dLS333hkN4/TSP2ahVQwNZsz20vracDcGNzSxcbsrPZUXqajnhAKMHNQTljIdpJav8aD6eoZO6aEbZnQ6JQqbUfh+w+4NyGTQINKM+C/SW7E0pwvBFNrVRmPRf5qpviGsw/NuLJexIvQgkfst63HLwJ8D7XSO3xsJRGAr+rv1HfM4czh4zooLwVcODZn8NDp+of9I092mLrsx+mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q6x0oS3p3iWsqpBG+Ul2yj+LO20+8WSIkas1P+GlYLk=; b=c9LM6NkfbWZCed6NgxBCbmowokia3hRLa7ehmCkQf1YyH6NbjzqEaLMeRFK8dqpQXzbQMOv7pOq0nLpAi5bg/avgF/F+WDQeJvJBbpqlopo5f2PBNAeU7Ymhg4pC5GAo5xsMLEQa5doFJoAJvQBWY0bgn41O2Or7rr60HGPwGQ6g9q22k96XpHDWfG8LS8l1O5PrRlBhcQNYobSj2zWe70kAZFZGdYDB3xm2IT/Ts187yeuB92+suMVHWmHuRSP+tUU5THYzGtN97C8CxUJH3gTzRZIqQXxrIZu7Fpl3K16XnjOLBNz4ZRhdjDEF1vr4rQtNKT6Zq5kfRQ2AWWkEww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q6x0oS3p3iWsqpBG+Ul2yj+LO20+8WSIkas1P+GlYLk=; b=U4EgOCofBxp+JNLNIALNch+6VvoZine3EfWQffXec4uKjCdEFrR3DAD0lzcZxHBV5stOSXnLdHQYb5+QW0E8vL+FNhy4fnEz7wxTBN1YeUeGsVJ3OVHc+lQXhZ+NUdV5OIj7aWcrLHveddssfJvV/GxNXZvBJxDTve6pXai+jdQ6yAVccpDPqBtLFfhibSeBgWghcLN8CxfMY9vIPM/LyDhvHG7+4Stp9vjqlWuDMJLCjvS3TpVkY1x2RXwpEvLesye+QQCeqFSakMKG+nQxnsa0dc5AAQ/ci5qeIW1739ij1RunPjIwmQQpAX4/wpy45gZs0hRbjBeZvMVbZwQmvw== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM0PR09MB2708.eurprd09.prod.outlook.com (2603:10a6:208:12c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Sun, 10 Oct 2021 19:45:56 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c05b:e2ca:5b8a:56d2]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c05b:e2ca:5b8a:56d2%9]) with mapi id 15.20.4587.025; Sun, 10 Oct 2021 19:45:56 +0000 In-Reply-To: <8735p8ensy.fsf@omarpolo.com> (Omar Polo's message of "Sun, 10 Oct 2021 20:17:49 +0200") X-TMN: [UE+Wc/J7rGK2zwbbwGmYJuMRKLXOREWH] X-ClientProxiedBy: HE1P189CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::23) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87r1csk6j1.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (81.232.177.30) by HE1P189CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.24 via Frontend Transport; Sun, 10 Oct 2021 19:45:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2bff5f2e-7fdc-4a31-685f-08d98c269366 X-MS-TrafficTypeDiagnostic: AM0PR09MB2708: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UTUoPemQ3raVOk6/MvLUMElfTjOQYUmScDOApzG46VxxNefJa3RMutELyNhQGpXHIg9HiEmEmT01vYklMwdtUzf+HHEazqS6lM/F4g+XSnJTI93SymL7HPKP67xhl7gdonH5JQfryIFK2/lWEDyLomP1F/7F+E3aiXp74TPYpJtdqISzpBSg2WrISkgM/X6Shg4t4c+4oSI+utOBJNM6OX8pIRpjHV1ud7Zy/hbZcgug6N9s3cq37U26JiBR84tTvegoVRD5Y9wIKcQUJPv38tBUiwDIbLIV7DQ+7pHNrN3n8oA9Pbzd8iZVHdCO9YT1vyh1fXbID4GMXYF/xyxZauSxFYKOm7yMpiuT/gomKMgT82wbSXQj8UqNsbClRuY/hZD6NLiKutdEyA/m5LBypJr0zfyN8HxRfFhTQH7UT1DNTgLk+vJHFUQbAWF5f4N3 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: nRreHMIpAI+NENGIXVBXjBrHkqJUGx98xxXxZZEF/EyhKrCG5j0FOOLhYSGgA5pSsY5tm+wfVUksqGtrXLSysipnoxQlXldRocxu8Dx1izjCXRMy8ZFfA/8EOg2ypyylAhcZp35LjZ35aFgShlI83A== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-72e6e.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 2bff5f2e-7fdc-4a31-685f-08d98c269366 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2021 19:45:56.2519 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR09MB2708 Received-SPF: pass client-ip=40.92.73.35; envelope-from=arthur.miller@live.com; helo=EUR04-HE1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276691 Archived-At: Omar Polo writes: > Arthur Miller 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.