Talált teljesítmény: Clang + LTO-val fordított Linux kernel
Mi történik akkor, ha elrugaszkodunk a megszokott GCC-től és inkább az LLVM Clang-e bízzuk a Linux kernel fordítását? Az LTO bekapcsolása segít vagy csak a fordítást lassítja?
Mi történik akkor, ha elrugaszkodunk a megszokott GCC-től és inkább az LLVM Clang-e bízzuk a Linux kernel fordítását? Az LTO bekapcsolása segít vagy csak a fordítást lassítja?
A Phoronix letesztelte, jelent-e a teljesítményelőnyt, és ha igen, akkor mennyit, ha a Linux kernelt nem a megszokott GCC-vel fordítjuk, hanem Clanggel, illetve hogy az LTO bekapcsolása jelent-e valamit.
Az LTO, azaz Link Time Optimization röviden egy olyan optimalizációs megoldás, amely az egész alkalmazást áttekintve végzi el az optimalizációt, ezért hatékonyabb, mint a klasszikus, modul szintű optimalizáció.
Tesztben szereplő alkalmazásverziók:
- Linux: 6.19 (Git)
- GCC 15.2
- LLVM Clang 21.1.7
A teszt során összesen 163 különböző mérés történt. Az eredmények sokszor szinte mérési hibahatáron belül vannak egymáshoz képest és vegyes felhasználást feltételezve szinte mindegy is, hogy GCC, Clang vagy Clang + LTO-val került fordításra a kernel.
Ugyanakkor van néhány olyan feladatspecifikus eredmény, ahol jelentősebb lehet az előny: nginx, PostgreSQL, Memcached. Különösen teljesítményérzékeny esetekben, valószínűleg elgondolkodnék azon, hogy a PostgreSQL szerverre Clang + LTO-val újrafordítsam a disztribúció kernelét.
Összegezve az eredményeket: bizonyos esetekben megérheti a Clang + LTO használata, de nem mindig. Ne feledjük, hogyha bármilyen módon eltérünk a disztribúciónk által szállított kerneltől, akkor annak a frissen tartásának a terhe a mi vállunkat fogja nyomni.
A teljes teszt a Phoronix oldalon olvasható: https://www.phoronix.com/review/linux-kernel-llvm-clang-lto