Re: HOWTO: lightning fast Emacs on Linux multicore

[Bob Proulx <bob@proulx.com>]

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