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: Mon, 11 Oct 2021 10:15:03 +0200 Message-ID: References: <87h7dpgues.fsf@omarpolo.com> <871r4tgp9o.fsf@omarpolo.com> <87o87xf5ag.fsf@omarpolo.com> <8735p8ensy.fsf@omarpolo.com> <8735p8d1lc.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="29064"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Andrea Corallo , Campbell Barton , emacs-devel@gnu.org To: Omar Polo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 11 10:16:49 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 1mZqUI-0007Hu-Jq for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Oct 2021 10:16:47 +0200 Original-Received: from localhost ([::1]:58980 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mZqUH-00068n-EJ for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Oct 2021 04:16:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47926) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZqSm-0004d4-SE for emacs-devel@gnu.org; Mon, 11 Oct 2021 04:15:13 -0400 Original-Received: from mail-oln040092070088.outbound.protection.outlook.com ([40.92.70.88]:55118 helo=EUR03-AM5-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 1mZqSj-0002gl-Pc for emacs-devel@gnu.org; Mon, 11 Oct 2021 04:15:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CTG/YK/FXnKjnAKW9oOojpKPOG/dtUb8wj7F7rJMiGDNXlfti16tAr+Z3qH0LQvNlNr7T50cxbid8PiL266b7DNmBxGcuiUP6c6p74o22o2GaKjL2dIjmiE/8SGdEx0zQa2ipOXlxkPFdblMeG/bYbJmoUZRDhTJNiOLQTWtKfHBIfnmyIYTmXXiWPKfmoMvrbIrydqt7GorGqmyYaZoRL1KPnKl1K81TxnFyd5IA3IeHmax95H2MqVOEsBwPqRVvwCYJ5IRCobiEX6aUNq2J4xM7uDMPu3TKb+he1jP6bkrBfnHzH3ZFc/Ic6uuXbcA+L0JY6whjrEwk4k/Mcx31g== 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=WCMPn7lCHx3qChK1/M5PdiUV3D1qa1BiZJjBHusmoS0=; b=fvczem9UqLuueZ8ElMPOCMWaSLKB+es+4NQHQ4sKuK9TwURvN9sS86VlRKQDyZKNKpO+Z4MHfc5Mnl39ShcDYV+C4yeyHgGEjEf1x50dVmGMlYfRD+rYNeGdQzUjfcMYNulvHREdwG2DZbGOMhNH6GOOsj13O+HL1vVfKxsJSKzP3TBpR4s91yH949+gV0p4JsLTs49aSKIggLzhjA4Cr4/WH78L7sZhJS6vLP4O6W/bQnd8ECgNBcNt1Jh4MSYSEayi3Eaa352s51gt24Rvw7JoT5NAaIKY6yHc6Xszsn08RjoTmeCynjp5RpV4GUW+ha/SsHzGg158ePReQG9lVQ== 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=WCMPn7lCHx3qChK1/M5PdiUV3D1qa1BiZJjBHusmoS0=; b=olNU+Hu0wuxF4dAaeqnf6U5wo+rBG4kwHR0aSD8DCmM1/GYH6+WHho+KUWqga8dZWeGmtmbZvy+DKjV3c4rbZnVI9DYsXwlc74gHwBEH/4vZ1pyJgCgImcrVUDak673mlwwF7vpyg9cwhAlAg3GA/pZOTvuoIh2wifseX6eyqcf3uRLLSj4lF6CuZSmtOSmr8b3WyeuktO/4+mfdk5nV2rYcYA5Nfwf+zPjSFSeVEf6xJZJ4XzujZ03zJp7HM/fEJ+5767y9FjgsB9L7nZSQ/MeiPXNs3sS52+xL9DJAYyWJr/oV5xRoCFmzCjqQgbXDiW9o9N964P5Mr81HPUDaaw== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM0PR09MB4467.eurprd09.prod.outlook.com (2603:10a6:20b:16c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Mon, 11 Oct 2021 08:15:05 +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.026; Mon, 11 Oct 2021 08:15:05 +0000 In-Reply-To: <8735p8d1lc.fsf@omarpolo.com> (Omar Polo's message of "Sun, 10 Oct 2021 23:04:53 +0200") X-TMN: [vMsZqF8tnxpLpika+fpzmDv+GOEaiGDr] X-ClientProxiedBy: HE1PR07CA0003.eurprd07.prod.outlook.com (2603:10a6:7:67::13) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87a6jgj7ug.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (81.232.177.30) by HE1PR07CA0003.eurprd07.prod.outlook.com (2603:10a6:7:67::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.4 via Frontend Transport; Mon, 11 Oct 2021 08:15:04 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3486650e-0dd3-4427-480e-08d98c8f3b24 X-MS-TrafficTypeDiagnostic: AM0PR09MB4467: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 394i/TzO8wxIjM5/NRvZJoyNxD5YFvZYS6B7tsj6Uk52R+43qatmzXoSNfuTJ3sauJTyfZTizTaCICL1hRRf7Tcl62dDsTIQVDXHiMYPtOBhBRkmfVGqRoPR2Jc8V80ykEOf4RNPGHwE7sKUxDcGuUiei+sSM879sqov/uXFLRudI0PhCpWAvrS6zOYkf7tJNj47TRLeV0GOcgKc4OaML7vlppw2BQWnPoVZS8Hy8nh0qmdCffe6OHDcq+UaDVPLXWkkZy92tUkim/dLIfbCBNAVxtPIV4KsNCbM9KnrRdovKnPdhkPOoTyjiCowxwEN9irJedPB9sgd9eiueuQM98YO8+no5g8QFlJJFbufMhWhslcxzI5WIe4KnNV7EYfA3jNC/NayU9qbKsm7WunclDRD0fVkdBQwJfIWyaadFljiMV9I7LPOTS7UHL4v9+VQ X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: KutH9RPPcljWDCQIvX3E6Blsaw+IlZhtZK2W1wqrHZ1bPhMkQojH0uIfehoj//A6b20hDbrM89EfH0Vbap7tLR/lD7CvsyhwaiAGr/QBoZlg02GjSVuhH2s/XlqQZkqGs4oZB1hOvhRIYDtvzK5k6g== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-72e6e.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 3486650e-0dd3-4427-480e-08d98c8f3b24 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2021 08:15:05.3755 (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: AM0PR09MB4467 Received-SPF: pass client-ip=40.92.70.88; envelope-from=arthur.miller@live.com; helo=EUR03-AM5-obe.outbound.protection.outlook.com X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) 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:276729 Archived-At: Omar Polo writes: > Arthur Miller writes: > >> 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. > > 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. Neither do I :). I was just trying to explain why I reason the way I do. > 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. You can just open a lisp file in Emacs, hack it and eval the function; no need to recompile and restart Emacs. Also the code is easier to read, type etc. In my eyes it is a winner for the maintance. > 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 ;-) I had fingers in one patch to dired.c and in some smaller lisp patches, but nothing of sifnicance either. I really contribute mostly discussions and rarely code. I hope to change it in the future .. :) > 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") It wasn't my; I copy that from comp.el; please report it as a bug to Andrea so he can correct it. I don't have access to neither *bsd nor mac, so I can't tell. I also think it should be wrapped into call-process rather than shell-command-to-string, since shell-command-to-string lumps stdout and stderr into same buffer, which might result in erronous output. call-process seems to avoid that. > or something equivalent, please refer to my reply to the OP for the > HW_NCPUONLINE vs HW_NCPU on OpenBSD. > > Cheers :) Cheers!