Is CachyOS Actually Faster? Where the Performance Gains Really Come From

A poster in r/linuxquestions ran the comparison everyone keeps arguing about. He installed CachyOS, benchmarked several games on a Ryzen 7 7800X3D with a Radeon RX 7900 XTX, and measured no difference against the other distributions already on the machine. The replies went the way they always go. One commenter put the ceiling low enough to be invisible in normal use. Another explained the scheduler. A third said benchmarks cannot show what the scheduler does. Nobody produced the measurement that would settle it.

The question keeps coming back in the same words: is CachyOS actually faster? The short answer is yes, in specific workloads. Recompiled packages can help code the compiler can vectorize, the gaming comparisons cited here show little average-FPS separation, and a system that feels faster after switching is harder to attribute because a distro switch changes far more than one variable.

It stays unsettled because "faster" carries three separate assertions with three different answers, each needing its own instrument. Recompiled packages either finish a task in less wall-clock time or they do not. A scheduler either changes how the desktop behaves under contention or it does not. And a snappier machine either traces back to CachyOS or to something that arrived alongside it.

The Short Version

• Recompiled packages: measurably faster, on a minority of what you run. Gains concentrate in code the compiler can vectorize, several packages come out slower, and most show no change. A January 2023 arch-chroot comparison at sunnyflunk.github.io, on an Intel NUC8i5BEK, found flac encoding 20.2% faster and bzip2 decompression 7.1% slower in the same run.
• The scheduler story splits in two. CachyOS's current default kernel uses EEVDF, while BORE is available separately. May 2026 distro comparisons found little average-FPS separation and also measured 1% lows and frame pacing, but they did not isolate BORE or add a controlled competing CPU load. Out-of-box gaming has been measured; BORE's under-contention benefit has not been isolated.
• The feeling of a faster machine: genuine experience, unreliable attribution. A fresh install and a coincidental fix to an unrelated bug both produce a quicker system that owes nothing to instruction-set levels. The exception worth knowing about is Phoronix's out-of-the-box comparison on an Intel Core Ultra 9 285K, where CachyOS came out ahead of stock Arch on a CPU that cannot use the AVX-512 optimizations at all.

What CachyOS Actually Changes About Your System

CachyOS is Arch Linux with three separate modifications stacked on it: a patched kernel offering alternative schedulers, repositories whose packages are recompiled for newer CPU instruction-set levels, and extra compiler optimizations on a subset of core packages. Each is a distinct mechanism with a distinct effect, and they are almost never measured apart.

The kernel side is the largest surface. CachyOS's kernel feature list covers Clang ThinLTO, AutoFDO profiling, runtime-selectable preemption modes, and several scheduler options. The current linux-cachyos package uses CachyOS-tuned EEVDF as its default scheduler. BORE and BMQ are available through separate kernel variants, while linux-cachyos-eevdf applies additional EEVDF responsiveness tuning and linux-cachyos-server uses stock EEVDF. sched-ext remains available on the variants that support it.

On the package side, the CachyOS x86-64-v3 repositories are the mechanism at issue. CachyOS's optimized-repositories page describes rebuilding Arch packages for three targets above the generic baseline: x86-64-v3, x86-64-v4, and a dedicated Zen 4/5 target adding further AVX-512 extensions, plus some instructions outside AVX-512, on top of v4. A subset of performance-sensitive packages also gets profile-guided optimization and BOLT.

Those level names come from the x86-64 psABI microarchitecture-level specification, and they are gates rather than dials. x86-64-v3 requires the AVX and AVX2-era instructions that arrived with Intel's Haswell in 2013 and AMD's Excavator cores; x86-64-v4 requires AVX-512, which in practice means Skylake-X-class Intel parts and every AMD Zen 4 or later. A CPU either clears the bar or it does not.

The Three Claims Hiding Inside the Word "Faster"

When two people disagree about whether CachyOS is faster, they are usually both right about different things. Throughput, frame consistency and perceived responsiveness are separate properties, and no single metric settles all three. A timed task measures throughput; frame-time and latency measurements cover gaming smoothness; a controlled fresh-install comparison is needed for the broader system-level effect.

A benchmark suite answering the first row cannot answer the second, and neither touches the third. Running one of the three and reporting the result as a verdict on all three is what keeps the thread going.

Do Recompiled Packages Actually Run Faster?

Yes, on a minority of what a desktop runs, and the size is set by the workload, not the distribution. Vectorizable work sees double-digit gains, a handful of packages come out slower, and most show nothing. CachyOS's optimized-repositories page puts the x86-64-v3 uplift at 5% to 20% over generic x86-64; published measurements mostly sit at the low end of that.

The cleanest CachyOS vs Arch performance comparison isolates the package variable and nothing else: a January 2023 arch-chroot test at sunnyflunk.github.io. The host ran stock Arch on an Intel NUC8i5BEK, both package sets were tested inside an arch-chroot so the kernel and environment stayed identical, and the benchmarks ran in RAM to remove disk latency. Against stock Arch packages, the CachyOS builds were 20.2% faster encoding flac at -8, 20.8% faster encoding vorbis and 9.5% faster on gzip -3. In the same run they were 7.1% slower decompressing bzip2, 1.6% to 2.9% slower compressing with lz4, 3% slower on pybench and unchanged on the R benchmark. Two caveats come from the author himself: CachyOS was building with -march=x86-64-v3 -mpclmul -O3 against Arch's -march=x86-64 -O2, and his follow-up tests suggested -O3 rather than the instruction-set level accounted for some of the larger wins. The post predates CachyOS's Zen 4 repository, which arrived with the July 2024 release, but not its BOLT work: the author reads the CachyOS Python package behind the pybench regression as already carrying BOLT on top of x86-64-v3.

The CachyOS benchmark runs on newer hardware repeat the pattern. A July 2024 comparison at mvermeulen.org ran a Phoronix Test Suite subset on a Zen 4 Ryzen 7940HS, CachyOS with the Zen 4 repository against Ubuntu 22.04. Most results landed within a few percent either way: coremark 6.4% slower, the OpenSSL subtests from about 1% slower to 4% faster, kernel build time 1.9% faster, phpbench an outlier at slightly more than double the score. The author flags a GCC version mismatch, 14.1 against Ubuntu's 11.4, as a likely confound. His separate NAMD run in March 2024 found 6.5% and 5.8% improvements on two molecular-dynamics workloads.

Institutional testing found the same mixed picture at both ends of it. Canonical's own x86-64-v3 benchmarking, published in March 2024 with an experimental Ubuntu 23.10 image on Azure, reported reproducible gains up to 60% on the glibc Log2 benchmark while other benchmarks regressed significantly, in one case because enabling v3 on already-optimized SSE code made the compiler expand it into 17 times more instructions. The CentOS ISA SIG's rebuild of CentOS Stream 9 from v2 to v3, on Ice Lake-class Intel machines in August 2023, called the results "fairly mixed", with 2.2x speedups concentrated in Mocassin and John the Ripper's md5crypt, both vectorization-heavy, though the team credited Mocassin's gain mainly to GCC 12's autovectorization rather than the ISA level.

Many performance-critical math and cryptography libraries ship several versions of hot functions and select one at runtime through CPU feature detection, a technique called function multiversioning and implemented in glibc through IFUNC resolvers. That means some hot paths can already use AVX2 on a stock Arch install without rebuilding the whole package. The sunnyflunk post saw this directly, noting that flac's source already includes AVX2 runtime functions that do not need -march to enable them. The CentOS finding is the mirror image: the team discovered glibc math functions lacking IFUNC versions, which is precisely where a static rebuild has room to help. What a v3 rebuild reaches is the remaining code the compiler's autovectorizer can improve on its own, which is a slice of a desktop and a small one.

Workload shape, not the badge on the CPU, decides whether a machine-level change shows up at all. The throughput verdict is yes, but bounded: single-digit changes are common in the measurements above, larger wins cluster around vectorizable workloads such as encoding and compression, and some packages regress. That is a better description than treating x86-64-v3 as a system-wide speed multiplier.

What the Scheduler Changes, and Why Average FPS Misses It

CachyOS's current default linux-cachyos kernel uses EEVDF, while BORE is available through scheduler-specific variants such as linux-cachyos-bore. That distinction matters because the gaming comparisons below are distribution-level tests, not controlled BORE-versus-EEVDF tests. BORE is still relevant to the broader performance claim because its design explicitly targets responsiveness under mixed workloads, but that claim has to be evaluated separately from out-of-box CachyOS gaming performance.

BORE's own README states the intent plainly:

To achieve this, BORE introduces a dimension of flexibility known as "burstiness" for each individual tasks, partially departing from CFS's inherent "complete fairness" principle.

firelzrd/bore-scheduler, project README

Burstiness is the CPU time a task has accumulated since it last gave up the CPU by sleeping, waiting on I/O or yielding. BORE converts that into a score and uses it to adjust each task's weight and its wakeup preemption aggressiveness, so tasks that keep yielding are treated as interactive and favored against tasks that hog their slice. The README names the trade-off itself: BORE settles into an "equilibrium between opposing greedy and weak tasks (usually CPU-bound batch tasks) and modest and strong tasks (usually I/O-bound interactive tasks)." Weighting interactive work up is the same operation as weighting batch throughput work down.

That tells you which instrument would detect BORE's specific claim: introduce a competing CPU load and measure frame-time percentiles or input latency while changing only the scheduler. A scheduler has much less to arbitrate when the game is running with idle CPU capacity.

A five-game benchmark published on May 16, 2026 used clean CachyOS and Omarchy installs on the same SSD and hardware, an RTX 5060 Ti and Ryzen 9, with the same Proton-GE build and 1440p settings. Average FPS differed by only one or two frames. Two days later, the same tester published a second comparison with full MangoHUD frame logging, adding 5% lows, 1% lows, and frame-pacing variance. That second test used different hardware, an Intel i7-13700 and Radeon RX 9060 XT, so it is additional evidence about frame consistency rather than a same-hardware extension of the first test. Neither comparison isolates the CPU scheduler or adds a deliberate competing CPU workload.

The project does not oversell it either. In an r/cachyos thread on gaming performance, Peter Jung, one of CachyOS's founding developers, answered a user directly: "In gaming not all too much. The newer feature can make a difference tough :)"

That leaves two separate conclusions. For out-of-box CachyOS gaming, published tests show little average-FPS separation and now include 1% low and frame-pacing measurements. For BORE specifically under deliberate CPU contention, I could not find a controlled published test that changes only the scheduler and measures responsiveness under that load.

Why a Switch Feels Faster Even When Nothing Measures Faster

Two mechanisms produce a quicker machine after a distro switch without any of CachyOS's optimizations being involved: the fresh install itself, and a coincidental fix to an unrelated problem the previous system had. Both are specific enough to recognize in your own case, which is what separates them from a blanket charge of placebo.

Start with the fresh install. In an r/linuxquestions thread on the question, a CachyOS user who said he had not noticed a difference himself suggested that people reporting large gains may be comparing against a well-used install rather than a fresh one. Years of accumulated autostart entries, orphaned services, drifted configuration and a full disk are a workload, and a clean partition removes all of it at once. A distro switch moves the kernel, the desktop environment, every package version and every default simultaneously, and a full Manjaro-versus-Ubuntu comparison runs to a dozen separate axes. Attributing an improvement to one of them afterwards is guesswork.

The coincidental fix is the sharper case. In the same thread, a commenter described daily-driving Fedora with a VRAM-management problem that was severely degrading performance, switching to CachyOS, and watching the problem disappear. He then moved to bare Arch and reported basically the same performance as CachyOS, concluding that he no longer knew what had been different. The improvement was real; CachyOS's compile targets had nothing to do with it.

Neither of those licenses a clean debunking, and the strongest evidence against one is a controlled test. Phoronix's Arrow Lake distribution comparison put Ubuntu 24.10, Fedora Workstation 41, Arch Linux, Clear Linux and CachyOS on the same Intel Core Ultra 9 285K in their default states, and CachyOS edged past all of them, including Clear Linux, which normally leads on Intel silicon. Arrow Lake has no AVX-512 support, so that lead cannot come from x86-64-v4; it reflects some combination of CachyOS's kernel and build choices, package optimizations, and default configuration.

The experience can be genuine while the attribution remains uncertain. The Phoronix Arrow Lake comparison is a useful counterexample: a default-state CachyOS install can outperform stock Arch even when x86-64-v4 is unavailable.

READ

Manjaro vs Ubuntu: A Comprehensive 2025 Comparison

How to Check Whether Any of This Applies to Your Machine

Which standardized x86-64 microarchitecture level your CPU supports is mostly answerable in one command. The dynamic linker reports the glibc-hwcaps levels it can use, so the highest supported x86-64-vN entry normally tells you whether the CPU qualifies for the generic v2, v3, or v4 repository tier. One important exception is Intel's 12th-generation and newer hybrid CPUs: CachyOS says to treat them as v3 even if v4 appears in the output because AVX-512 is not usable there. CachyOS's separate Zen 4/5 target also needs its own architecture check.

/lib/ld-linux-x86-64.so.2 --help | grep supported

For AMD Zen 4/5, CachyOS also documents:

gcc -march=native -Q --help=target 2>&1 | grep -Po "^\s+-march=\s+\K(\w+)$"

The first command prints something like this:

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

That is a CPU with v3 and v2 but no AVX-512. Three outcomes, three decisions:

• Nothing above x86-64-v2. The v3/v4/Zen-specific rebuild advantage does not apply to this CPU. CachyOS can still run, and package-specific compiler optimizations plus kernel and default-configuration changes can still matter.
• x86-64-v3 supported, x86-64-v4 unavailable. This includes modern Intel hybrid CPUs such as Arrow Lake for practical repository selection. In the comparisons cited above, many changes were small, some encoding and compression workloads gained much more, and some packages regressed.
• x86-64-v4 supported. AVX-512 creates more theoretical headroom for vectorizable workloads, but it does not guarantee a large system-wide gain.

If your CPU qualifies and the package half is what you want, you do not have to reinstall to get it. CachyOS's repositories can be added to an existing Arch system, and ALHP publishes rebuilds of the official Arch repositories at each x86-64-vN level, documented on the Arch Wiki with its own caveats: DKMS packages are required instead of directly linked kernel modules, and setting -march for kernel compilation "would not yield any significant results." Either route gets you the recompiled packages and none of the kernel patch set or the scheduler variants.

Run the command first. It converts an argument about distributions into a fact about your own machine, which is the only version of this question you can settle by yourself tonight.

Frequently Asked Questions

Does CachyOS Actually Improve Gaming Performance?

For average frame rate, barely. A May 2026 five-game comparison found only a one-to-two-frame difference, and a follow-up two days later also measured 1% lows and frame pacing. Neither test introduced a deliberate competing CPU workload, so the unresolved question is scheduler responsiveness under contention, not whether frame pacing has been measured at all.

Does My CPU Support x86-64-v3 or v4?

On CachyOS or Arch, run /lib/ld-linux-x86-64.so.2 --help | grep supported to see the standardized glibc-hwcaps levels detected for your CPU. x86-64-v3 requires the AVX/AVX2-era feature set, while v4 adds AVX-512. For Intel 12th-generation and newer hybrid CPUs, CachyOS recommends treating the system as v3 even if v4 appears in the output; Zen 4/5 users should also check the separate znver4/znver5 target.

Why Don't Recompiled Packages Make a Bigger Difference Than They Do?

Because some heavily optimized code is already runtime-dispatched to CPU-specific implementations. Math and cryptography libraries often use function multiversioning or IFUNC for hot functions, so rebuilding packages mainly helps code the compiler can further optimize or vectorize globally.

Can I Get CachyOS's Optimized Packages Without Switching Distros?

Yes. CachyOS's repositories can be added to an existing Arch Linux install, and the ALHP project publishes rebuilds of the official Arch repositories targeting x86-64-v2, v3 and v4, documented on the Arch Wiki. Both give you the recompiled packages only, not the CachyOS kernel patch set, the alternative schedulers, or the installer defaults.