HOWTO: lightning fast Emacs on Linux multicore

HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

A couple of months ago I got a multicore computer.
Better yet, it is a dualcore :)

I thought I'd share a trade-secret for all us
Emacs-only users.

There is a saying that the common case is the one that
should be optimized. That's what I'm doing here, with
the common case being - Emacs.

(This assumes a Debian Linux but I don't think it'd
look that different on other distributions or even
systems.)

First, confirm you have a multicore with

    lscpu | egrep '^CPU\(s\)'

Then, go to

    /etc/default/grub

and, as superuser, insert or change the line with
GRUB_CMDLINE_LINUX_DEFAULT into this:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet isolcpus=1"

Then

    sudo update-grub

and

    shutdown -h now -r # or otherwise reboot

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...

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.

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[Marcin Borkowski]

On 2014-11-09, at 00:07, Emanuel Berg wrote:

> Now, Emacs has a core to itself and should run much
> faster, at least for normal usage.

Sounds cool!  How much does it impact the power consumption?

BTW, it might be more reasonable to dedicate a core to the web browser
(at least in my case, this, not Emacs, is the performance bottleneck).
Or to LaTeX and/or evince. ;-)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Sounds cool! How much does it impact the power
> consumption?

Ha ha, power consumption? No idea... I never tried it
on a laptop so it isn't an issue for me, but feel
unrestricted to find out yourself, of course.

If you limit all processes to one core, and Emacs to
the other, that should mean Emacs runs faster, because
of less competition for that CPU (core), and the other
processes will run slower, by the same logic.

Emacs should be faster unless Emacs makes use of those
other processes, or if those other processes slow down
the entire system somehow by not getting enough CPU
(perhaps they start obstruct the memory or whatever).
I don't know what other processes people typically
have in the background, mine aren't any fancy. It
should definitely work for point movements and typing
and such, probably for most things I do actually. Mine
feels faster indeed.

> BTW, it might be more reasonable to dedicate a core
> to the web browser (at least in my case, this, not
> Emacs, is the performance bottleneck). Or to LaTeX
> and/or evince. ;-)

Yeah, you can do all that in Emacs of course, but in
general, I don't think you should use this to
eliminate bottlenecks, or yeah, you can actually do
that as well (good idea), my idea was rather to boost
the interactive feel of Emacs. If you have more than
two cores, perhaps eight or whatever, you can have one
core for each major application and then have the rest
distribute freely over those that remains. I think
that would be ... fast.

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[York Zhao]

This is interesting. On my system, running

ps -eo psr,comm | grep ' 1 '

produces:

1 watchdog/1
1 migration/1
1 ksoftirqd/1
1 kworker/1:0
1 kworker/1:0H
1 kworker/1:1

Is this acceptable?

My feeling is that my Emacs is running a bit faster. Could be placebo
though.

Thanks for sharing.


On Sat, Nov 15, 2014 at 2:26 PM, Emanuel Berg <embe8573@student.uu.se>
wrote:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
> > Sounds cool! How much does it impact the power
> > consumption?
>
> Ha ha, power consumption? No idea... I never tried it
> on a laptop so it isn't an issue for me, but feel
> unrestricted to find out yourself, of course.
>
> If you limit all processes to one core, and Emacs to
> the other, that should mean Emacs runs faster, because
> of less competition for that CPU (core), and the other
> processes will run slower, by the same logic.
>
> Emacs should be faster unless Emacs makes use of those
> other processes, or if those other processes slow down
> the entire system somehow by not getting enough CPU
> (perhaps they start obstruct the memory or whatever).
> I don't know what other processes people typically
> have in the background, mine aren't any fancy. It
> should definitely work for point movements and typing
> and such, probably for most things I do actually. Mine
> feels faster indeed.
>
> > BTW, it might be more reasonable to dedicate a core
> > to the web browser (at least in my case, this, not
> > Emacs, is the performance bottleneck). Or to LaTeX
> > and/or evince. ;-)
>
> Yeah, you can do all that in Emacs of course, but in
> general, I don't think you should use this to
> eliminate bottlenecks, or yeah, you can actually do
> that as well (good idea), my idea was rather to boost
> the interactive feel of Emacs. If you have more than
> two cores, perhaps eight or whatever, you can have one
> core for each major application and then have the rest
> distribute freely over those that remains. I think
> that would be ... fast.
>
> --
> underground experts united
>

Re: HOWTO: lightning fast Emacs on Linux multicore

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> A couple of months ago I got a multicore computer.
> Better yet, it is a dualcore :)

If you want to have fun, perhaps implementing a few emacs lisp library
functions in parallel (multi-threaded), could speed things up.

You'd have to find out what operations (particularly on big buffers) are
slow and parallelizable.

For example, replace-string could split its start/end range, (check the
cuts for occurences) and then process each range in parallel.

Similarly, replace-regexp and fontifying which is often thought to be
slow, could benefit (taking the same precautions around the cuts).

A lot of code that use iterative search (re-search-forward) could
probably be upgraded, using a function (such as re-all-matches) that
would perform the search in parallel on the different ranges.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> If you want to have fun, perhaps implementing a few
> emacs lisp library functions in parallel
> (multi-threaded), could speed things up.
>
> You'd have to find out what operations (particularly
> on big buffers) are slow and parallelizable.
>
> For example, replace-string could split its
> start/end range, (check the cuts for occurences) and
> then process each range in parallel.
>
> Similarly, replace-regexp and fontifying which is
> often thought to be slow, could benefit (taking the
> same precautions around the cuts).
>
> A lot of code that use iterative search
> (re-search-forward) could probably be upgraded,
> using a function (such as re-all-matches) that would
> perform the search in parallel on the different
> ranges.

I'm afraid you overestimate me. The stuff I mention
are Linux processes. If I put Emacs on core A,
everything from Emacs will be on core A. I don't know
how - if indeed possible - to put something out of
Emacs on some other core, and even less so to put
things on different cores and then to synchronize the
result after executing in parallel. But yeah - that
would be very cool indeed. And fast.

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

York Zhao <gtdplatform@gmail.com> writes:

> This is interesting. On my system, running
>
> ps -eo psr,comm | grep ' 1 '
>
> produces:
>
> 1 watchdog/1 1 migration/1 1 ksoftirqd/1 1 kworker/1:0
> 1 kworker/1:0H 1 kworker/1:1
>
> Is this acceptable?

Yes, that's normal. I guess the Grub stuff somehow
doesn't affect those. You'll have to examine the Linux
boot process to find out why.

> My feeling is that my Emacs is running a bit faster.
> Could be placebo though.

No, it is faster! And why shouldn't it be? It is
logical.

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[Jean-Jacques Rétorré]

Emanuel Berg <embe8573@student.uu.se> writes:

> York Zhao <gtdplatform@gmail.com> writes:
>
>> This is interesting. On my system, running
>>
>> ps -eo psr,comm | grep ' 1 '
>>
>> produces:
>>
>> 1 watchdog/1 1 migration/1 1 ksoftirqd/1 1 kworker/1:0
>> 1 kworker/1:0H 1 kworker/1:1
>>
>> Is this acceptable?
>
> Yes, that's normal. I guess the Grub stuff somehow
> doesn't affect those. You'll have to examine the Linux
> boot process to find out why.
>
>> My feeling is that my Emacs is running a bit faster.
>> Could be placebo though.
>
> No, it is faster! And why shouldn't it be? It is
> logical.

Have you measured how much faster it is on your system ?

--
JJR

Re: HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

jj.r&torr&@gmail.com (Jean-Jacques Rétorré) writes:

> Have you measured how much faster it is on your
> system ?

No, but if you know of some benchmark or syntactic
workload I can run sure, I'll do it.

But this is not about batches of computation, it is
the interactive responsiveness, which is much more
difficult to measure. (But actually as think batch
will be faster as well.)

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[Jean-Jacques Rétorré]

Emanuel Berg <embe8573@student.uu.se> writes:

> jj.r&torr&@gmail.com (Jean-Jacques Rétorré) writes:
>
>> Have you measured how much faster it is on your
>> system ?
>
> No, but if you know of some benchmark or syntactic
> workload I can run sure, I'll do it.

I dont. I do the trick on my eeepcX101CH (Intel(R) Atom(TM) CPU N2600 @
1.60GHz) and I dont see any significant difference.

>
> But this is not about batches of computation, it is
> the interactive responsiveness, which is much more
> difficult to measure. (But actually as think batch
> will be faster as well.)

--
JJR.

Re: HOWTO: lightning fast Emacs on Linux multicore

[Bob Proulx]

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

Re: HOWTO: lightning fast Emacs on Linux multicore

[Eli Zaretskii]

> Date: Sun, 16 Nov 2014 12:49:52 -0700
> From: Bob Proulx <bob@proulx.com>
> 
> > 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.

Seconded.

> 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.

In general, one should keep out of the scheduler's way, unless they
have a VERY good reason.  Such reasons can only pop up when you need
to run some software with hard real-time deadlines (and even then
there are better ways).  Any other reason is by definition to good
enough.

Re: HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

jj.retorre@gmail.com (Jean-Jacques Rétorré) writes:

> I dont. I do the trick on my eeepcX101CH (Intel(R)
> Atom(TM) CPU N2600 @ 1.60GHz) and I dont see any
> significant difference.

There can be many reasons for this.

One can be - is Emacs already super-fast?

I have lots of configuration and extentions, and
though I've written it as cleverly as possible, I must
admit that the interactive feel of 'emacs -Q' is
faster, not much but I sense it. Just as I sense the
one-core solution is faster.

Try bring in a bunch of stuff in .emacs if you didn't
already - w3m, LaTeX, Gnus, everything you can think
of - and then compare that to 'emacs -Q'. If you don't
feel a difference, perhaps you already hit the roof.

As for your CPU I don't know what optimization,
parallelizations, and so on are at play at that level.
It is more like a electrical engineering thing
anyway :) But do enlighten us if you know.

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

>> 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.

Yes, very strange indeed :) This is what you are
expected to get *after* appling the Grub setting.
Right now, that command gives me this list - apart
from what I explicity allocated CPU 1 with taskset(1)
- the following processes on CPU ("psr") 1:

  1 watchdog/1
  1 migration/1
  1 ksoftirqd/1
  1 kworker/1:0H
  1 kworker/1:1H
  1 kworker/1:2
  1 kworker/1:1
  1 kworker/1:0

Without the Grub setting, I get all sorts of processes
on CPU 1 as well as CPU 2.

> The kernel will schedule processes on the cpus in
> order to optimize performance or other things.

Yes, but the kernel strives for maximal *overall*
performance.

This approach is getting special treatment for Emacs,
optimizing the common case.

Another way to do it might to change the priority of
the Emacs. -20 is the highest priority, and the
default priority is 0. So:

    sudo renice -20 -p `pgrep emacs`

Verify with:

    ps -lC "emacs"

And check the NI column (NI for "nice").

> 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.

Yes, htop(1) is great, only the colors (light cyan and
green) I don't like.

Here is a screenshot of htop and top(1) together:

    http://user.it.uu.se/~embe8573/dumps/tops.png

Can you see anything interesting?

> 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.

That was a lot to digest :) I'll read that Wikipedia
article later and see if that clarifies things.

My CPU is, according to lscpu(1):

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            15
Model:                 35
Model name:            AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
Stepping:              2
CPU MHz:               1000.000
CPU max MHz:           2000.0000
CPU min MHz:           1000.0000
BogoMIPS:              1989.83
L1d cache:             64K
L1i cache:             64K
L2 cache:              512K
NUMA node0 CPU(s):     0,1

> 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.

Indeed, thats how it works in general. However, I do
web browsing, mail, Usenet, all programming including
compilation, actually I do everything in Emacs by now.
So I think it makes sense for the system to not strive
for general performance, but for special-treatment of
the number one process. Anyway that's the reasoning
behind this method, if it holds, let's just say it is
complicated and difficult to quantify. It feels faster
is all I know for sure.

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[Bob Proulx]

Emanuel Berg wrote:
> Bob Proulx writes:
> > 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.
> 
> Yes, htop(1) is great, only the colors (light cyan and
> green) I don't like.

That sounds like you want to turn off colors.  There is always 'export
TERM=vt100' to disable terminal colors everywhere if you like. :-)

But I know we just chatted about sources.list where you want syntax
coloring.  So is this simply another case where you want color but you
want a different color theme?  I assume it is possible to set
different colors for htop.  I have never bothered to look.

> Here is a screenshot of htop and top(1) together:
>     http://user.it.uu.se/~embe8573/dumps/tops.png
> Can you see anything interesting?

I see that both cpus are getting work.  Other than that not really.
The load is so low at 0.2 that there isn't enough going on to be
interestingly resource stressful.

Just as a general statement other useful tools are iotop and nettop
too.

> > 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
> 
> That was a lot to digest :) I'll read that Wikipedia
> article later and see if that clarifies things.
>
> My CPU is, according to lscpu(1):
> Model name:            AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

You have a true dual-core.  Not hyperthreaded.  So you can ignore all
of the discussion about hyperthreading.  Which is good actually.

> Indeed, thats how it works in general. However, I do
> web browsing, mail, Usenet, all programming including
> compilation, actually I do everything in Emacs by now.
> So I think it makes sense for the system to not strive
> for general performance, but for special-treatment of
> the number one process. Anyway that's the reasoning
> behind this method, if it holds, let's just say it is
> complicated and difficult to quantify. It feels faster
> is all I know for sure.

But even when working almost entirely within emacs the emacs process
itself will depending upon what you are doing eventually spawn
children processes.  I would want all of those to be able to make use
of both cpu cores.  Locking it all down to one cpu would be slower for
me.

You say you do compilation within emacs.  Does this mean that emacs is
sharing the single locked core with the compilation process too?  That
would be a prime example where I would want emacs and any make -j2
parallel compilation to share the cpu.  Locking all of that to one cpu
would definitely be worse there.

Bob

Re: HOWTO: lightning fast Emacs on Linux multicore

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

> That sounds like you want to turn off colors. There
> is always 'export TERM=vt100' to disable terminal
> colors everywhere if you like. :-)
>
> But I know we just chatted about sources.list where
> you want syntax coloring. So is this simply another
> case where you want color but you want a different
> color theme? I assume it is possible to set
> different colors for htop. I have never bothered to
> look.

I want colors, but not light cyan and light green. But
I don't rely on htop enough to change this. I believe
the red and yellow theme of top (the one in the
screenshot) is configured though.

> Just as a general statement other useful tools are
> iotop and nettop too.

If you are into the "top business" there is a large
article on this in Linux Magazine, a max 3-4 issues
back.

> But even when working almost entirely within emacs
> the emacs process itself will depending upon what
> you are doing eventually spawn children processes. I
> would want all of those to be able to make use of
> both cpu cores. Locking it all down to one cpu would
> be slower for me. You say you do compilation within
> emacs. Does this mean that emacs is sharing the
> single locked core with the compilation process too?
> That would be a prime example where I would want
> emacs and any make -j2 parallel compilation to share
> the cpu. Locking all of that to one cpu would
> definitely be worse there.

All this depends. I'm not sure Emacs-spawned processes
will run slower on the dedicated Emacs core.
Compilation in practise is compiling small changes all
the time, not huge recompilations. Even so, it isn't a
good example as this was never about doing batch jobs,
it is about increasing the interactive feel and touch
responsiveness of Emacs. And this actually happens.

-- 
underground experts united

Re: HOWTO: lightning fast Emacs on Linux multicore

[Eli Zaretskii]

> Date: Sun, 16 Nov 2014 14:39:40 -0700
> From: Bob Proulx <bob@proulx.com>
> 
> But even when working almost entirely within emacs the emacs process
> itself will depending upon what you are doing eventually spawn
> children processes.

Right.  Moreover, Emacs nowadays uses more than one thread, at least
when built with GTK.  And the OS itself uses more than one thread when
it services system requests on Emacs's behalf.

So running one program certainly doesn't mean one execution unit is
enough, or optimal.