From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: HOWTO: lightning fast Emacs on Linux multicore Date: Sun, 16 Nov 2014 12:49:52 -0700 Message-ID: <20141116123211220580626@bob.proulx.com> References: <871tpdl29g.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416167428 13379 80.91.229.3 (16 Nov 2014 19:50:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 19:50:28 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Nov 16 20:50:22 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xq5q1-0000v3-MJ for geh-help-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 20:50:21 +0100 Original-Received: from localhost ([::1]:44937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq5q1-0000VU-9a for geh-help-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 14:50:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq5pg-0000NZ-4U for help-gnu-emacs@gnu.org; Sun, 16 Nov 2014 14:50:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xq5pb-0001cY-4c for help-gnu-emacs@gnu.org; Sun, 16 Nov 2014 14:50:00 -0500 Original-Received: from joseki.proulx.com ([216.17.153.58]:59560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq5pa-0001cP-Oi for help-gnu-emacs@gnu.org; Sun, 16 Nov 2014 14:49:55 -0500 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 561AB21229 for ; Sun, 16 Nov 2014 12:49:53 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 1A17D2DC35; Sun, 16 Nov 2014 12:49:52 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <871tpdl29g.fsf@debian.uxu> User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100965 Archived-At: Emanuel Berg wrote: > After rebooting > > ps -eo psr,comm | grep ' 1 ' > > to see that almost no processes are executing on > CPU 1. But life in the vault is about to change... It seems strange to me that you would not see processes on both cpus during normal operation. The kernel will schedule processes on the cpus in order to optimize performance or other things. A tool I like a lot for visualizing this is the bar graphs in 'htop'. You might try it. I expect you will see that during normal operation all cpus are going to get processes. You didn't say what type of cpu you have but let me say a word about Intel Hyper-Threading (https://en.wikipedia.org/wiki/Hyper-threading) in case it is one of those. HT is a marketing breakthrough because it is trademarked by Intel and therefore unavailable on AMD. Previously when I benchmarked performance I found that HT helped a single core by a very small amount but that it degraded multi-core again by a very small amount. Therefore I recommend disabling HT on multi-core systems. If you have an HT system and it is enabled then a dual core cpu will be displayed as a quad-core. That will be two cores with two threads per core. It is very easy to misinterpret this as four symetric cores. It is very easy to misinterpret the kernel scheduling algorithm as not using a core when in reality it is simply scheduling efficiently around the threads. Because cpu0 and cpu1 are two threads on the same core and cpu2 and cpu3 are two threads on the same core. A task running on cpu0 consumes both cpu0 and cpu1. If the kernel scheduled a task on both cpu0 and cpu1 while cpu2 or cpu3 are idle then the tasks sharing the first core would run at half speed. I mention this because hyper-threading is very easy to misdiagnose. In the early days back in the Linux 2.4 kernel it knew nothing of cpu threads and would do exactly this and HT needed to be disabled. > Launch Emacs like this: > > taskset -c 1 emacs > > Now, Emacs has a core to itself and should run much > faster, at least for normal usage. I am happy if you are happy with the above. However I recommend not doing this. It is making a small optimization for one specific case. But the kernel is trying to make global optimizations. It will try to make the entire system run as fast as possible. It is doing global dynamic optimization. By locking a process to a specific cpu you are preventing it from using another cpu even if it would go faster if it could use two. There are some specific uses for being able to do that type of thing. But mostly computers are general purpose and people use them for all kinds of general purpose things. One moment I am editing. Another moment email is being transfered. Another moment I am browsing the web. Another moment it is updating the system clock. Another moment it is running a cron task. Another moment reading and writing files to disk. Another moment it is generating entropy for an https or ssh encryption process. Another moment it is updating the display. These are all things that are all being mixed together. I think it is better to allow the kernel to optimize process scheduling itself. As I said, if you are happy then I am happy for you. But I wouldn't recommend this to others since it will generally slow down the system. Bob