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-re 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-re 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, hogy jelent-e a teljesítményelőnyt és ha igen, akkor mennyit, ha a Linux kernelt nem a megszokott GCC-vel fordítjuk, hanem Clang-el, illetve hogy az LTO bekapcsolása jelent-e valamit.
Az LTO azaz Link Time Optimization röviden egy olyan optimalizációs megoldás, mely 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 a kernel fordításra.
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, hogy ha 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