Користувач r/linuxquestions провів порівняння, про яке всі не перестають сперечатися. Він встановив CachyOS, прогнав бенчмарки кількох ігор на Ryzen 7 7800X3D з Radeon RX 7900 XTX і не зафіксував жодної різниці порівняно з іншими дистрибутивами, які вже стояли на машині. Відповіді пішли звичним сценарієм. Один коментатор опустив стелю так низько, що у звичайній роботі її не помітити. Інший пояснив планувальник. Третій заявив, що бенчмарки не здатні показати, що робить планувальник. Ніхто не навів вимірювання, яке б закрило питання.
Питання повертається знову й знову тими самими словами: чи справді CachyOS швидший? Коротка відповідь — так, на окремих навантаженнях. Перекомпільовані пакети можуть допомогти коду, який компілятор уміє векторизувати, наведені тут ігрові порівняння показують невеликий розрив за середнім FPS, а систему, яка здається швидшою після переходу, важче пояснити, бо зміна дистрибутива змінює значно більше, ніж одну змінну.
Суперечка не вщухає, бо «швидший» містить три окремі твердження з трьома різними відповідями, і кожному потрібен свій інструмент. Перекомпільовані пакети або виконують завдання за менший астрономічний час, або ні. Планувальник або змінює поведінку робочого столу під конкурентним навантаженням, або ні. А жвавіша машина пояснюється або CachyOS, або тим, що прийшло разом із ним.
Коротко
- Перекомпільовані пакети: вимірювано швидші, але лише для меншої частини того, що ви запускаєте. Виграш зосереджений у коді, який компілятор уміє векторизувати, кілька пакетів стають повільнішими, а більшість не змінюється. Порівняння в arch-chroot від січня 2023 року на sunnyflunk.github.io, на Intel NUC8i5BEK, показало кодування flac на 20,2 % швидше й розпакування bzip2 на 7,1 % повільніше в тому самому прогоні.
- Історія з планувальником розпадається на дві частини. Поточне ядро CachyOS за замовчуванням використовує EEVDF, а BORE доступний окремо. Порівняння дистрибутивів у травні 2026 року показали невеликий розрив за середнім FPS, а також виміряли 1 % найгірших кадрів і рівномірність кадрів, але не ізолювали BORE й не додавали контрольованого конкурентного навантаження на CPU. Ігри «з коробки» виміряні; користь BORE під конкуренцією за CPU — ні.
- Відчуття швидшої машини: досвід справжній, атрибуція ненадійна. І свіже встановлення, і випадкове виправлення непов'язаної помилки дають жвавішу систему, яка нічим не завдячує рівням набору інструкцій. Виняток, про який варто знати, — порівняння Phoronix «з коробки» на Intel Core Ultra 9 285K, де CachyOS випередив стандартний Arch на процесорі, який узагалі не може використовувати оптимізації AVX-512.
Що CachyOS насправді змінює у вашій системі
CachyOS — це Arch Linux із трьома окремими модифікаціями зверху: пропатченим ядром з альтернативними планувальниками, репозиторіями, пакети яких перекомпільовані під новіші рівні набору інструкцій CPU, і додатковими оптимізаціями компілятора для частини базових пакетів. Кожна з них — окремий механізм з окремим ефектом, і їх майже ніколи не вимірюють окремо.
Сторона ядра — найбільша поверхня. Перелік можливостей ядра CachyOS охоплює Clang ThinLTO, профілювання AutoFDO, перемикані під час роботи режими витіснення та кілька варіантів планувальника. Поточний пакет linux-cachyos використовує налаштований CachyOS EEVDF як планувальник за замовчуванням. BORE і BMQ доступні через окремі варіанти ядра, при цьому linux-cachyos-eevdf застосовує додаткове налаштування чутливості EEVDF, а linux-cachyos-server використовує стандартний EEVDF. sched-ext і далі доступний на варіантах, які його підтримують.
З боку пакетів ідеться про репозиторії CachyOS x86-64-v3. Сторінка оптимізованих репозиторіїв CachyOS описує перезбирання пакетів Arch під три цілі вище базового рівня: x86-64-v3, x86-64-v4 та окрему ціль Zen 4/5, яка поверх v4 додає ще розширення AVX-512 і кілька інструкцій поза AVX-512. Частина чутливих до продуктивності пакетів також отримує оптимізацію за профілем і BOLT.
Ці назви рівнів походять зі специфікації рівнів мікроархітектури x86-64 psABI, і це пороги, а не регулятори. x86-64-v3 вимагає інструкцій епохи AVX та AVX2, що з'явилися з Intel Haswell у 2013 році та ядрами AMD Excavator; x86-64-v4 вимагає AVX-512, що на практиці означає процесори Intel класу Skylake-X і будь-який AMD Zen 4 або новіший. Процесор або бере планку, або ні.
Три твердження, сховані у слові «швидший»
Коли двоє людей сперечаються, чи швидший CachyOS, зазвичай обоє мають рацію — але про різне. Пропускна здатність, стабільність кадрів і відчутна чутливість — різні властивості, і жодна метрика не закриває всі три. Замір часу завдання вимірює пропускну здатність; вимірювання часу кадру та затримки покривають плавність в іграх; для ширшого ефекту на рівні системи потрібне контрольоване порівняння зі свіжим встановленням.
| Твердження | Що стверджується | Як це виміряти | Що показують дані | Упевненість |
|---|---|---|---|---|
| Виміряна пропускна здатність | Перекомпільовані пакети виконують те саме завдання за менший час | Заміряти одне завдання на фіксованому залізі та фіксованому ядрі, змінюючи лише репозиторій, з якого взято пакети | Солідний виграш на векторизованій роботі, невеликі регресії в кількох пакетах, без змін у більшості | Висока. Canonical, CentOS ISA SIG і двоє незалежних тестувальників сходяться в загальній картині |
| Затримка введення та стабільність кадрів | Робочий стіл лишається чутливим, поки щось інше навантажує CPU | Процентилі часу кадру та затримка введення під конкурентним навантаженням, а не середня частота кадрів | Опубліковані тести тепер включають 1 % найгірших кадрів і рівномірність кадрів, але не ізолюють планувальник і не вводять контрольованого конкурентного навантаження на CPU | Низька. Механізм задокументований, вимірювання немає |
| Відчутна чутливість | Машина здається жвавішою після переходу | Порівнювати зі свіжим встановленням попереднього дистрибутива, а не зі зношеним | Зазвичай пояснюється ефектом свіжого встановлення або принагідним виправленням; одне порівняння «з коробки» показало перевагу на рівні дистрибутива | Середня. Досвід справжній, атрибуція ненадійна |
Набір бенчмарків, що відповідає на перший рядок, не може відповісти на другий, і жоден із них не стосується третього. Прогнати одне з трьох і видати результат за вердикт щодо всіх трьох — саме це не дає суперечці закінчитися.
Чи справді перекомпільовані пакети працюють швидше?
Так, для меншої частини того, що виконує робочий стіл, і величину задає навантаження, а не дистрибутив. Векторизована робота отримує двозначний виграш, жменька пакетів стає повільнішою, а більшість не показує нічого. Сторінка оптимізованих репозиторіїв CachyOS оцінює приріст x86-64-v3 у 5–20 % відносно звичайного x86-64; опубліковані вимірювання здебільшого лежать біля нижньої межі.
Найчистіше порівняння продуктивності CachyOS і Arch ізолює змінну пакетів і нічого більше: тест в arch-chroot від січня 2023 року на sunnyflunk.github.io. Хост працював на стандартному Arch на Intel NUC8i5BEK, обидва набори пакетів тестувалися всередині arch-chroot, щоб ядро й оточення лишалися ідентичними, а бенчмарки виконувалися в ОЗП, щоб виключити затримки диска. Порівняно зі стандартними пакетами Arch збірки CachyOS були на 20,2 % швидшими при кодуванні flac з -8, на 20,8 % швидшими при кодуванні vorbis і на 9,5 % швидшими на gzip -3. У тому самому прогоні вони були на 7,1 % повільнішими при розпакуванні bzip2, на 1,6–2,9 % повільнішими при стисканні lz4, на 3 % повільнішими на pybench і без змін на бенчмарку R. Два застереження походять від самого автора: CachyOS збирав із -march=x86-64-v3 -mpclmul -O3 проти -march=x86-64 -O2в Arch, а його подальші тести показали, що -O3 , а не рівень набору інструкцій, пояснює частину найбільших виграшів. Допис написано до появи репозиторію Zen 4 у CachyOS, який вийшов із релізом липня 2024 року, але не до роботи з BOLT: автор вважає, що пакет Python CachyOS, який стоїть за регресією pybench, уже ніс BOLT поверх x86-64-v3.
Бенчмарки CachyOS на новішому залізі повторюють картину. Порівняння від липня 2024 року на mvermeulen.org прогнало частину Phoronix Test Suite на Ryzen 7940HS (Zen 4): CachyOS із репозиторієм Zen 4 проти Ubuntu 22.04. Більшість результатів вклалася в кілька відсотків у той чи інший бік: coremark на 6,4 % повільніше, підтести OpenSSL від приблизно 1 % повільніше до 4 % швидше, час збирання ядра на 1,9 % швидше, phpbench як викид із результатом трохи більше ніж удвічі вищим. Автор відзначає розбіжність версій GCC, 14.1 проти 11.4 в Ubuntu, як імовірний спотворювальний чинник. Його окремий прогін NAMD у березні 2024 року показав поліпшення на 6,5 % і 5,8 % на двох задачах молекулярної динаміки.
Інституційні тести знайшли ту саму змішану картину — з обох країв. Власне тестування x86-64-v3 від Canonical, опубліковане в березні 2024 року на експериментальному образі Ubuntu 23.10 в Azure, повідомило про відтворюваний виграш до 60 % у бенчмарку glibc Log2, тоді як інші бенчмарки помітно просіли, в одному випадку тому, що увімкнення v3 на вже оптимізованому SSE-коді змусило компілятор розгорнути його в 17 разів більше інструкцій. Перезбирання CentOS Stream 9 силами CentOS ISA SIG з v2 на v3, на машинах Intel класу Ice Lake у серпні 2023 року, назвало результати «доволі змішаними»: прискорення у 2,2 раза зосередилося в Mocassin і md5crypt із John the Ripper, обидва сильно векторизовані, хоча виграш Mocassin команда приписала переважно автовекторизації GCC 12, а не рівню ISA.
Багато критичних до продуктивності математичних і криптографічних бібліотек постачають кілька версій гарячих функцій і обирають одну під час виконання за визначенням можливостей CPU — техніка називається мультиверсіонуванням функцій і реалізована в glibc через резолвери IFUNC. Це означає, що частина гарячих шляхів уже може використовувати AVX2 на стандартному встановленні Arch без перезбирання всього пакета. Допис sunnyflunk побачив це напряму, відзначивши, що вихідники flac уже містять AVX2-функції часу виконання, яким не потрібен -march , щоб увімкнутися. Знахідка CentOS — дзеркальне відображення: команда виявила математичні функції glibc без версій IFUNC, і саме там у статичного перезбирання є простір допомогти. Перезбирання під v3 дістає решту коду, який автовекторизатор компілятора здатен поліпшити сам, — а це лише скибочка робочого столу, і невелика.
Форма навантаження, а не ярлик на процесорі, вирішує, чи проявиться зміна на рівні машини взагалі. Вердикт щодо пропускної здатності — так, але з обмеженнями: однозначні зміни звичні у наведених вимірюваннях, більші виграші групуються навколо векторизованих навантажень на кшталт кодування та стискання, а деякі пакети регресують. Це точніший опис, ніж вважати x86-64-v3 загальносистемним множником швидкості.
Що змінює планувальник і чому середній FPS цього не бачить
Поточне ядро CachyOS за замовчуванням, linux-cachyos , використовує EEVDF, а BORE доступний через варіанти під конкретний планувальник, як-от linux-cachyos-bore. Ця відмінність важлива, бо ігрові порівняння нижче — тести на рівні дистрибутива, а не контрольовані тести BORE проти EEVDF. BORE і далі стосується ширшого твердження про продуктивність, бо його дизайн явно націлений на чутливість при змішаних навантаженнях, але це твердження треба оцінювати окремо від ігрової продуктивності CachyOS «з коробки».
README самого BORE прямо формулює задум:
Для цього BORE вводить для кожного окремого завдання вимір гнучкості, відомий як «burstiness», частково відходячи від притаманного CFS принципу «повної справедливості».
firelzrd/bore-scheduler, README проєкту
Burstiness — це процесорний час, накопичений завданням відтоді, як воно востаннє віддало CPU, заснувши, чекаючи на введення-виведення або поступившись. BORE перетворює його на оцінку й використовує її, щоб коригувати вагу кожного завдання та агресивність його витіснення при пробудженні, тож завдання, які постійно поступаються, вважаються інтерактивними й отримують перевагу над завданнями, що вибирають свій квант повністю. README сам називає компроміс: BORE приходить до «рівноваги між протилежними жадібними та слабкими завданнями (зазвичай пакетними, обмеженими CPU) і скромними та сильними завданнями (зазвичай інтерактивними, обмеженими введенням-виведенням)». Підвищити вагу інтерактивної роботи — та сама операція, що й знизити вагу пакетної роботи на пропускну здатність.
Це підказує, який інструмент виявив би конкретне твердження BORE: увести конкурентне навантаження на CPU і вимірювати процентилі часу кадру або затримку введення, змінюючи лише планувальник. Планувальнику майже нічого розрулювати, коли гра працює за вільних ресурсів CPU.
Бенчмарк п'яти ігор , опублікований 16 травня 2026 року, використовував чисті встановлення CachyOS і Omarchy на одному SSD та одному залізі, RTX 5060 Ti і Ryzen 9, з тією самою збіркою Proton-GE і налаштуваннями 1440p. Середній FPS відрізнявся лише на один-два кадри. Двома днями пізніше той самий тестувальник опублікував друге порівняння з повним логуванням кадрів через MangoHUD, додавши 5 % і 1 % найгірших кадрів та розкид рівномірності кадрів. Другий тест виконувався на іншому залізі, Intel i7-13700 і Radeon RX 9060 XT, тож це додаткове свідчення про стабільність кадрів, а не продовження першого тесту на тому самому залізі. Жодне з порівнянь не ізолює планувальник CPU й не додає навмисного конкурентного навантаження на CPU.
Сам проєкт теж не перебільшує. У треді r/cachyos про ігрову продуктивність, Peter Jung, один із розробників-засновників CachyOS, відповів користувачеві напряму: «In gaming not all too much. The newer feature can make a difference tough :)» (в іграх не так уже й сильно, хоча новіша функція може дати різницю).
Залишаються два окремі висновки. Для ігор на CachyOS «з коробки» опубліковані тести показують невеликий розрив за середнім FPS і тепер включають вимірювання 1 % найгірших кадрів та рівномірності кадрів. Для BORE конкретно під навмисною конкуренцією за CPU я не зміг знайти опублікованого контрольованого тесту, який змінює лише планувальник і вимірює чутливість під таким навантаженням.
Чому перехід здається швидшим, навіть коли нічого не вимірюється швидшим
Два механізми дають жвавішу машину після зміни дистрибутива без участі жодної з оптимізацій CachyOS: саме свіже встановлення та випадкове виправлення непов'язаної проблеми, яку мала попередня система. Обидва достатньо конкретні, щоб розпізнати їх у своєму випадку, — і саме це відрізняє їх від огульного звинувачення в ефекті плацебо.
Почнімо зі свіжого встановлення. У треді r/linuxquestions на цю темукористувач CachyOS, який, за його словами, сам різниці не помітив, припустив, що люди, які повідомляють про великий виграш, можливо, порівнюють із добряче попрацьованим встановленням, а не зі свіжим. Роки накопичених записів автозапуску, осиротілі служби, розхитана конфігурація і забитий диск — це навантаження, і чистий розділ прибирає все це разом. Зміна дистрибутива одночасно змінює ядро, оточення робочого столу, версію кожного пакета й кожне налаштування за замовчуванням, а повне порівняння Manjaro та Ubuntu розтягується на дюжину окремих осей. Приписати поліпшення одній із них заднім числом — ворожіння.
Випадкове виправлення — випадок гостріший. У тому самому треді коментатор описав, як щодня користувався Fedora з проблемою керування VRAM, що сильно знижувала продуктивність, перейшов на CachyOS і побачив, що проблема зникла. Потім він перейшов на чистий Arch і повідомив практично про ту саму продуктивність, що й на CachyOS, дійшовши висновку, що більше не розуміє, у чому була різниця. Поліпшення було реальним; цілі компіляції CachyOS були тут ні до чого.
Ніщо з цього не дає права на чисте викриття, і найсильніше свідчення проти нього — контрольований тест. Порівняння дистрибутивів на Arrow Lake від Phoronix поставило Ubuntu 24.10, Fedora Workstation 41, Arch Linux, Clear Linux і CachyOS на один Intel Core Ultra 9 285K у стані за замовчуванням, і CachyOS трохи випередив усіх, включно з Clear Linux, який зазвичай лідирує на кремнії Intel. В Arrow Lake немає підтримки AVX-512, тож ця перевага не може походити від x86-64-v4; вона відображає певну комбінацію рішень CachyOS щодо ядра та збирання, оптимізацій пакетів і конфігурації за замовчуванням.
Досвід може бути справжнім, поки атрибуція лишається невизначеною. Порівняння Phoronix на Arrow Lake — корисний контрприклад: встановлення CachyOS у стані за замовчуванням може випередити стандартний Arch навіть тоді, коли x86-64-v4 недоступний.
Як перевірити, чи стосується щось із цього вашої машини
Який стандартизований рівень мікроархітектури x86-64 підтримує ваш процесор, майже повністю з'ясовується однією командою. Динамічний компонувальник повідомляє рівні glibc-hwcaps, які він може використовувати, тож найвищий підтримуваний запис x86-64-vN зазвичай каже, чи підходить CPU для загального ярусу репозиторію v2, v3 або v4. Один важливий виняток — гібридні процесори Intel 12-го покоління й новіші: CachyOS приписує вважати їх v3, навіть якщо у виводі з'являється v4, бо AVX-512 там непридатний. Окрема ціль CachyOS Zen 4/5 теж потребує власної перевірки архітектури.
/lib/ld-linux-x86-64.so.2 --help | grep supportedДля AMD Zen 4/5 CachyOS також документує:
gcc -march=native -Q --help=target 2>&1 | grep -Po "^\s+-march=\s+\K(\w+)$"Перша команда виводить приблизно таке:
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)Це процесор із v3 і v2, але без AVX-512. Три результати, три рішення:
- Нічого вище x86-64-v2. Перевага перезбирань під v3/v4/Zen до цього процесора не стосується. CachyOS усе одно може працювати, а оптимізації компілятора для окремих пакетів разом зі змінами ядра та конфігурації за замовчуванням усе ще можуть мати значення.
- x86-64-v3 підтримується, x86-64-v4 недоступний. Сюди для практичного вибору репозиторію належать сучасні гібридні процесори Intel на кшталт Arrow Lake. У наведених вище порівняннях багато змін були невеликими, деякі навантаження кодування та стискання виграли значно більше, а деякі пакети регресували.
- x86-64-v4 підтримується. AVX-512 дає більше теоретичного запасу для векторизованих навантажень, але не гарантує великого загальносистемного виграшу.
Якщо ваш процесор підходить і вам потрібна лише пакетна половина, перевстановлюватися заради неї не треба. Репозиторії CachyOS можна додати до наявної системи Arch, а ALHP публікує перезбирання офіційних репозиторіїв Arch для кожного рівня x86-64-vN, задокументовані в Arch Wiki зі своїми застереженнями: замість напряму злінкованих модулів ядра потрібні пакети DKMS, а встановлення -march для компіляції ядра «не дасть скільки-небудь значущих результатів». Будь-який зі шляхів дає вам перекомпільовані пакети й нічого з набору патчів ядра чи варіантів планувальника.
Спершу виконайте команду. Вона перетворює суперечку про дистрибутиви на факт про вашу власну машину — єдину версію цього питання, яку ви можете закрити самі вже сьогодні ввечері.
Розробляйте на Linux VPS з root-доступом, NVMe та потужністю AMD EPYC.
Переглянути тарифи LinuxЧасті запитання
Чи справді CachyOS поліпшує продуктивність в іграх?
За середньою частотою кадрів — ледве. Порівняння п'яти ігор у травні 2026 року знайшло лише різницю в один-два кадри, а повторний тест двома днями пізніше також виміряв 1 % найгірших кадрів і рівномірність кадрів. Жоден із тестів не вводив навмисного конкурентного навантаження на CPU, тож невирішене питання — чутливість планувальника під конкуренцією, а не те, чи вимірювалася рівномірність кадрів узагалі.
Чи підтримує мій процесор x86-64-v3 або v4?
На CachyOS або Arch виконайте /lib/ld-linux-x86-64.so.2 --help | grep supported , щоб побачити стандартизовані рівні glibc-hwcaps, визначені для вашого процесора. x86-64-v3 вимагає набору можливостей епохи AVX/AVX2, а v4 додає AVX-512. Для гібридних процесорів Intel 12-го покоління й новіших CachyOS рекомендує вважати систему v3, навіть якщо у виводі з'являється v4; користувачам Zen 4/5 варто також перевірити окрему ціль znver4/znver5.
Чому перекомпільовані пакети не дають більшої різниці?
Бо частина сильно оптимізованого коду вже під час виконання спрямовується до реалізацій під конкретний процесор. Математичні та криптографічні бібліотеки часто використовують мультиверсіонування функцій або IFUNC для гарячих функцій, тому перезбирання пакетів допомагає переважно коду, який компілятор здатен додатково оптимізувати або векторизувати глобально.
Чи можу я отримати оптимізовані пакети CachyOS, не змінюючи дистрибутив?
Так. Репозиторії CachyOS можна додати до наявного встановлення Arch Linux, а проєкт ALHP публікує перезбирання офіційних репозиторіїв Arch під x86-64-v2, v3 і v4, задокументовані в Arch Wiki. Обидва варіанти дають лише перекомпільовані пакети, а не набір патчів ядра CachyOS, альтернативні планувальники чи налаштування інсталятора за замовчуванням.
Обговорення
Коментарі
Увійдіть, щоб долучитися до обговорення.