Jadro pudla a tedy hlavni vliv na rychlost mezi distribucema bude to co vsechno je defaultne predinstalovano, hlavne demoni a sluzby. Jelikoz chci jenom desktop a par GUI aplikaci tak by nemel byt problem dohledat a vypnout services co neni treba. Ale to uz je takove to bastleni bez zaruky kde nevite co na cem zavisi a co se rozbije.
To si nemyslím. Vypínání služeb na pozadí mělo smysl v dobách, kdy měly počítače zoufale málo RAM a každý megabyte se počítal. Díval jste se, jakou máte spotřebu RAM a zátěž CPU v klidu? Tipnul bych si, že CPU se bude flákat mezi 0 - 2 % zátěže a RAM bude ze tří čtvrtin k dispozici.
Druha vec, jak psal @beer muzou byt ovladace grafiky (ja mam jen integrovanou intel iris 6100). Ale 2D akcelerace by snad nemela byt problem s jakymkoli driverem.
Pro Intelí grafiky je k dispozici je jeden ovladač, který určitě máte nainstalovaný, protože je součástí jádra a Mesy. Zde toho tedy moc nevymyslíte.
Treti vec je display manager a desktop environment. Wayland je v plenkach takze zatim Xwin. No a tezkotonazni DE se stovkou libu jako KDE a Gnome tedy muzme vyloucit a zamerit se na XFCE prip. LXDE.
Display manager výkon určitě nijak neovlivní, pracovní prostředí dost minimálně. Je možné, že třeba aplikace postavené okolo KF5 knihoven budou startovat o něco pomaleji. Naopak zrovna použití Xek místo Waylandu nějaký negativní efekt na rychlost mít může. Z jedné přednášky Daniela Stonea si pamatuji, že třeba při spuštění GEditu zabere dost času jen fetching nějakých properties od Xek. Sám bohužel desktop na Waylandu nikde naostro nemám, F25 s Gnome a experimentální podpora Waylandu v KDE mi přišly mírně svižnější, než když to běželo po Xky, když jsem to ze zvědavosti párkrát zkoušel.
Stvrta vec je jak se kompilovalo. U 64bit distra nepredpokladam dramaticke rozdily v -march prepinaci, predpokladam, ze dnes se snad vsechno kompiluje s "core2" co je dobry krome intelu jak pro amd tak pro atomy.
Arch myslím kompiluje s -march=generic, u ostatních dister nevím. Když jsem na podobné vylomeniny měl čas, kompiloval jsem si ručně třeba mplayer, ffmpeg a dalších pár kousků softwaru, co mi přišly jako výkonnostně náročnější. Teď používám zásadně distribuční verze a nepozoruji žádný rozdíl.
Pata vec - kernel. No na rovinu, naposledy jsem kernel kompiloval jeste za dob RHEL5 a od ty doby na to radeji nesaham 
Ale jiste by se nasla desitka modulu co nepotrebuji, podpora kde jakeho filesystemu atd. Mozna se s tim pohram o vikendu. Nekdy -o3 dela zazraky :-)
Dnes je v jádře skoro všechno modulární a co není potřeba, tak se nezavede. Jádro jsem si sám samozřejmě překládal také a též nemám dojem, že by to kdovíjak pomohlo.
Kdysi dávno jsem rozběhával na Celeronu 300A Gentoo. Bylo to v době, kdy tento procesor patřil spíše do muzea milníků výpočetní techniky než do pracovního stroje. Po týdnu zběsilého kompilování se všemožnými optimalizacemi jsem tam dostal KDE 3.5 a Firefox. Firefox startoval 30 vteřin, KDEčka asi minutu a půl a celé to bylo bytostně nepoužitelné. I kdybych ty KDEčka nahradil nějakým Fluxboxem, Firefoxu by to přiliš nepomohlo. O pár let později jsem měl na Athlonu 64 3000+ Gentoo, na P4E 3.2 Arch, obé s KDE 4. Gentoo baštila o něco méně paměti, nejspíš proto, že jsem USE flagy vypnul podporu pro různé blbinky. Rozhodně ale nešlo říci, že by ta Gentoo byla viditelně rychlejší.
32 bit bude urcite ryhclejsi nez 64bitovy
Tohle je absolutní blbost. Programy přeložené pro x86_64 mohou použít více registrů, do jednoho registru nacpat 2x více dat a předpokládat instrukční sadu SSE2. Na Phoronixu se to párkrát benchmarkovalo a 64bitový Linux ten 32bitový - byť jinak identický - totálně zažehlil.
33 Odpovědí
14797 Zhlédnutí