all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Bob Proulx <bob@proulx.com>
To: help-gnu-emacs@gnu.org
Subject: Re: HOWTO: lightning fast Emacs on Linux multicore
Date: Sun, 16 Nov 2014 12:49:52 -0700	[thread overview]
Message-ID: <20141116123211220580626@bob.proulx.com> (raw)
In-Reply-To: <871tpdl29g.fsf@debian.uxu>

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



  parent reply	other threads:[~2014-11-16 19:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-08 23:07 HOWTO: lightning fast Emacs on Linux multicore Emanuel Berg
2014-11-10  2:05 ` Marcin Borkowski
     [not found] ` <mailman.13356.1415585130.1147.help-gnu-emacs@gnu.org>
2014-11-15 19:26   ` Emanuel Berg
2014-11-16  1:13     ` York Zhao
     [not found]     ` <mailman.13774.1416100398.1147.help-gnu-emacs@gnu.org>
2014-11-16  7:46       ` Emanuel Berg
2014-11-16  7:57         ` Jean-Jacques Rétorré
2014-11-16  8:07           ` Emanuel Berg
2014-11-16  8:43             ` Jean-Jacques Rétorré
2014-11-16 20:34               ` Emanuel Berg
2014-11-16  2:55 ` Pascal J. Bourguignon
2014-11-16  7:41   ` Emanuel Berg
2014-11-16 19:49 ` Bob Proulx [this message]
2014-11-16 20:25   ` Eli Zaretskii
     [not found] ` <mailman.13827.1416167406.1147.help-gnu-emacs@gnu.org>
2014-11-16 21:04   ` Emanuel Berg
2014-11-16 21:39     ` Bob Proulx
2014-11-17  3:42       ` Eli Zaretskii
     [not found]     ` <mailman.13834.1416173992.1147.help-gnu-emacs@gnu.org>
2014-11-16 21:58       ` Emanuel Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141116123211220580626@bob.proulx.com \
    --to=bob@proulx.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.