Re: HOWTO: lightning fast Emacs on Linux multicore

[York Zhao <gtdplatform@gmail.com>]

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
>