Here is what I have been using, for speed. It’s probably important to note that I’m running in 8G RAM. The last one might be set to “performance” if I had 12G or more.
Processor Family, set to Native Optimizations
Processor type and features -> Timer frequency, set to 1000
General setup -> Compiler optimization level, set to “size”, for small memory usage
At the core, any current desktop OS is running binary code; and the vast majority of it is binary code which uses only a subset of the CPU at hand. This is because there are so many different CPUs which need to run the same code. Intel and AMD constantly add things to the CPUs they put out, but code of general distribution lags very far behind, because when one downloads and installs, that code set has to run on everything, whether it be ten years old or three months old. On an excellent Linux, one can recompile any package in such a way that the binary code resultant uses the entire CPU which one is using. Performance gains are thus available.
Most of the advice I have been given and found, for recompiling certain packages for Arch Linux and derivatives, has made things very very complicated, and often includes statements that it’s not worth it. Well, I am a witness that it is well worth it, one can increase performance quite a lot, and it’s not too complicated as of this writing.
My Arch derivative of choice is Manjaro, it does a lot of things for us. But all of these methods are pure Arch, all you have to do is get the prerequisites.
Prepare the environment
Before we do anything, we update the system and reboot. This is partly because operations further down will get new packages.
Then we install
yay. Manjaro has it in its standard repos and can be installed just with
pacman -S yay; it’ll be a bit more difficult under pure Arch. Once yay is in, we edit /etc/makepkg.conf, and find these lines:
Both lines will be quite long, with close-quotes, containing several items. One of the items in both is
-march=; this needs to be changed from whatever it is to
-march=native. We also need an item added or changed if it exists: we need
-mtune=native. This will make everything we compile, run by far the best on the very make and model CPU we have in this machine. It will also make the packages not run well on anything else, fair warning :-)
In addition in this file, find a line starting with this:
There will be a number to the right and a close quote. Find out how many CPU cores your machine has, and add one; so if you have a dual core, you’ll add this line just below the original:
This speeds up package compilation a lot, even with just two cores, and enormously more with 4 or more.
There is one more item to prepare. In this file (“~” means your home directory):
you’ll want to add the following:
This eliminates the need to manually receive and approve GPG signing keys for various source files as they are downloaded.
Install an Optimized Kernel
So. Once the above is done, it’s not hard to use yay to build and install the Xanmod kernel, an excellent desktop-optimized kernel:
yay -S linux-xanmod
Yay will bring in the PKGBUILD, the file defining how the kernel source is download and package built. It quickly gives the option to edit it, and doing so is part of our procedure. As of this writing, you’ll look for one line:
and change this to:
This is according to documentation in the file itself; in this version at least, 22 equals “native”, which means the kernel will be optimized for the very specific CPU make and model in your machine. You can then save and choose the defaults for the rest of the process. It will take a while, 30 minutes often and much more on slower machines. Once the rebuild and install is done, you will notice a performance boost after booting the new kernel. Do be aware that automatic updates may override this kernel down the road; you can use
grub-customizer (also available via yay) to specify which kernel you will boot.
After the kernel itself, by far the most used boulder of code in a Linux machine is the GNU C Library, glibc for short. So we rebuild this next.
We pull the PKGBUILD and related build scripts with yay:
yay -G glibc
And then we cd into the directory created, and light off makepkg and watch it go:
If packages are needed for the build, install will commence, and then compilation. Compilation will take quite a while, longer even than the kernel. After it’s done, install:
sudo pacman -U *.pkg.tar.xz
and reboot to fully engage, though you may see improvement as soon as you start running or restarting programs.
Issues with many packages
There are issues which can show up with many packages.
First of all, compilation may fail. glibc is a huge package with a very large number of complications, and sometimes those complications have to do with specific versions of gcc and other items — which means if your machine is updated past those versions, you won’t compile successfully. You can either dig deep in code and/or forums to see what is going on, or just wait until the (very knowledgeable and capable, much more so than I) primary developers resolve it for all of us. Even something like the Xanmod kernel compilation may fail occasionally for the same reasons; there are quite a few more kernels available to try from yay, though each of them have different methods of setting CPU optimization, do watch for this.
Secondly, getting the versions you need. You probably should want the standard version, not the AUR (bleeding edge sometimes, archival and out of date sometimes too!) version. yay -G will tell you what it’s doing, but do be careful to not try to use outdated versions, that can break your OS if you go off the beaten path.
And thirdly, when you automatically update using pacman or GUIs, newer un-optimized versions will be autoinstalled over your optimal one. There may be ways to override this, but override is very questionable, because a very outdated package of many sorts is likely to produce crashes, especially something core like glibc or xorg-server. Better to just recompile after the update is installed. It is also helpful to choose such packages for the rarity of their updates, and glibc is one such.
Other packages to CPU-optimize
There are many other packages worth recompiling. I choose these regularly and differently according to high result/effort ratio! Here is a list, there are doubtless many more. These are all for the yay -G and makepkg method used for glibc, not yay -S. There may well be others which will help more, certainly for particular use purposes, e.g., audio and video.
It’s called DroidCam, and it really works, Windows and Linux.
Under Linux you’ll need kernel module compilation capability, headers only for source. If you use the Adobe Flash Player for camera, or any other V4L version 1 application, you’ll want to start it like the below for the Pale Moon web browser:
First try installing this package:
If that doesn’t help and you have a 64-bit OS, create this file:
containing this line for 64-bit OS: